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)