Using an External Assembly for Entity Events and Business Rules in SalesLogix Web

Using external assemblies in SalesLogix development, rather than built in Code Snippets, is a better & more efficient way to customize SalesLogix entities, with far less headaches. Some of the benefits include a better and more complete development environment and having all your code in one place (instead of digging around through all the entities to get to the code). Let’s take a look at how to do it.

The Assembly Project

To start, we’ll create the basic SalesLogix assembly project in Visual Studio. This basic project shell is something I create whenever I start on a new customer project. Then, then when I need to start creating code, my assembly project is all set up and ready to go. To start, open Visual Studio and create a Class Library project.

Once your project is created, you’ll need to add some core SalesLogix assembly references to it. The common ones I always start with are:

  • Sage.Platform.dll
  • Sage.SalesLogix.dll
  • Sage.Entity.Interfaces.dll
  • NHibernate.dll (Some entity event signatures include ISession which is found here)

Where do you reference these from? If you’re going to be sharing this code with other developers who will be pulling from the same source repository, you’ll want to make sure that the referenced location is the same for all developers. The SalesLogix Application Architect makes this easy because it copies all the needed references to one common location, located at C:Program FilesSalesLogixReferenceAssemblies. If you don’t see this folder or the needed assemblies there then in Application Architect go to “Tools” and then select “Copy Assemblies”. This will copy the files to that location. So, in your Visual Studio project add the references I mentioned above from this location. I usually open the csproj file in a text editor as well and change the HintPath to these references from “C:Program Files (x86)SalesLogix…” to “$(ProgramFiles)SalesLogix…”, this way if some devs are on 32-bit machines and others on 64-bit machines the path will be the same for all.

The basic project is all set up and ready. Now lets look at adding some business rules and event code to it.

Adding Business Rules and Events to the Assembly

Now that the project is all set up in Visual Studio, let’s look at adding some business rules and events to it. This is the easy part. In Application Architect, go to the entity you want to add the code for. For our example, we’ll add an event to the Account entity. Under the account entity, expand, Rules, then Events. Double click on OnBeforeInsert (we’re using OnBeforeInsert for our event, but of course, you’ll do this for the event you’re writing code for). You’ll notice that there is a method signature showing:

We need to add that same signature to our project. Highlight it with your mouse and then use CTRL+C on your keyboard to copy it. In a class in your assembly, paste that same signature. You’ll also want to add these usings to the class for that signature:

using NHibernate;
using Sage.Entity.Interfaces;

Now you’ll add code to that method just as you would normally in a code snippet in Application Architect. For example, something like this:

public static void OnBeforeInsert(IAccount Account, ISession session)
    // Simple example code

    Account.Type = "Customer";
    foreach (var contact in Account.Contacts)
        contact.Type = "Customer";

Point is, there is no difference in the code you’ll write here than the code you write in a code snippet in Application Architect. Once you’re done you’ll compile the assembly. Now we need to wire it up in Application Architect.

Wiring up the Assembly to the Event (or Rule) in Application Architect

We need to wire up the assembly in the business rule so SalesLogix knows where to execute the code when the event or rule fires. Kris Halsrud has posted about this part before . See Wiring up a SalesLogix Entity Event to an External Assembly. Basically, you’ll have two parts here. First is to wire up the assembly to the event. Second is to add the assembly to the bin folder in the Support Files of the portal (so it is deployed with the rest of the site).

To wire it up, click the ‘Add’ link of the event or rule in the desired step, just like you would normally. Then, instead of selecting C# or VB.NET Snippet, select External Assembly then click the “Select  type and method from assembly” link:

When you click that link you’ll use the File menu on the dialog that opens to browse to your compiled assembly. Then expand the namespaces and classes in the assembly to find your method you created:

That’s it. It is all wired up now. However, in order for the assembly to get deployed with the website you’ll also need to add it to the “bin” folder in the Support Files:

Now the assembly will deploy with the site. You can also now add the assembly to a manifest to bundle it up for delivery.


I mentioned this at the start of the post, but wanted to reiterate this here. Basically, I prefer adding event and business rule code in external assemblies to using snippets in AA. You’ll find this is a much smoother and easier experience all around. Here’s some benefits that you’ll see:

  1. All event and rule code in the same place.  No more needing to dig around the entity model to locate your code. It’s all in once place in the Visual Studio project file.
  2. Code reuse much easier. No more duplicating code since all your code is in a single place where it is much easier to manage. If you wanted you could make a base class with all sorts of built in goodies that your class could inherit from to have some useful built stuff.
  3. Adding references to other things much easier. One of the biggest pains of using code snippets in Application Architect is adding references to other assemblies. This is always a pain and turns out to take up way more time than is needed. This route avoids that pain completely. Not to mention if you wanted to add a reference to a web service, using this route makes that easy. Good luck trying that in a code snippet.
  4. Not limited to code you can fit in a single method. When you add a code snippet, you basically get a method stub you add the code into. This makes it hard to use good object oriented design and use good coding standards. Doing the code externally makes this a no-brainer.
  5. Ability to unit test your code. I love unit testing and the only way you’ll be able to do this with your entity code is to do it externally (future blog post on this topic down the road).
  6. Shorten development cycle. Something I do often, is bypass the whole build & deploy phase while developing. I’ll wire up the method, but then as I make changes to the code I’ll just copy the new compiled assembly to the deployed site’s bin folder then refresh my browser. Instant ability to see your code in action without the need to build and deploy.
  7. More complete development environment. Let’s face it, the code editor in Application Architect leaves a lot to be desired. It does the job, but the intellisense isn’t always something to trust.
Want content like this delivered to your inbox? Sign up for our newsletter!

Ryan Farley

Ryan Farley is the Director of Development for Customer FX and creator of He's been blogging regularly about SalesLogix, now Infor CRM, since 2001 and believes in sharing with the community. His new passion for CRM is Creatio, formerly bpm'online. He loves C#, Javascript, web development, open source, and Linux. He also loves his hobby as an amateur filmmaker.


  1. Fred,

    There are always benefits to using an external assembly. I will use one 95% of the time over trying to code things inside the AA itself.

    As for doing what you mentioned using SData, there’s no benefit to using SData for this (as a matter of fact it will make it all slower) since in a business rule you have access to the entity model already and there’s no need to go through SData to use the model you already have direct access to.

    For passing parameters, there are ways you can bind parameters that get passed to the business rule, or a simple approach is to use a snippet to call the rule in the assembly and pass long whatever values you need.


    • Unable to access Custom Entity while creating class library. For example I am using MailQueue for send email functionality. I am unable to access IMailQueue entity in the class library. The alternative I used is access using SData. As mentioned by you using SData in Business rules impact performance. Kindly suggest the alternate way to access Custom entity in Class library. Thanks

  2. Hi Ryan,

    This article is already too old. it’s valid yet or new version of AA has functionality and work better than Visual Studio?

    • Hi Oscar,

      The methods outlined in this article are still valid for using an external assembly for a business rule (we still use this method in current versions of Infor CRM)


    • However, the .NET Framework version is now different in current versions. That is really the only difference. For example, for 8.4.04 you’d use .NET 4.5.2. Other than that, the steps are the same.

Submit a Comment

Your email address will not be published. Required fields are marked *