Wednesday, August 29, 2012

CRM 2011: Plug-in assembly does not contain the required types or assembly content cannot be updated

This post explains why you receive this error message when trying to update a plugin assembly in CRM 2011 and how to correct it.
This is another very popular question in the community, why do I get the following error message when updating a plugin assembly?
Plug-in assembly does not contain the required types or assembly content cannot be updated (Error Code -2147204725)
The answer is not very simple as there are a number of conditions that would produce that error message, and these conditions are barely covered in the official documentation from Microsoft. So here are the things you need to check:

1. You are not allowed to update the assembly metadata (strong name)
The new plugin assembly must have the same fully qualified name (same culture, publickeytoken, name and version). You are allowed (and should!) modify the version build and/or revision number but you cannot change the major or minor version. Your assembly version is always in the form <major.minor.build.revision> and you can specify the assembly version in Visual Studio before you build. Note that because the publickeytoken must be the same, then you must use the same key to sign your assembly as you used for the original assembly you are trying to replace.

2. You cannot remove or rename classes which are already registered as plugin types
A plugin type is basically a class which implements IPlugin and they might or might not be registered in CRM as plugins. If your plugin assembly has any plugin types registered under it, then you need to make sure that your new assembly contains those registered types with the same class names. It is important that the signature of each class which is registered as a plugin is not changed in your new assembly (internal and helper classes can always change with no problem, but not the public plugin classes). If you wish to change the class name of a registered plugin (for example you had a plugin called "MyPlugin" and then you changed the name of a class to "MyNewPlugin") you will have to first unregister that plugin type and then you can successfully update the plugin assembly which contains new plugin type and then you’d have to re-register the new plugin type.

3. You cannot change or remove arguments of custom workflow activities
If your plugin assembly contains custom workflow activities which are registered and which have In or Out arguments, then you are not allowed to update the assembly if you are making changes to the custom workflow activity arguments. Removing or changing the datatype or the name of the arguments is not allowed; however, adding new arguments is OK (not recommended though). If you would like to change the arguments then you’d have to unregister the custom workflow activity from the system, update the new assembly and then re-register the custom workflow activity with the updated arguments. You can find more details about how workflows behave with different version of the plugin assembly: http://gonzaloruizcrm.blogspot.ca/2011/08/assembly-versioning-in-crm-2011.html

If you absolutely need to make a change which is not allowed in the list above, then you would need to either unregister the old assembly and re-register everything back or you can increase the major/minor version of your assembly and then register it as a new assembly (but you cannot update the existing one). Also keep in mind that in general it is a good practice to always change the build/revision number before you update an assembly. That way, the new assembly will be used immediately without having to run iisreset or restart CRM services.
If you find other conditions that cause this error message you can comment on this post. Also, I

6 comments:

  1. Thank u very much! Point 1 did it for me. Now i also found the SDK-Information. D'oh!

    ReplyDelete
  2. I had an interesting issue which presented with this error message as well. The user had added Microsoft.Crm.Sdk.dll into the merge step of their build process. They were building and using ILMerge to pull all the dlls together. When they didn't include the SDK, ILMerge complained about missing types. Adding the SDK made ILMerge happy, but then the file couldn't be uploaded to CRM.
    The solution was to use the /lib parameter to ILMerge, pointing it to the folder where your SDK resides.

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete
  4. Hello, Picked up the sample code for the Workflow Activity from the sdk, compiled and tried to register it for the first time. Fails with the above error. Ideas?

    ReplyDelete
  5. I had the same problem with de 2015 version. To fix, I used the same key and mantain the same DLL version.
    Thanks

    ReplyDelete