Quick tip: keep your Dynamics 365 development tools up to date using Nuget

I recently encountered an issue when I tried switching the view of the registered plugins & custom workflow activities in the Plugin Registration Tool.

When updating to the latest version using the PowerShell script listed on Download Dynamics 365 development tools from Nuget the error got resolved. Lessons learned: make sure that you keep your Dynamics 365 development tools up to date.

Lessons learned about Dynamics 365 solution layering - Part 1

This is the first in a series of blog posts on Dynamics 365 solutions and solution layering in which I will cover the basics about Dynamics 365 solutions and gradually delve deeper into the mysterious world of the inner workings of Dynamics 365 solutions.

In my opinion,  based on how managed solutions and solution layering work - I think that in the majority of cases you should only use a single managed solution to avoid issues down the line. Read on to see why...

This blog post assumes that you are using managed solutions to deploy to all environments and only have unmanaged solutions in your development environment.

Dynamics 365 solutions fundamentals

If you work with Dynamics 365/CDS solutions, you should be aware of the concept of solution layering. Solution layering occurs on import of solutions when a specific component is affected by a change within one or more solution. Solution layering will determine the kind of behavior that a user will see in Dynamics 365.

The figure above shows how layering works: at the bottom, you have the standard CDS solutions on top of which you might have some first party apps installed like Dynamics 365 Sales/Customer Service etc... If you deploy custom managed solutions, they will go on top based on the order in which they are installed. Direct customizations and unmanaged solutions are always at the top but there is no real layering of unmanaged solutions - they all end up directly modifying the base behavior.

Solution layers describe the dependency chain of component from the root solution introducing it, through each solution that extends or changes the component’s behavior. Solution layers are created through extension of an existing component (taking a dependency on it) or through creation of a new component or version of a solution. So it is very important to understand that layers should be considered on a per component basis.

In April 2019, Microsoft introduced a new user interface component which visualizes the different solution layers which are impacting the behavior of a specific component - View solution layers for a component. Below is an example of the solution layers of the case form which was quite an interesting example.

Going beyond the basics

But what happens if two or more solutions define solution components differently? This article  - Introduction to solutions - conflict resolution explains the two conflict resolution strategies - Merge and Top Wins. The article is also valid for online according to Microsoft support - even though it was written for Dynamics 365 on premise and last updated in December 2017.

When importing a managed solution with the overwrite customization option, it is possible to override the "top wins" conflict resolution  but this does not apply to components which apply a “merge strategy” - for more details see Understand how managed solutions are merged

So you need to be very careful when adding components which apply a merge strategy in multiple solutions with different publishers since the merge behavior might cause unexpected side effect such as creating a separate active layer on top which would block your customization to appear to the user.

An active layer can emerge in two scenarios - a direct customization was done in the instance but it seems that it is also possible that a managed active layer is created when using only managed solutions without direct customizations in the system. This happens when managed solutions in one system, with different publishers (the Microsoft solutions count as a different publisher) are trying to update the same component. It is a defense mechanism that Microsoft has built in when there are object inconsistencies across managed solutions.

The general recommendation is that you keep the number of managed solutions with common components (e.g. forms with a different form layout) to a minimum. This will avoid merging issues across the layers.

Single solution to rule them all?


Taking into account all of the above it seems that you would opt to use a single managed solution to deploy to other environments.

Single solution approach
Pros: Easier to version control Avoid solution layering issues Less environments needed Easier to promote across environments	Cons: Longer duration of solution import Long list of components

I do think that a single solution might make sense in the majority of cases but there are of course exceptions to this rule.  I would recommend you to take a look at the Solution Lifecycle Management: Dynamics 365 for Customer Engagement Apps whitepaper and especially the section on solution boundaries which outlines some of other valid scenarios for having multiple solutions e.g.  the scenario where you need to deploy to multiple regional production instances with small variations with a core solution approach and on top local solutions  or the scenario where you need to release subsets of applications on different cadence/timeline.