Dynamics CRM 2011 - unable to unregister plugin

There seems to be a bug in CRM 2011 if you make changes to a DLL or remove a DLL from the server/bin/assembly folder and subsequently try to unregister the associated plugin. For some reason (I have yet to figure out) 2011 needs to load that plugin assembly again before it can unregister it. Obviously it runs into problems trying to reload this plugin and throws an error. My best guess as to why it needs to do this is it has to unregister the SDKMessageProcessingSteps in the background and I bet that as soon as it attempts to access these items it attempts to load up the assembly. So we end up with a catch 22 situation.

Here's a way to see this in action:

1. Create a basic plugin called something like "TestPlugin"

2. Copy the plugin dll to the server/bin/assembly folder

3. Register this plugin using the "Disk" option using the PluginRegistrationTool

4. Test the plugin (so that it is loaded and activated)

5. Go back to the code and change the plugin name to something like "TestPluginNameChange"

6. Copy the DLLs over again (If you get an access error on the files perform an IISReset)

7. Try to unregister the plugin...

You end up getting an error something like this:

  <ErrorCode>-2147220970</ErrorCode>
  <ErrorDetails xmlns:d2p1="http://schemas.datacontract.org/2004/07/System.Collections.Generic" />
  <Message>System.Web.HttpUnhandledException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #A28C2B17</Message>

So what's the solution? There's a few options here.

1. Copy back in the old DLLs... I don't usually have the original DLLs so that's out (I'm usually in developer mode when this happens and quickly recycling DLLs).

2. If it's an easy edit try to revert your code back and copy in these DLLs. Attempt to unregister.

3. If this doesn't work try to update the assembly with the new DLLs (that were edited as close back to the originals as possible). Then unregister.

4. If this still fails try to update the assembly again but this time switch over from Disk to Database. Then unregister.

5. If you're reading this step you've managed to create a situation I once ran into as well... and couldn't resolve... watch this space for a solution!


All in all, be careful with plugins during development. When replacing a plugin that you've edited quite a lot try get into a habit of unloading the existing assemblies before you load up the new ones. Just takes one slip and you land yourself in a bit of a mess.