Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
In Dynamics CRM 2016 you’ll see changes to the way CRM handles solutions, encouraging developers and customizers to track the changes to a solution over time more diligently than perhaps we’ve done in the past. On the Solutions page, you can now see the Clone a Patch and Clone Solution buttons, which are mainly just simpler methods for tracking version history and managing changes.
Despite the name, cloning a solution doesn’t actually create a copy of the solution – it rolls up any related patches and helps you increment the version number to reflect the changes.
In previous versions of Dynamics CRM, you were expected to adjust the version number of your solutions manually whenever you made a significant change. However, in CRM 2016 you can let these two buttons do the work for you by using the Clone a Patch button to increment the version number for small changes, and the Clone Solution button for major releases.
The average developer might not have spent too much time incrementing version numbers, but it’s hard to argue that this new functionality isn’t useful and quite efficient.
When you go to clone a solution, the second part of the version number gets automatically incremented for you – i.e. the minor part of the major.minor.build.revision syntax.
And when you go to clone a patch, the build part of the version number gets incremented
Either way, you still have control over your version numbers and can adjust it manually later if you want. For example, if you’re using the year.month.day.revision version numbering syntax you might find the limitations on these dialogs restrictive, so manual editing might still be desired.
Furthermore, if you try to edit a solution which has had a patch created from it, you’ll be told that “you cannot directly edit the components of a parent solution” and that you should be editing the most recent patch instead.
So it looks like the best way to use this new functionality is to use the Clone a Patch button to create a patch solution for your short term development, work directly on the patch for simplicity, then use the Clone Solution button to roll up all the changes you made into the new release when you’re done.
The fact that you can export patches also makes it easy to deploy minor changes during development and testing, without including every component of the parent solution. This can help you trim down the time it takes to deploy small tweaks from your development to your testing environments, saving everyone a little bit of hassle.
Business Applications communities