Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Plugin exception : Type A & B originates from different assemblies RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    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:

    1. We are running on Premise.      AsyncServer is running on the same box as CRM for now (test environment)
    2. We use ILMerge as we have 10+      dlls per assembly and this simplifies deployment. The assemblies are      stored in the database.
    3. 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

  • Question
    Sign in to vote
    0
    Sign in to vote

    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 GAC

     

    Hope this will help somebody else

    Thanks

    Christian J. Betrisey

    Tuesday, April 29, 2014 9:03 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    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 GAC

     

    Hope this will help somebody else

    Thanks

    Christian J. Betrisey

    Tuesday, April 29, 2014 9:03 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    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