Dynamics 365 — Problems with managed solution problems out of sync solutions
Solutions group customisations which can be easily moved between environments but with what Microsoft gives with one hand they punch you in the face with dependencies issues with the other :-) #HoskWisdom
Solutions in Dynamics 365 offer the developer great flexibility but which can lead to complex multiple and overlapping solutions mixed with branched/versioned solutions.
The Dynamics developer can use unmanaged solutions 🙂
Other posts on solutions
- What’s the best way to organise solutions in Microsoft Dynamics 365
- Dynamics 365 — Error when exporting a solution
- What the solution checker does and why you should use it
- How to convert an unmanaged solution into a managed solution in Dynamics 365?
- Dynamics 365 — how solution layering can help you resolve solution updating problems
When Solutions go wrong they are awful and can take lots of time poking around trying to find out the cause of the problem.
Many developers have had problems importing solutions and dependencies or other errors, some of the errors I have experienced are below.
Solution import Errors
- CRM 2011 — Solution not importing — Timeout errors
- CRM 2011 — SQL error while importing solution in crm 2011
- CRM2011 OptionSetId Cannot be Changed when Importing Unmanaged Solution
- CRM 2011 — error when importing solution
Solutions brief introduction
If you want to learn about solutions read this blog CRM 2013 — Understanding Solutions and how they work, below is a quick recap
- A solution is a way to manage and deploy groups of customizations.
- Managed solutions or the customisations cannot be modified
- Unmanaged solutions copy the changes into the default solution; the solution container is merely a wrapper to move the customizations between CRM organisations.
If you remove a managed solution, it removes all the customizations and the data.
Why use managed solutions
Choosing your solution strategy is an important because it can be difficult to swap back from a managed solution to an unmanaged solution.
There are many choices you have to make in Dynamics which are very hard to undo like
There are developers who dislike managed solutions and only deploy unmanaged solutions. Microsoft recommends you use managed solution beyond the DEV environments.
The logic behind a managed solution is two fold
- Managed solutions are read only to stop anyone changing the customizations
- Stopping users from changing the customizations which could cause customizations to not work incorrectly.
Managed solutions are great for resellers who created a solution which acts like a product. E.g. an Autonumber solution. They can sell the Autonumber solution, it’s gets deployed and the users can’t change any of the code to stop it working and developers can’t look at the code to steal the code/ideas (although they can if they really want to)
This scenario is ideal for managed solutions because if the users change their mind and don’t want to use the solution they can uninstall it and it removes all traces of the solution and its data.
Why doesn’t everyone use unmanaged solutions?
If managed solutions can be problematic why doesn’t everyone use unmanaged solutions?
Unmanaged solutions are great but there are some things to consider
When importing unmanaged solutions, your changes will be written to the default solution. This will overwrite all
This article Use solutions for your customizations
Never import an unmanaged solution unless you are sure you want to accept all the customizations in it and allow any of those customizations to overwrite any customizations you previously created.
Unmanaged solutions means all customizations are editable, this means users could possibly change a customizations and stop them working as intended by
- Deleting a field
- Add conflicting customizations
- Modifying customizations
- Importing unmanaged solutions could overwrite customer’s modifications or change how they work.
Unmanaged solutions can avoid conflicts but can lead to other problems, often problems caused by overwriting customizations which are not initially obvious.
If you use unmanaged solutions, you would manually have to delete components from every environment.
Below I discuss some problems using managed solutions.
Multiple managed solutions can be tricky in general
Managed solutions can be problematic is when you have overlapping managed solutions where you have different managed solutions which have the same entity in both.
The solution layering can effect which solution layer is on top.
Managed solutions out of sync
Managed solutions can be problematic when different versions/phases of the same managed solution are deployed in different environments (e.g. prod, pre prod, dev) with different functionality being delivered.
To visualise this scenario it helps to think of solutions as branches in source control. Users want changes made to an earlier version but later versions have already been modified.
The developers is in a tricky situation of adding fields/customizations to an older solution but cannot bring these changes to the later branches because it could/would overwrite changes made in the later solution. This can lead to manually adding fields into the different versions of solutions which can lead to problems
Problems with branched solutions
I recently experienced a problem with branched/versions of solutions which I will explain the problem (I will try, it’s complex), the cause and the solution.
When I use the term branched solution, I am referring to the same solution but with different versions. I find it easier to visualize and explain the problem if you consider these solutions as code branches.
Any developer who has gone through the process of merging changes through code branches knows it can be a difficult and slow process, involving merging the code, working out if the merged code works and importantly checking the merged code hasn’t broken anything.
Merging code can lead to a conflict (this happens when the same piece of code has changed in code being merged) and the developers needs to decide what to replace.
Dynamics developers don’t do merging, Dynamics does this with solutions and if there is a conflict! A conflict in customizations
Conflicts are usually dealt with by using the options on the solution import.
The common problem with importing solutions is dependencies, this is caused by having components in the development environment which are not present in the target environment.
Branching solutions problem
I had multiple versions of a solution which was managed
- Hosk Solution version 1
- Hosk Solution version 2
- Hosk Solution version 3
- Hosk solution version 1 deployed in production/Live
- Hosk solution version 2 deployed in pre production
- Hosk solution version 3 deployed in Dev and currently being worked on
- HSV1 (Hosk solution version 1) was the current live solution and is not being changed
- HSV2 is in preproduction and being tested with some functionality
- HSV3 the current development functionality
Understanding the solutions and their states is easier if you visualise the separate solutions as a waterfall.
Remember HSV2 was created from HSV1 but is now very different and HSV3 was created from HSV2 but now is very different with lots of new and cool functionality. I have tried to show this by creating them as different colours and shapes.
A situation can occur where a bug is found in Hosk version 1 — HSV1, the developer must decide which solution the fix should be put in. This problem needs some extra fields to be added to an entity as well as some code.
Where to put the fix?
We can’t put the fix into the latest version HSV3 because we couldn’t deploy this solution to live until all the customizations were finished and tested.
If we put the change into HSV2 we would then need to put all the customizations and changes into live and the customer hasn’t finished testing the customizations. We would have a problem where HSV2 and HSV3 are out of sync.
The choice made was to put the fix into HSV1 (production solution), add the fields and code, test it on the HSV1 organisation we have and deploy the fix to live.
We now have a problem because the CRM solutions HSV2 and HSV3 are now out of sync.
There are fields and code in the live CRM system which doesn’t exist in HSV2 and HSV3.
One of the main concerns is the current development might not work when deployed with the changes in HSV1, so we have to sync the environments.
How do you get these changes into HSV2 and HSV3?
The fields were manually added to HSV2 and the code added/merged.
The plan was to export HSV3 as unmanaged.
Import HSV2 into HSV3 and then reimport HSV3 with the previous exported version, this will have added the new fields.
Problems occurred when we tried to import HSV2 managed into HSV1 Managed. The reason it complained was because of duplicate fields.
We added new fields in HSV1 and HSV2. These fields have the same schema name but importantly different guids.
CRM doesn’t see the new fields as the same field because they have the same schema name; it sees it as a CRM developer trying to add another field with the same schema name.
Gulp, we now can’t import HSV2 solution into the HSV1 environment!
Managed solutions make this tricky
Managed solutions make things tricky because if you remove a managed solution it takes away all the precious data with it.
One of the reasons we ran into this problem was because we didn’t use any other solutions to move new fields/customizations between the different solutions.
Solving the problem
Created a new organisation with HSV1 unmanaged — the CRM org we will call Operation SYNC
Deleted newly added fields/views/dashboards in HSV2
Export HSV2 unmanaged — call this HSV2 modified
Imported HSV2 modified solution onto HSV1
We now have the customizations with the same guids in HSV2
Merge code customizations
This organisation now could be used for the HSV2 environment (old one had to be trashed)
The same technique was used to get the changes from HSV2 to HSV3.
How to avoid Sync/branching solution problem
The key to the problems I experienced was you need to be aware you have different branched solutions.
If you need to add changes to the earliest solution (e.g. HSV1) you need to have a mechanism to bring these changes through the other branched solutions. It’s important you bring the SAME changes through the Dynamics systems otherwise (if you add the fields manually) you will be get duplicate errors.
The solution we used above seems easy when you read it but it took a whole day of creating organisations, importing solutions and we weren’t sure it was going to work (fingers and legs were crossed) until it worked.
If the solution didn’t work we hadn’t considered the alternatives but none of them would have been very pleasant, which is why we put of making any further plans.
The first step to avoiding this scenario is don’t create duplicate fields in different branched solutions. This will lead to duplicate fields and cause solution importing problems.
Ideally it’s better to add new fields in the latest solution; you wouldn’t have to worry about syncing your solutions.
Sometimes this isn’t an available choice because the customer needs a resolve a bug in the production solution.
If need to make a change to an older version you need to view your solutions like a water fall and make sure the changes flows down through all the solutions to ensure the fields have the same guids in all your solutions and as good CRM developers know we should never create duplicate customizations.
You could create a patch solution and import it to your branched solutions but you will need to export/import.
Say you want to add new field called HoskField
- Export current branch — HoskField doesn’t exist
- Import patch solution — Hoskfield added, other entity customizations are older
- Import current branch — Refresh entity customizations, HoskField exists
The most important message in this blog post is for people know the danger of branched managed solutions and the potential problems.