Jun 25, 2013

Merging DLLs to register plug-ins in database

When we code plug-ins usually, we do them according to programming principles.  One strong principle we all adhere is separating codes to different layers: mainly for calling part, Business Logic Layer, Data Access Layer and etc. So we can copy all DLLS to relevant path (Server\Bin\Assembly) when deploying the plugin and call the accessing part through plug-in registration tool. In this case we need to register the plug-in in Disk mode.

How about if we need to register the plug-in in Database mode?


Here we can only point one DLL. So are we going to get rid of our systematic code that produces few DLLs? No. You can merge the DLLs to one and register.

Suppose I got below three DLLs and XXXPlugin.dll is the calling DLL.

XXXPlugin.dll

XXXDataLayer.dll

XXXBizLayer.dll

Below is the code to bundle the DLLs to one called “PluginCaller.dll” (you can use any name).

REM ilmerge  /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319   XXXPlugin.dll    /keyfile:xxxKey.snk  /out:PluginCaller.dll 


ilmerge  /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319    PluginCaller.dll XXXBizLayer.dll XXXDataLayer.dll /keyfile:xxxKey.snk   /out:PluginCaller.dll

Now you are good to go.

Note

Now this tempt you to use a development CRM organization too in the same server as Live, since you can register any number of plug-in versions of same DLLs.

Still I don’t think it’s an advisable thing. While infrastructure specialists can find more reasons for this, my simple question is will your client going to allow you to install development tools in the same server? Otherwise how you going to debug the development CRM? How you going to restart IIS in the process of development?

By the meantime, this will be a good solution for CRM online systems too.

(I am thanking my colleague Kin Ng for helping me with this)

4 comments:

  1. Indika AthukoralaJune 25, 2013 at 11:32 PM

    Hi Summa aiya,
    I think one way you can do is, deploying related dlls in to the GAC (XXXDataLayer.dll, XXXBizLayer.dll), which I normally used to do.
    But recently we had an issue with this practice.
    In our project we have more than one BU. So each and every BU we had different Visual Studio Solutions which means different BizLayer dlls and DataLayer dlls and also we had different XrmDataContext dlls as well. XrmDataContext (early bound classes) is the one we generated using crmsvcUtill exe.
    When two plugins (two different BU) loaded at the same time one plugin was failed due below error,
    “Unable to cast object of type BU1.Entities.CRM.Contact' to type BU2.Entities.CRM.Contact'”
    To overcome this issue what we did was,
    We created Common project which contains only XrmDataContext class, then refer this project in other Projects, for an example BU1 project , Bu2 Project.
    So now in the GAC we have only one XrmDataContext. All other dlls [BU1.BizLayer.dll, BU1.DataLayer.dll/ BU2.BizLayer.dll, BU2.DataLayer.dll] are accessing this common dll from the GAC.

    Thanks

    ReplyDelete
  2. sumedha ObeysekeraJune 27, 2013 at 4:40 PM

    Hi Athu,

    I completely forgot that GAC can handle versioning. Actually I didn’t take much attention on that since moved to deploying DLLs to bin\Assembly. Anyway, your solution opens another avenue I can think of. By the way, do you have any idea what is the Microsoft recommendation?

    Thanks for sharing the knowledge.

    I found this article that explains ways of deploying DLLs along with respective pros and cons.
    http://crmvoyager.net/2011/01/14/deploying-referenced-assemblies-in-crm-2011-plugins-and-workflows/

    Cheers,
    Summa

    ReplyDelete
    Replies
    1. Indika AthukoralaJune 27, 2013 at 7:23 PM

      Thanks for sharing aiya, As he mentioned in that blog post all methods has pros & cons, we need to find out best method which matching to our development environment,
      As I feel the good thing about GAC deployment is that it reduces one deployment steps. Because, normally Business and Data Access dll we are using in other places as well such as Custom workflows Custom web pages.
      When we do a large deployment we can simply deploy these dlls in to GAC, and most importantly as you know we can register plugin dll in DEV environment or UAT, and then add steps, images then we can add Plugin assemblies and Sdk Message processing steps in to out CRM Solution.
      So when it comes to production deployment we don’t need to register plugin dll separately, we just need to do the GAC Deployment for related Dlls.

      Thanks & keep posting

      Delete
  3. sumedha ObeysekeraJune 27, 2013 at 10:19 PM

    You are correct. I just read Microsoft article and found they recommend it. I was thinking other way. Thanks for making me realised.
    (http://msdn.microsoft.com/en-us/library/gg309620.aspx)

    "…Regardless of whether you deploy your plug-in to the database or disk, if your plug-in requires other assemblies to run, you must put copies of these assemblies in the global assembly cache on each server where the plug-in is to execute. This does not apply to a Microsoft Dynamics CRM Online server because you do not have access to the global assembly cache on that server."

    Now problem narrows down to CRM onlines.

    ReplyDelete