none
Unable to load plugin assembly

    Question

  • After struggling hard to get my first plugin working, I thought I had this thing licked, but now I have a new problem (man those plugins really fight you at every step, don't they?!). I am loading a single plugin, contained in an assembly which I am strongly typing. This assembly depends on three other assemblies. Those three assemblies are located in the \bin\assembly directory on the CRM server. All three are strongly typed and added to the Global Assembly Cache (GAC). As I said, I had everything working. Then I needed to change some functionality in the plugin. Along the way I deleted the Assembly.cs file for the Plugin, which had set a version for the Assembly. I rebuilt all of the assemblies, reloaded the Plugin into the database (using Plugin Registration Tool) and reloaded all the dependant assemblies onto the CRM server (replaced files, removed from GAC, readded to GAC, reset IIS). I'm now getting the infamous (to me anyway ;-) ) "Unable to load plugin assembly". Luckily I found out about turning on CRM tracing, so I have some details. Included at the bottom of this message is a trace. As you can see, the problem seems to be that CRM is expecting a different version of the assembly then the one I am uploading into the database. (The version uploaded is 0.0.0.0 but the expected version is 4.0.0.0). So I guess the old version number, before I delete Assembly.cs must have been 4.0.0.0. I suppose I could set the version back to that, but I'd much rather understand where this information is being cached and how I can remove it? Any ideas? I've cleared the DB of all entries for this Plugin. That didn't help. I've restarted the server, removed all copies of the plugin dll from the CRM server. So far no change.

    >Crm Exception: Message: Assembly content(MyShark.Workflow.Plugins, Version=0.0.0.0, Culture=neutral, PublicKeyToken=613253e5c8adc728) does not match the expected assembly identity (MyShark.Workflow.Plugins, Version=4.0.0.0, Culture=neutral, PublicKeyToken=613253e5c8adc728)., ErrorCode: -2147204719
    [2008-03-21 13:16:19.6] Process: w3wp |Organization:3025cc6b-1ae1-44e9-a864-f497e84b603a |Thread:    1 |Category: Application |User: 00000000-0000-0000-0000-000000000000 |Level: Error | ErrorInformation.LogError
    >MSCRM Error Report:
    --------------------------------------------------------------------------------------------------------
    Error: Assembly content(MyShark.Workflow.Plugins, Version=0.0.0.0, Culture=neutral, PublicKeyToken=613253e5c8adc728) does not match the expected assembly identity (MyShark.Workflow.Plugins, Version=4.0.0.0, Culture=neutral, PublicKeyToken=613253e5c8adc728).

    Error Number: 0x80044191

    Error Message: Assembly content(MyShark.Workflow.Plugins, Version=0.0.0.0, Culture=neutral, PublicKeyToken=613253e5c8adc728) does not match the expected assembly identity (MyShark.Workflow.Plugins, Version=4.0.0.0, Culture=neutral, PublicKeyToken=613253e5c8adc728).

    Error Details: Assembly content(MyShark.Workflow.Plugins, Version=0.0.0.0, Culture=neutral, PublicKeyToken=613253e5c8adc728) does not match the expected assembly identity (MyShark.Workflow.Plugins, Version=4.0.0.0, Culture=neutral, PublicKeyToken=613253e5c8adc728).

    Source File: Not available

    Line Number: Not available

    Request URL: http://REMOVED/sfa/conts/edit.aspx?id={03AC731C-7CF4-DC11-8B9D-0003FF908524}

    Stack Trace Info: [CrmException: Assembly content(MyShark.Workflow.Plugins, Version=0.0.0.0, Culture=neutral, PublicKeyToken=613253e5c8adc728) does not match the expected assembly identity (MyShark.Workflow.Plugins, Version=4.0.0.0, Culture=neutral, PublicKeyToken=613253e5c8adc728).]
       at Microsoft.Crm.Extensibility.PluginAssemblyFactory.CreateInstance(Guid pluginAssemblyId, IOrganizationContext context)
       at Microsoft.Crm.Caching.PluginAssemblyCacheLoader.LoadCacheData(Guid key, IOrganizationContext context)
       at Microsoft.Crm.Caching.CrmMultiOrgCache`2.CreateEntry(TKey key, IOrganizationContext context)
       at Microsoft.Crm.Caching.CrmSharedMultiOrgCache`2.LookupEntry(TKey key, IOrganizationContext context)
       at Microsoft.Crm.Caching.PluginTypeCacheLoader.LoadCacheData(Guid key, IOrganizationContext context)
       at Microsoft.Crm.Caching.CrmMultiOrgCache`2.CreateEntry(TKey key, IOrganizationContext context)
       at Microsoft.Crm.Caching.CrmSharedMultiOrgCache`2.LookupEntry(TKey key, IOrganizationContext context)
       at Microsoft.Crm.Caching.PluginTypeCache.LookupEntry(Guid pluginTypeId, IOrganizationContext context)
       at Microsoft.Crm.Extensibility.PluginStep..ctor(Guid stepId, StepDescriptionCache stepDescriptionCache, SecureConfigurationCache stepSecureConfigurationCache, StepImageDescriptionCache stepImageDescriptionCache, CrmEventLog eventLog, IOrganizationContext context)
       at Microsoft.Crm.Extensibility.PipelineStepFactory.CreateInstance(Guid stepId, IOrganizationContext context)
       at Microsoft.Crm.Caching.PipelineStepCacheLoader.LoadCacheData(Guid key, ExecutionContext context)
       at Microsoft.Crm.Caching.ObjectModelCacheLoader`2.LoadCacheData(TKey key, IOrganizationContext context)
       at Microsoft.Crm.Caching.CrmMultiOrgCache`2.CreateEntry(TKey key, IOrganizationContext context)
       at Microsoft.Crm.Caching.CrmSharedMultiOrgCache`2.LookupEntry(TKey key, IOrganizationContext context)
       at Microsoft.Crm.Extensibility.ImageRetrievalStep.MergeEntityRequests(PipelineExecutionContext context, Dictionary`2 entityRequests)
       at Microsoft.Crm.Extensibility.ImageRetrievalStep.Execute(PipelineExecutionContext context)
       at Microsoft.Crm.Extensibility.Pipeline.Execute(PipelineExecutionContext context)
       at Microsoft.Crm.Extensibility.MessageProcessor.Execute(PipelineExecutionContext context)
       at Microsoft.Crm.Extensibility.InternalMessageDispatcher.Execute(PipelineExecutionContext context)
       at Microsoft.Crm.Extensibility.ExternalMessageDispatcher.Execute(String messageName, Int32 primaryObjectTypeCode, Int32 secondaryObjectTypeCode, PropertyBag fields, CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId)
       at Microsoft.Crm.Sdk.RequestBase.Process(Int32 primaryObjectTypeCode, Int32 secondaryObjectTypeCode, CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId)
       at Microsoft.Crm.Sdk.RequestBase.Process(CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId)
       at Microsoft.Crm.Sdk.CrmServiceInternal.Execute(RequestBase request, CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId)
       at Microsoft.Crm.Sdk.InProcessCrmService.Execute(Object request)
       at Microsoft.Crm.Application.Platform.ServiceCommands.PlatformCommand.ExecuteInternal()
       at Microsoft.Crm.Application.Platform.ServiceCommands.UpdateCommand.Execute()
       at Microsoft.Crm.Application.Platform.EntityProxy.Update(Boolean performDuplicateCheck)
       at Microsoft.Crm.Application.Platform.EntityProxy.UpdateAndRetrieve(String columnSet, Boolean performDuplicateCheck)
       at Microsoft.Crm.Application.Forms.AppForm.RaiseDataEvent(FormEventId eventId)




    Friday, March 21, 2008 8:27 PM

