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
Intro
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.
Basics
The very basic parts are solutions and assemblies, so there just a few things to consider:
Solutions:
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
Version information on code level
Sample: Release Notes Document
Tags: