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:
- 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 Files\SalesLogix\ReferenceAssemblies. 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:
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:
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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.