Don’t watch the clock; do what it does. Keep going. Sam Levenson
Consistency is what separates the amateurs from the experts #
Microsoft Dynamics CRM plugins have a maximum plugin size, if you exceed this, the plugins will no longer import.
The limit is more likely to be hit in a CRM online projects because sandbox plugins can only include 1 dll, where CRM OnPremise projects can reference plugins in the GAC.
You can put common libraries in the GAC on the server. I have worked in a project where we did this but it meant we had to install dll‘s onto multiple servers due to load balancing. It worked but I’m not sure I liked this method and the majority of projects are being delivered with Microsoft Dynamics CRM online.
What is the plugin size?
I searched for the limit and it was difficult to find but I finally found this forum post
The limit of the plugin is 8 Megabytes, this is a .NET limit on the httpRunTime MaxRequestLength setting held in the web.config.
Microsoft Dynamics CRM on premise projects can increase this value and I have had to do this before to import large solutions and reports
- How to upload large report files in CRM
- CRM 2011 – A time-out occurs when you import a solution in Microsoft Dynamics CRM 2011
- CRM 2013 error – The file is too large and cannot be uploaded. Please reduce the size of the file and try again.
Why is this a problem?
The problem occurs when your solution is larger than 8 megabytes, you will get a timeout error. For CRM online projects because you can’t increase the setting without access to the web.config.
Early bound code can bloat plugins if you generate the early bound model for all entities and not just the ones you need.
It doesn’t only affect CRM Online because the limit can happen for sandbox plugins in OnPremise deployments, highlighted in this article Import CRM Dynamics 2015 Managed Solution – Exceeded Content Size
What can you do
There are few options to avoid this
- Limit the early bound classes to the entities referenced in the plugin
- split your plugin into a separate solutions
- don’t use global business logic classes, only include the business logic a group of plugin needs.
This might not be a problem but it should be something to be aware of, if your solutions are growing in size you will need to organise them into smaller solutions.
I talk about solutions organisation in this article CRM 2016 – What’s the best way to organise solutions in Microsoft Dynamics CRM