0

I've entered a project that used the architecture where all the utility classes were stored in the same project as the plugin. That's fine as long as there's only a few plugins with different utilities.

I noticed, however, that as the number of plugins has grown, many of the individual utility classes overlap. So, I'd like to pull out all the utilities into a single, separate project. My fear is that it's going to be too complicated to maintain once I'm leaving the customer as they're not technically keen.

The best solution I've got this far is following this blog facilitating ILMerge. However, I wonder if there's a simpler way. The optimal approach would be if I can make the CRM "see" the utility DLL just by uploading it. Can I somehow register a non-plugin, non-executable DLL that the plugins can refer to?

Konrad Viltersten
  • 36,151
  • 76
  • 250
  • 438

1 Answers1

2

No, if you are using CRM Online this is not supported.

If you are running CRM On-Premises you could deploy the utility DLLs to disk or register them in the GAC. In either case you need to make sure to keep them updated on each CRM server - if there is more than one.

Nicknow
  • 7,154
  • 3
  • 22
  • 38
  • 1
    So, for CRM Online, my options are: (1) ILMerge, (2) a copy of *Utils.cs* in each plugin project or (3) all the plugins in the same project... I think I'll go with the last option - there are not that many entities that are pluginized and everything will be kept in a tighter solution structure. +1 for clarity and quick reply. – Konrad Viltersten May 14 '15 at 18:33
  • 1
    I go back and forth between # 1 and # 3, usually going with # 3 - except for larger projects where I go with # 1. I wrote about an easier way to use ILMerge (http://nicknow.net/dynamics-crm-ilmerge-dll-plugin/) but it does, seem, to require VS2013 - as someone reported issues with VS2012. It takes advantage of NuGet and uses convention to avoid having to create batch files or modify the build scripts by hand. – Nicknow May 14 '15 at 21:15