Unearthing “Solution Layering” feature of Dynamics 365. How are the good old concepts of patching and cloning related to it?

If you really ask me, solution layering is not a functionality in itself. Rather it is a visual representation to see the order in which a solution changed the component. Since you have visual representation of how a component got modified during the course of deployment of multiple managed solutions, this can be used for troubleshooting as well.

I am not going to explain what is Solution Layering. The feature is explained in Microsoft Docs and many other wonderful blog posts. What I am going to explain here is how you can use this feature to your benefit. Believe me the concept of solution layering has always been there starting since 2011, first with managed solutions and then with CRM 2016 it got even more intricate with the introduction of solution patching and cloning. Till now the concept was running behind scenes but there was no way to visualize it. Well with Solution Layering you get just that and let’s see how.

I take the simplest of example. I take the Contact entity and play with the “First Name” field. And believe me with this example I can show you the entire solution layering visual involving patching, cloning and everything. So let’s get started.

Step 1:

Create a solution – Let’s call it “Sol A”. Version 1.0.0.0. Add the contact entity with just “First Name” field. Change length of “First Name” field to 100. Export the solution as managed and import it in target environment.

image

Open the target environment default solution and go to Contact–> Fields –> First Name. Select the field and from the top menu, click on “Solution Layers”. Why did I go to default solution? This is because solution layers is only visible for unmanaged solutions. And when default is present already why bother to create an unmanaged one for this demo.

image
image

This is our first glance of Solution Layering screen. As you can see ‘Sol A’ is at the top order indicating that the length specified for ‘Account Number’ field in Sol A is what in force. Awesome!

Step 2:

Now we repeat Step 1. Create solution named “Sol B”. Version 1.0.0.0. Add the “Contact” entity with just “firstname” field. Change length of “First Name” field to 200. Export the solution as managed and import it in target environment.

Now if I see Solution layering for the field in target environment, as expected you can see Solution B is of the highest order now indicating that changes coming in Sol B are now in effect. Is this something new in here? The answer is a BIG NO. We all know that managed solutions are stacked in order of import (not always and will come to that in a moment) and hence changes coming with Sol B are in effect here. Could I visualize this previously? NO. Solution layering does just that.

image

Step 3:

Now repeating our step of creating solution one more time. We now clone Sol A. Set the version number to 2.0.0.0. And change the length of the field to 250. Remember we already have a lower version of the solution already installed.

image

Now we export it as Managed and then import it in the target environment. Now this time the behavior is bit different. This time we get a different option whether we want to maintain customization or overwrite customization. Let’s first choose “overwrite customization”.

image

When the solution is now imported in the target environment, check for solution layers, you can see something different. You can see in the order in which the unmanaged solution is the doing the final honours here. Which is again something we know would happen as we choose overwrite customizations. But could not visualize before Solution layering was not available.

image

Step 4:

Now what we do. We open Sol B and then change the first name field to 300. Export it and then import it in the target. This time we maintain our customizations.

image

If we check the Solution layering now in the target then nothing new in here. We can see Unmanaged layer at the top again taking all the accolades.

image

Step 5:

Now something very important. We create a patch solution of Sol A.  Add the contact entity and the First Name field. Change the field length to 450.

image

Export it as managed and import it in the target environment. If I open Solution layering now, you can see the managed patch right above it’s base Sol A. Is this something new here guys? No it’s not. After all we all know that managed patches sit on top of base solution. But when I see this through solution layering its a treat. The patch just sits above Sol A and below Sol B.


image

And before I end this as I said at the start. Solution layering just gives a wonderful visibility of how the managed solutions are stacked up. And how a components’ final behavior is affected by multiple solutions imported here. The logic of the inner workings now get a wonderful UI to visualize.

Hope this helps!

Debajit Dutta

(Dynamics MVP)

For consultation/ corporate training visit www.xrmforyou.com or reach out to us at info@xrmforyou.com

Our product offerings:

Role based views for Dynamics 365 (http://www.xrmforyou.com/role-based-views.html)

CRM-Sharepoint Attachment uploader and metadata manager (http://www.xrmforyou.com/sharepoint-integrator.html)

Record Cloner for Dynamics 365 (http://www.xrmforyou.com/record-cloner.html)

Multiselect picklist for Dynamics 365 (http://www.xrmforyou.com/multi-select-picklist.html)

1 thought on “Unearthing “Solution Layering” feature of Dynamics 365. How are the good old concepts of patching and cloning related to it?”

Comments are closed.