Answers

  • Hi.

     

    The AssemblySourceType can either be Database, Disk or Gac. If it's pure Database the both Assembly Description information (loaded into the Cache) and assembly bits come from the database, so I can't figure out why you're getting this error.

     

    but if there is a chance you registered the dll into the gac or loaded the dll to the assembly bin for debug then this might interfere (file version) with the re-registration of the plug-in.

     

    If you're really into checking the bits your self you can create a small console app, read the bit from the FilteredPluginAssembly Content Column (Base64String) into an Assembly Object and read its FullName.

     

    Hope this helps,

    Adi  

     

    Saturday, March 22, 2008 4:40 AM

All replies

  • Are you using the PluginRegistration tool v 2.0?

     

    i don't think you need to GAC your dll.

    Friday, March 21, 2008 9:47 PM
  • You don't need to add your main DLL to the GAC (that goes in the database), but you do need to add any referenced assemblies to the GAC and as I mentioned, I'm referencing three other assemblies. I'm using version 2.0.0.0 of the tool. I don't think it's a tool issue, but it's not impossible? Has there been an update? Anybody have a clue? I'm stumped. The version has to be stored somewhere right, for this to be happening?
    Friday, March 21, 2008 11:13 PM
  • As suspected, setting the version on my Plug-in assembly back to 4.0.0.0 causes it to load properly. I guess I can live with this, but it still seems like something that could end up biting me in the future if I can't determine WHY this is the case. Does anyone have any ideas? Is it a bug? Am I missing something?
    Friday, March 21, 2008 11:27 PM
  • Hi.

     

    What is the plug-in deployment type (On-Disk or Database)?

    You can Query the FilteredPluginAssembly View to confirm the assembly version.

    Did you try restarting IIS?

     

    I'm shooting blanks,

    Hope this helps

     

    Adi

     

    Saturday, March 22, 2008 12:26 AM
  • I restarted the CRM web machine and the SQL server machine. The deployment is into the database.
    Saturday, March 22, 2008 2:03 AM
  • Hi.

     

    The AssemblySourceType can either be Database, Disk or Gac. If it's pure Database the both Assembly Description information (loaded into the Cache) and assembly bits come from the database, so I can't figure out why you're getting this error.

     

    but if there is a chance you registered the dll into the gac or loaded the dll to the assembly bin for debug then this might interfere (file version) with the re-registration of the plug-in.

     

    If you're really into checking the bits your self you can create a small console app, read the bit from the FilteredPluginAssembly Content Column (Base64String) into an Assembly Object and read its FullName.

     

    Hope this helps,

    Adi  

     

    Saturday, March 22, 2008 4:40 AM
  • one thing you may need to note is that the tool does not do the update properly so you will have to remove the plugin and then add it again.

     

    i'm not sure if anyone else is able to update their plugins using this tool as i could not!!

     

     

    Saturday, March 22, 2008 2:10 PM
  • So any luck with this?.. I seem to got into the same problem.. and although I unregistered the assembly.. changed the public key token (in other words I created a completely new dll) I still get that error you mentioned.. in my trace log I see the same problem.. crm is apparently looking for version 4.0.0.0, yet I have 0.0.0.0.. So, with a new assembly, registered for the first time but for the same event, I get the same problem. What is the solution for this?

    Thank you,
    Florin

    Edit: I bumped into this problem again. Apparently whenever I set the plugin to database, it works just fine. The only thing is that.. I don't know how to debug assemblies loaded into database.
    Can you, guys, tell me how?
    Friday, May 16, 2008 11:37 AM
  • Just add a reference of Microsoft.Crm.Sdk.dll  to the plug in registration tool  - rebuild the plug in registration tool & it works. 

    Tuesday, September 23, 2008 11:35 AM
  • Even though this thread is ages old, I figured I'd comment.

     

    In SQL, if you check out the CRM database (org data, not configuration) and open the FilteredPluginAssembly view, you'll notice the column at the end which is 'version'. A quick look will reveal it's purpose but there is something interesting in here.

     

    The assemblies that ship with CRM, like Microsoft.Crm.Scheduling, .Crm.Plugins, .Crm.ObjectModel, etc. etc. have their version set to 0.0.0.0 in the database however the actual version of these assemblies in the filesystem is 4.0.0.0 - this version number makes sense (CRM 4) but what doesn't make sense is why it's recorded in the database as 0.0.0.0

     

    I figure that, by default, if a version isn't set (or set to version 0.0.0.0) the platform will automatically infer that the assembly is version 4.0.0.0 - but no idea why this is the case. If you set the version at compile time for your plugin/workflow assembly to any version other than 0.0.0.0 - everything works fine. No more 'Wrong assembly version' errors. I'm sure there is some deep and meaningful reason the dev's did this, possibly for backward-compat or something.

     

    So I guess the rule here is always version your custom assemblies. I always set them to 0.0.0.1 before going any further. Never had a problem with the 'Assembly is wrong version' issue since.

     

    Personally, I have never deployed to database unless the assembly is ready for production, and therefore always has a version >0.0.0.0 - I would imagine that deploying to database would make debug and testing that extra bit harder, and no one likes making extra work for themselves!

    Wednesday, January 28, 2009 5:09 AM
  • I had same problem. It was when a registered new plug-in without strong name. After that i add key to assembly and rebuilded it. Now same error. You need reregister assembly in CRM only.
    Tuesday, April 28, 2009 1:09 PM