As I mentioned in the previous post, solution layering seems to be explained quite well in the solution lifecycle management whitepaper, so I figured I’d give a try to something here.. and, yes, it got a bit confusing.
Here is what I did in the source instance:
- Created a solution and added a new entity to that solution. “Name” attribute of that entity was set to 100 length. Then exported it as a managed solution
- Created another solution, added the same entity to that solution (with all assets), set “name” property length to 150, and exported that as a managed solution, too
- Increased version number of the original solution, updated “name” property length to be 120 this time, and added a new attribute to the entity. Then exported this version of the original solution as a managed solution again
- And, then, imported those solution into a new instance in exactly that order
And the results?
1. Step 1 (importing the original solution)
2. Step 2 (importing the second solution)
3. Step 3 (importing new version of the original solution)
So, as expected, “Name” field kept its length in the target instance even though it had a different length in the updated version of the original solution. This is layering in action.. What about that new attribute, though? How did that attribute show up in the target instance if it was not included into solution B? In other words, why did “name” attribute changes did not show up, but that new attribute did, even though both changes were introduced in the updated version of the original solution?
The blurb above is talking about the unmanaged layer, but maybe there is more to it.. Let’s try this:
- Update tst_newattribute length in the source (from 100 to 150)
- Export updated version of solution B
Import it to the target instance
Here we go, it’s 150 in the target instance now:
- Ok.. one last test. Let’s change it to 120 and prepare another updated version of the original solution (not solution B). The import it to the target.
And of course, it’s still l150 in the target:
Interesting stuff, so I figured maybe there is a slightly different explanation of layering.
When looking at the timeline, it seems at least solutions are not installed in layers. Actually, maybe the whole concept of layering is a bit confusing since it’s not, really, all about layering.
It seems to be like this:
- As the solutions are installed, they can introduce the same component multiple times
- Each solution can have many different versions of the same component. Within each solution’s stack of versions, the most recent version of the component is what takes precedence
- Where the same component exists in more than one solution, Dynamics decides which version of the component will “surface” depending on which solution stack of versions first introduced that component more recently
And, as for the unmanaged changes, they have the power to break that logic above by introducing a change “here and now”. Although, what happens when we choose to update unmanaged customizations when importing the managed solution.. Does that just remove unmanaged component version in the process?