How to Keep Solution Sizes Small in Microsoft Dynamics 365

Dominic Jarvis, 17 October 2017

When moving changes between environments in Microsoft Dynamics 365, solutions are used to package these changes for ease of change tracking and feature management. However, solutions can often become large in size, which can greatly increase the time needed for deployment. It is often good practice to keep these solutions to as small a size as possible. The reason for this is twofold:

1. This will reduce the amount of time needed for a deployment.
2. If anything goes wrong, or a bug is raised after the deployment has taken place, the cause of the issue can be more easily identified in a smaller solution.

There are a couple of easy ways to minimise the size of a solution in Dynamics 365:

Only Include Components You Are Using

When adding an entity to a solution, Dynamics 365 provides you with the option of including subcomponents (forms, views, fields etc.). If you are making a change to all areas of the entity, you may choose to include all components in the solution. If you are only customising a couple of fields and a form, for example, consider only adding these components to the solution, as this will decrease the amount of time needed to import the solution at its destination.

There are actually a couple of schools of thought on this issue, as there are times that it may make sense to include all components. A couple of examples may be working with other customizers, or when performing ribbon customisations.

The reason for this is that if one of the other customizers require another field that was not in the initial inclusion of the entity to the solution, they might incorrectly assume that their changes are already included in the solution. This can be a real hassle when trying to keep track of multiple fields/modifications, as one missing may cause an error on import to the new system.

The other issue is with the metadata. When including an entity in a solution, there is the option to include entity metadata, which includes things like “Notes” and “Activities”, and whether they’re enabled for an entity. Once the entity has been added to the solution there is no way to tell whether the metadata has been included also. In this instance you may need to again remove then re-add the entity with the include metadata option checked – which again, is a hassle. So perhaps in this instance if you are not the sole person using the solution, for the sake of ease of coordination it may make sense to include all child components.

Do Not Include Required Components

If you are creating a hotfix solution, or an update solution, or even a piece of new functionality, odds are that something in your solution will have a dependency on something else in the system (Custom entities are usually the culprits here). Adding required components should only be done in the instance where those required components do not exist in the target system. In this case, add these manually. Doing so using the ‘Add Required Components’ dialog can greatly increase the size of a solution, as well as the clutter. In some cases with the click of a button a solution can increase in size from several components to several tens of components.

Of course, when it comes to customisations and best practices, do what is best for your client/company. Bear in mind though that reducing clutter in your solution can have a great effect on efficiency, and it is much easier to add a component manually than it is to remove a dozen that have been added automatically.