Hardcore CRM: Do a major upgrade of a plugin version!

isclaimer / Warning / Attention:
This is not a task that you’ll conduct frequently. This task only makes sense if you are doing product  development in which you want to make an explicit difference between versions.
This procedure might wreck  your CRM solution…My warning didn’t scare you away?
Please, join in, buckle up! Time for some serious fun. At least you cannot say I didn’t warn you.
Warning

The last months I’ve been working on a large project. As with all projects, they do come to an end. Within the project we’ve had multiple releases, some big and some more small.
Today I had to make a delivery of the final product.This meant that I had to make a release with a major new version of the plugins within the solution.
A fairly large assembly with 45 plugins containing a total of 80 plugin steps and 62 registered images. Not a task for the faint hearted…

CRM has it’s own way of handling versioning of plugin assemblies. When you look at the standard .NET approach, a version number has four parts:

< major version > . < minor version > . < build number > . < revision >

As long as you don’t increment the major version, you don’t have to expect many problems when you update an assembly. Unfortunately Dynamics CRM works a bit differently. In case you change the minor version of the assembly, you can’t simply update your plugin in the plugin registration tool. You have to register the updated assembly as a new assembly and you end up with having two assemblies registered.

Too bad, the plugin steps and the associated images are still bound to the old version of the assembly. However there is a clever trick to bind all plugin steps to the new assembly. I’ll explain how. 

Step 1. Create a new “upgrade” solution

First of all within the solution manager in CRM, create a new solution. In this solution include the new and old assembly and include all SDK messaging steps that are being used by the old assembly.

The next step is to save and publish the new solution. Then export it as an unmanaged solution.

Step 2. Modify the customizations.xml

Just to be safe, make a copy of the exported unmanged solution. Just in case something goes wrong.
Then unzip the file and open the “Customizations.xml” file with you favourite text editor (e.g. Notepad ++).

In the customization file, you’ll find the registration of the new and old assembly AND (more importantly) the SdkMessageProcessingSteps which are bound to the old assembly.

Customizationsxml

Navigate to the XML section “SdkMessageProcessingSteps”.
In this section you will find all registered steps. As you can see each step is associated with a plugin type name. In our case it is bound to the old version 7.1.0.1.

For every SdkMessageProcessingStep, you have to change the version number 7.1.0.1 (in our case) to the new desired version number. Be careful don’t do a global search and replace.

Once done, save the file and close the editor.

Copy the modified customizations.xml back to the zip file.

Step 3. Import the “upgrade” solution

Import the modified “upgrade” solution. Once imported and published, both the new and old assembly have the plugin steps and images registered. The import process summary might show a number of warnings… you can ignore these. The system is now in a intermediate state.

What happened in the background is that all existing plugin steps and images  (that you exported) are now associated with the new plugin assembly.

Step 4. The great swap

In the actual solution (not the upgrade one, but the one you want to deliver), add the new assembly. You will see a list containing two assemblies. Remove the old assembly from the solution and publish the changes.

In the background the old assembly is removed from the project and the old plugin steps are gone as well. The “new” plugin steps remain.

Step 5. Wrap it up!

Once done, verify that your solution is still functioning.

  • If this is not the case, then you can import the copy of the unmanaged “upgrade” solution and start all over.
  • If this is the case: everything works like a charm. You can remove the old assembly from CRM and make a managed and unmanaged export of the actual solution.

Another job done!

8 thoughts on “Hardcore CRM: Do a major upgrade of a plugin version!

  1. […] Hardcore CRM: Do a major upgrade of a plugin version! […]

  2. Johnny says:

    Hi.

    This is great explanation. I had similar situation, but because of refactoring the namespaces for some plugins have been changed. The update of assembly was of course not more possible, but modifying steps did the trick – GREAT.

    100 point question! – how to update custom workflows assembly when namespaces have changed? there is no steps like in plugins, and somehow I don’t find any relation between custom workflow action and assembly used to trigger it?

    • Johnny says:

      Actually, I also adjusted the workflows. This time a pointer to assembly was seprately in each XAML workflow. Anyway after the modification of XAML files and uploading solution back everything works like a charm.

      Again thx for the main tip – it led me to the solution

  3. Erez Yaron says:

    1. Upload the new version assembly – you will have both versions in CRM
    2. Use the plugin registration tool to move the registered plugin messages to the new event handler

    In a new CRM solution, add the new and old version assemblies, and all SDK messages. (you can add any other dependencies as needed)
    If you need to move this to another organization, you can import the new solution, and it will move the existing SDK messages as just another update.

Leave a Reply

Your email address will not be published. Required fields are marked *