Dynamics Community Forum Thread Details

Solution Version Control

We currently ran into a unique issue and are looking for guidance. We cloned one of our solutions in the Sandbox with the intent of rolling up our patches to clean up our environment (were reaching 70+ patches). This was done ahead of time with the intent to push over the weekend so we had time to conduct full end-to-end testing. However, additional development was needed that week and ended up extending over 4 weeks. When we went to push our development changes, we realized we were unable to as the patch didn't match the parent solution in production. We realized we can directly modify the version of the patch to allow importing it to production, but we are hesitant to do so without being assured we won't run into any issues downstream. This is a potential solution we came up with, but would like feedback from the experts in this community:

Modify patch to previous version number (ie. from 1.4.1 to 1.3.73) and push to production
Clone solution (1.4) and set version to same number (1.4)
1. Therefore rolling up 1.3.73 patch into solution in Sandbox
Import new parent 1.4 solution into production

We have a few concerns with doing the above:

Will modifying the version number corrupt the patch or the managed solution in production?
If we change the patch number to 1.3.73, when we clone the 1.4 solution in Sandbox will it roll up that patch underneath?
1. If it won't, can we change the version back to 1.4.1 and then clone the parent without causing issues when we push to prod?
Can we clone a solution to create the previous version (ie. clone 1.4 to create 1.4)?
1. If we can't and have to move to 1.5, can we upgrade the 1.3 solution in production to 1.5 and skip 1.4?

FYI, the reason we'd like to push the patch prior to cloning and pushing to production is to due to a deadline mid-week. We'd like to hold off on a full upgrade until the weekend when we have adequate resources and time to test effectively. If the above introduces a lot of unknowns or causes issues, then we would delay until the weekend and export 1.4.1 patch, remove it from sandbox, push the 1.4 upgrade to production, import the 1.4.1 patch in sandbox, then export the patch to production.

Any thoughts/guidance would be much appreciated. Thank you!

Hello,

If your patch are now on different major version from the Parent solution, you should import the solution upgrade, perform the solution upgrade and then continue on your Sandbox with the patch's now on version 1.4.x.

Basically when you do Clone Solution on your sandbox from your base solution it will take into consideration your base solution 1.3 + the patch's on 1.3.x and create a new solution with version 1.4. So until now the patch on version 1.4.x is not inside the solution upgrade and even if you change the version to 1.3.x and import into production, most probably the changes will not take effect when doing Solution Upgrade. Also without counting with the possibility of inconsistencies on the environment.

I would do a Solution Upgrade on target to clean the patch's with version 1.3.x and have the solution on 1.4. Then continuing with the patch's from that version.

If you don't have the Solution Upgrade on version 1.4 and you already have patch's on your source environment you can try to export the patch's as unmanaged and save on your side (computer folder). Delete them from your source environment. Export the solution on version 1.4 and import on target as solution upgrade. Import again on source the patch's that you saved and you can continue the development.

Another thing, there is no explicit number of how many patch's we should use (there are too many variables). But having this many patch's when doing solution upgrade you can encounter performance issues and also is likely to encounter timeouts on your target environment. Depending on how big are your patch's. I would target between 10 and 20. But as I said, it is optional and it depends how many components you have on each patch.

Quick Links

Leaderboard