There are numerous blog posts on this subject. Not long ago a local Swedish MVP Gustaf Westerlund posted on the subject (here), and there is also a brilliant post by Gonzalo Ruiz (here). Add to this the official version by Microsoft found in the SDK here and here.
In several projects I have worked with the model “un-managed for development / managed for production” and have found a few pro's’ and cons’ with this model. First, lets set the scene.
Un-managed solutions for development
In this system we have a number of components required for the development of the solution, including the Microsoft Activity Feeds solution, a Ribbon Editor and a Sitemap Editor. We also have installed the managed solution that includes a set of development utilities and components that we use to speed up development. This form of Solution Libraries are an effective way to compartmentalize your work.
When this solution is ready for test, and later on production, we first ensure that all pre-requisites are installed in the production system. This would include the Activity Feeds solution and the solution libraries required for the main solution. These are installed as managed solutions in the production environment.
When that is done, we export the main solution (the nameless one in the above picture) as a managed solution and import it into the production environment.
Managed solutions for production
In test and production all solutions are managed and we do not allow any customizations or fiddling with the setup. This will ensure that all solutions are correctly merged, and – very important – that additional changes cannot be done during test or production.
Pros’ and cons’
What is the benefit of working in this way? In certain cases it’s easier to just work in a single un-managed solution, and publish changes as you go. In certain cases yes, but just as often not. Consider the following:
- You add the Microsoft Activity Feeds solution to your system – it is a managed solution.
- You the start customizing the system in your own – un-managed – solution. During the project, you do a few modifications to the sitemap and include the sitemap in your un-managed solution.
- You export your un-managed solution and import is as un-managed into the test or production environment.
What happens then is that your modified sitemap will overwrite the existing sitemap in production, and the Activity Feeds part of the sitemap will then be removed. You can avoid this behavior by including the Activity Feeds entities in your own un-managed solution, but that will create a unnecessary dependency in your solution. Why is this dependency “unnecessary”?
What dependencies should be included?
When you create your solution you obviously need to include all the components (entities, web resources, plugins, processes etc) that are required for the solution. But should you also always include all the required dependencies? I think not, not if the dependencies are already installed in the destination (i.e. test or production) system. This goes for all default – and un-customized – entities and for any component included in a managed solutions that is a dependency.
Having separated your solutions allows you to:
- Update them separately, e.g. when there is an update to the Activity Feeds solution it can be added without your whole solution being affected.
- Remove a solution; when a solution component is no longer required it can be removed. E.g. the do not require the Activity Feeds functionality any more. Just remove that solution.
- It’s quicker; the smaller you make your solutions, the quicker they are to publish, export and import.
When working with multiple managed solutions you need to be aware of the rules and consequences of solution layering and merging. Information can be found here.
Planning ahead
What we are seeing now is a change in the development of larger CRM and XRM deployments. Initially one consultant might be responsible for the initial setup, customization and development of the deployment. But over time the customer – or other consultants – can be involved in further development or in the installation of third-party products and add-ons from the Dynamics Marketplace.
The initial consultant will not stay “in control” of the deployment, as might have been the case previously. In order to secure a good, stable and long-living deployment, ensure that your initial structuring and solution architecture allows for multiple applications and multiple vendors.