What’s the best way to organise solutions in Microsoft Dynamics 365
--
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.
Solutions
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
and msdn — Introduction to solutions
Solution patches
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
