Robert Pröll

.NET Software Architect

Key areas of interest: ALM, .NET C#, PowerShell, Azure, Dynamics 365 Tooling

Robert started in the area of ASP.NET projects and has now more than 10 years of experience in the international Dynamics Enterprise business.

He works mainly as a principal software architect at Kupp and as an external consultant for Microsoft.

Robert Pröll

.NET Software Architect

“Plug-in assembly does not contain the required types or assembly content cannot be updated.”

Dynamics CRM Versioning & Release Notes

Posted: 04.2019 | Category: ALM

Robert Pröll | .NET Software Architect


It’s well-known that versioning is very helpful to manage software systems especially when it comes to issue identification.

However, it’s a common practice to just ignore it or to “fake a stable versioning system” which actually means either somebody adjust version numbers when he feels to do so, or a huge effort is needed to manage the process.

I want to show what needs to be done and how we can automate this easily.  



The very basic parts are solutions and assemblies, so there just a few things to consider:


Changing the solution version attribute is straight forward (unmanaged), the only restriction is to increase the number if a managed solution must be staged.

C# Assemblies:

.net Assemblies versions are defined by the AssembliesFile.cs file:

Important: Major or Minor part

If you want to change the major/minor version-part, it’s a little bit more complicated:

CRM will complain: “Plug-in assembly does not contain the required types or assembly content cannot be updated.”

Solution: An exported solution consists of some files / subdirectories and the related dll’s.

All references and filenames must be changed. One possible way is to copy the specific xml part and “clone” the steps. Afterwards the “child”-Nodes must be moved. – This approach which will change the step ids.

To keep the plugin step ids additional work must be done.

Advanced Versioning & Release Notes

CRM has a lot of different components which can be the root cause of an issue in a global process.

Strange behavior of a system is often caused by a wrong assumption which version of a component is currently deployed – This can happen for reason like failed deployments, code modification by hand etc.

So, versioning subcomponents seems to be an good idea, but really frustrating to maintain.

From a technical point of view it’s very easy to insert just a version string on each build – If you already got an automated code update process in place.

… theoretically, if there are no encoding issues etc…

KDTooling Solution:

As part of our managed code deployment process all components (JavaScript, Html, CSS, XML, Assemblies, Solutions etc.) can automatically be versioned via a unique source like TFS or a DateTime-Pattern.

This also makes it possible to create a completely new release notes experience with just a few clicks:

Release Notes Details Level

Release Notes Details Level

Version information on code level

Version information on code level

Sample: Release Notes Document

Sample: Release Notes Document