The trouble with organizing a thing is that pretty soon folks get to paying more attention to the organization than to what they’re organized for.
Laura Ingalls Wilder
What is the best way to organise customisations in solutions, should I use one solution or many? Like most aspect of development, there are best practices to follow but there isn’t a single best way to do anything which you can use on every project.
There isn’t a best way to organise your solutions because organise your solutions the best way for each project, based on the project.
I will discuss the different ways to organise solutions and the advantages and disadvantages.
No Best way
Developers spend hours arguing about the best way to write code, design code, build, deploy and the reason these debates rage on because there isn’t a best way. Some methods are better suited to particular situations but not one suited to every situation.
Writing plugins in Microsoft Dynamics 365 has many best practices such as using early bound code because it‘s easier to read, it captures validation errors in design time and not run time. There are times when it‘s good practice to not use early bound code when you write a plugin which will be triggered by multiple entities.
Dynamics developers need detailed knowledge of solutions, such as
- What is a managed and unmanaged solution?
- What can and can’t go into a solution
- How do solutions merge?
- What happens when you delete a managed and unmanaged solution?
To learn about solutions read my post Overview of solutions
Patch solutions allow you to take part of solution and create a patch of it, copying out a smaller part of a larger solution. For more information on solutions check out the links below
- Create patches to simplify solution updates
- Use segmented solutions and patches to simplify solution updates
- Solution Patching in Microsoft Dynamics CRM 2016
- CRM 2016 Solution Segmentation for The Rest of Us
This video walks you through patches. Patches allows you to choose components and sub-components. This allows you to select individual fields and not all fields, reducing the time to deploy and potential conflicts.
Patches allows developers to update a small part of the solution, create a patch and deploy those changes. Previously if you wanted to update an entity, you had to take allthe fields, all the views and other related components for the entity.As with all customisations be consistent in a project.
solutions can cause problems, some common problems are
- CRM 2011 — Solution not importing — Timeout errors
- CRM 2011 — SQL error while importing solution in crm 2011
- CRM2011 OptionSetId Cannot be Changed when Importing Unmanaged Solution
- CRM 2011 — error when importing solution
Solutions can get out of sync because developers added fields on the development environment and QA environment.
Out of sync problems can be avoided by using only one route for customisations being created, starting with DEV and flowing through Dynamics environments until you get to production.
you can find common questions on solutions in the two blog posts below
other blog posts on solutions
- CRM 2013 — Understanding Solutions and how they work
- CRM 2011 — Solutions and publisher prefix
- You can’t import a CRM 2011 solution into CRM 2015
- CRM 2011/2013 — Progress of solution import
- CRM 2013 — Exporting your changes in a solution from your CRM 2013 trial
Dynamics 365 solutions such as workflows and plugins configuration records in Microsoft Dynamics CRM, if the guid is different between Dynamics 365 instances the workflow and plugin won’t work.
The blog post below discusses how you can copy data between Dynamics 365 environments and keep the same guids
The article discusses the Dynamics CRM Configuration Data Mover v1.10, a good way to move configuration data between Dynamics 365 environments keeping the same guids.
Release management and deployments
Solutions are the main mechanism to move customisations from one CRM environment to another, best practices for CRM deployments but these focus on the manual deployment process. Manual deployment process has been used on the projects I worked on because no project manager or CRM practice wanted to invest time in investigating and setting up automated and scripted deployments.
This is a mistake, Dynamics 365 deployments should use the SolutionPackager and packagedeployer which automate deploying and data, saving developers from the boring task of deploying, reduce errors and remove data errors. This is a gap in my knowledge which I plan to investigate.
If a development task can automated, it should be automated#HoskWisdom
Solution architecture in my experience
Below I list the different methods of organising solution on projects I worked on. These projects were CRM 2011, CRM 2013 and CRM 2015 and before patch solutions.
You can organise solutions to releases/phases/sprints, including the changes for each major release of functionality. During development it’s easy for developers to work with the solution. Developers with experience of the project will find release/sprint solutions easy to understand but new developers won’t find the solution content obvious.
The release solution can lead to many solution files because solutions are not reused but it can stop solution files becoming too large.
- Release 22.214.171.124
- Release 126.96.36.199
- Release 188.8.131.52
- You see what changes were in each release/version/sprint
- You deploy smaller solutions, containing only customisations which changed
- It’s easy to understand
- You can end up with ever-growing collection of solutions
- It can take a long time to create new environments because you need to import each solution in order
- The solutions depend on previous versions
- Solutions can be confusing because they don’t contain all the customisations being used, it’s difficult to navigate to the right customisation
Solutions by customisation type
A few projects organise solution files by customisation type
- Entities and fields
- Custom workflows
- Easy for developers to understand where to put customisations
- The separate solutions are dependent on each other
- More solutions, more time deploying
You just have one solution containing all customisations
- Simple to navigate
- The solution can grow in size and there are some size restrictions
- Potentially complex having all customisations in one solution
- The solution can take a long time to import
- Historically there are problems with solution timing out (before CRM 2016)
Other solution strategies
I haven’t used the solution architecture below but I can see they could be useful in the right scenario
Reusable Solutions (managed)
It’s a great idea to create focused managed solutions for reusable functionality. Functionality like number sequence or a system configuration settings entity would be great to have as a reusable solution which could be used in many projects.
You might need to make functionality generic to fit into it’s own solution, untangling the dependencies from an existing project but the benefits will be you can slot the functionality into any project and potentially sell it to customers.
- Small focused solutions, good programming practice
- Reusuable solutions and functionality between projects
- Maintain a separate solution
- If solution needs to be different you need to branch the solution
If you have a Dynamics 365 project which will be deployed to multiple Dynamics 365 instances, it could be for different companies in the same group. The companies could 50 percent of the same functionality and 50 percent different. In this scenario you could have a core solution for the functionality which is the same and separate solutions for the organisation specific functionality.
- Organises the solution logically and easily understood
- Difficult to keep solutions from being dependent on each other
- Lots of solutions to manage and support
Two solutions, one containing system entities and another containing custom entities. I’ve not seen a project use this but I have heard of someone else using it.
- You can keep your custom entities and customisation separate from default entities
- Is this needlessly complex
Futher reading on solution management
I have gone through my experience but I also found this white paper which discusses
ALM for Microsoft Dynamics CRM 2011: CRM Solution Lifecycle Management
Don’t be fooled by the CRM 2011, it is an in-depth analysis of Dynamics 365 solutions and release management.
A summary of the white paper can be found here by Blake Scarlavai
One of the traditional reasons for creating multiple solutions is large solutions would cause timeout errors when importing. The easiest way to avoid time out problems is to split the solution into multiple smaller solutions.
Microsoft added patch solutions, allowing you to import a smaller sub components.
Patches remove the need to create specific hotfix and version/sprint solutions because this is done using patch solutions at a more granular sub component/asset level.
Solutions organised into entities and code (plugins/workflows etc) solutions, the benefitis an organisational benefit and ease of navigation.
How should we organise solutions
There is no one best practice for organising Dynamics 365 solutions, solution architecture should be based on the requirements for the project.
I like creating small focused reusable solutions which you can use on various projects, a company could build up a collection of solutions to use in new projects, it saves time and creates a standard approach to the functionality spanning projects. This would help to answer the question Why isn’t code reused in Microsoft Dynamic CRM projects?
The solution design of a project rarely creates separate solutions and the solutions depend on each. Having multiple solutions is a way of organising customisations to move customisations between Dynamics 365 instances.
There are legitimate reasons for having multiple solutions which could be having a number of Dynamics 365 instances which need a core solution.
Patching means the common problem of solution timeout isn’t an issue.
Considering the different options of which solutions you create, for general projects the advantages and disadvantages are similar. There isn’t a definitive winner in terms of advantages but most companies will have a standard way of organizing solutions for general Dynamics 365 projects (e.g. usually plugins, entities, reports, workflows). Consistency allows developers to work on different projects with minimal disruption
When assessing how you should organise your solutions, think about what you are trying to acheive and don’t forget you can always change it in the future.
To save time and efficiency, how you manage your solution is not as important as how you build and deploy those solutions. In a large project with multiple environments, a developer can spend hours manually deploying solutions through the various environments.
The SolutionPackager allows you package solutions into XML Fragaments and linked with TFS to automate the build process. This can be used with PackDeployer Automating the build and deployment process using CRM Package Deployer could save hours, reducing deployment errors. The CRM PackageDeployer also packages data, to avoid the manual data deployments and guid problems.