Answered by:
Plugin exception : Type A & B originates from different assemblies

Question
-
Hi,
We are getting the following plugin exception.
Unhandled Exception: Microsoft.Xrm.Sdk.InvalidPluginExecutionException: Plugin Exception: ex.Message: [A]Acep.Xrm.Entities.Acep_membership cannot be cast to [B]Acep.Xrm.Entities.Acep_membership.
Type A originates from 'Acep.Crm.Membership.Activities.Merged, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e469dda33dffe06c' in the context 'LoadNeither' in a byte array.
Type B originates from 'Acep.Crm.Plugins.Merged, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e469dda33dffe06c' in the context 'LoadNeither' in a byte array.ex.InnerException: at Acep.Crm.Plugins.FACEPPlugin.HandleBeforeOpUpdate()
In …\CrmPlugins\FACEPPlugin.cs
The problem seems to occur because we have a plugin assembly 'Acep.Crm.Plugins.Merged', and a custom activity assembly 'Acep.Crm.Membership.Activities.Merged' that contain the same dll Acep.Xrm.Entities.dll (contains the early binding generated with crmsvcutil.exe).
In one case:
- A normal workflow is updating a contact (in this case it is not a custom workflow)
- One of the contact plugin fires
- The plugin is trying to access the acep.xrm.entities.dll from the workflow instead of the one from the plugin
In another case
- A custom workflow fails with the same error
This does not always occur. Sometimes, recycling the crm pool and restarting the async server fixes it. Other times it make it reappear as if one of the DLLs would be loaded before the other.
Notes:
- We are running on Premise. AsyncServer is running on the same box as CRM for now (test environment)
- We use ILMerge as we have 10+ dlls per assembly and this simplifies deployment. The assemblies are stored in the database.
- We know that it is recommended to increment the version numbers. We typically recycle the pool & restart async server. In this particular case, both Acep.Xrm.Entities.dll would have exactly the same versions since they are the same anyway.
Is this a known issue? Any solution or workaround?
Christian J. Betrisey
Tuesday, April 15, 2014 10:45 PM
Answers
-
OK, it is working now.
We opened a case with Microsoft Support. Here is the summary:
Microsoft CRM does NOT support plugins and custom activities assemblies using ILMerged. Here is their answer:
We see numerous issues with ILMerging Plugins – especially type casting related issues. You have registered 2 plugin assemblies, both have the
same early bound class in them merged as its own dll, however the namespacing of the 2 plugins is different, so the namespacing of the early bound dll after
merge is different. Once the dll is loaded into memory it will not be reloaded by the next plugin that needs it, as we will check to make sure the
proper early bound entity class is loaded, but not check the namespace origin of the class. If you simply register this early bound dll into the GAC and
reference it from both plugins it will get loaded by one plugin when the plugin executes and then be able to be used by other plugins that reference it.
As mentioned, ILMerged plugins are Not Supported by CRM Support.We eventually registered all our dependent assemblies in the GAC and the main plugin assembly / custom Activities in the DB.
We ran into 2 additional issues
a) The Plugin Registration Tool was not able to register the plugin because we were using an Plugin Base class. This class was in a dependent assembly. We had
to move the base class into the main assembly.b) We did copy all the dependent assemblies to the bin/assembly folder. This did work fine for plugins, but did not for custom assemblies. We eventually had to put them
in the GACHope this will help somebody else
Thanks
Christian J. Betrisey
- Marked as answer by Christian J. Betrisey Tuesday, April 29, 2014 9:04 PM
Tuesday, April 29, 2014 9:03 PM
All replies
-
OK, it is working now.
We opened a case with Microsoft Support. Here is the summary:
Microsoft CRM does NOT support plugins and custom activities assemblies using ILMerged. Here is their answer:
We see numerous issues with ILMerging Plugins – especially type casting related issues. You have registered 2 plugin assemblies, both have the
same early bound class in them merged as its own dll, however the namespacing of the 2 plugins is different, so the namespacing of the early bound dll after
merge is different. Once the dll is loaded into memory it will not be reloaded by the next plugin that needs it, as we will check to make sure the
proper early bound entity class is loaded, but not check the namespace origin of the class. If you simply register this early bound dll into the GAC and
reference it from both plugins it will get loaded by one plugin when the plugin executes and then be able to be used by other plugins that reference it.
As mentioned, ILMerged plugins are Not Supported by CRM Support.We eventually registered all our dependent assemblies in the GAC and the main plugin assembly / custom Activities in the DB.
We ran into 2 additional issues
a) The Plugin Registration Tool was not able to register the plugin because we were using an Plugin Base class. This class was in a dependent assembly. We had
to move the base class into the main assembly.b) We did copy all the dependent assemblies to the bin/assembly folder. This did work fine for plugins, but did not for custom assemblies. We eventually had to put them
in the GACHope this will help somebody else
Thanks
Christian J. Betrisey
- Marked as answer by Christian J. Betrisey Tuesday, April 29, 2014 9:04 PM
Tuesday, April 29, 2014 9:03 PM -
Excellent Post Christian. I never came across this scenario yet..but appreciate your posting this Assembly level details.Wednesday, April 30, 2014 1:30 PM