When it comes to the solutions framework in CRM 2011 the question I get asked the most often is: “Should I use a managed or unmanaged solution?” and like all questions around best practices the answer is often “it depends”. The differences between the two are quite fundamental; however, there is still plenty of confusion in the community around this. A Microsoft colleague once gave a great analogy I would like to quote: Think of unmanaged solutions as source code and think of managed solutions as compiled, versioned and signed assemblies.

Unmanaged solutions

Similar to source code when writing a program, unmanaged solutions is your only choice during development: Every solution was once an unmanaged solution just like any binary was once source code. As long as your solution remains unmanaged, it is “open” (editable) so you can add/remove/edit components, update the publisher, the configuration and the managed properties of the solution. You will also be able to update the version of the solution and you will be able to export it. Additionally, if you are working on a multi-language solution, you can export and import the solution translation labels. Since CRM solutions now contain the translation labels in the same zip file, you should always import your labels into the unmanaged version of the solution; this way, each time you export the solution it will contain all the labels so you will not need to repeat the translation steps for every environment.

Another typical use of unmanaged solutions is to work as an integration solution to which multiple developers or teams contribute with different components. However, once your solution is ready to go into UAT or production, the solution should be installed as managed because it will no longer need to be editable, this will allow a more rigorous release control because it will force all updates to be made in a development environment and then promoted to UAT/Production as opposed to making direct changes in production environments (a fundamental best practice in IT).

Managed solutions

These are similar to .net assemblies in the sense that you do not directly edit a managed solution; it is “closed” to development. Additionally, managed solutions provide a sort of read-only signature which includes the version and the publisher of the solution. You should always make use of a consistent publisher to uniquely identify you or your company as the entity that released the solution; there are also additional privileges granted to the solution when the publisher matches the publisher of an existing managed solution in the system and it works in a similar (but more primitive) way as strong name validation in .net assemblies.

One of the advantages of leveraging managed solutions is the managed properties feature. Managed properties allow you to restrict changes in the solution by an unauthorized publisher. This is particularly useful if you have an undisciplined IT department that does not apply a thorough change management process when making changes to a solution. By making use of managed properties you can ensure that you (as the solution publisher) will remain in full control of the solution and prevent other from making breaking changes to your solution.

Another great feature of managed solutions is that it is able to create layers of customizations. In the unmanaged model, all customizations are at the same layer, so making any customization will overwrite what is currently in the system. However, managed solutions have the capability to keep track of which customizations belong to which solution. To the end user, only the top layer (latest solution installed) is visible, but under that layer there can be multiple layers of customizations so you can build a solution on top of another solution without mixing up all the changes. You can think of this capability as using reference assemblies in .net. You can develop a solution by referencing an existing managed solution. The end result is that you will have two solutions (one depends on another) but there can be a clear distinction of which customizations belong to which solution. Solution layering also means that you can revert-back to a previous system state. If you uninstall a solution, all its components will be removed but the customizations from other solutions in a lower layer will surface back.

To summarize, these are some of the reasons why I very much prefer to use managed solutions in all environments that are not development environments:

• Solutions can be installed into multiple layers.
• You can build solutions on top of other solutions (solution-level dependencies).
• Additional change management control.
• Option to turn on managed properties on solution components.
• Capability to uninstall a solution and roll-back to a previous customization state.
• Solution publisher can truly own solution components.

The only disadvantage I have found so far with managed solutions is that certain solution components, such as entities, attributes and reports cannot be deleted once they are managed. You are forced to uninstall the entire solution and re-install a version that does not contain the components which you want to remove. Feel free to add your personal experiences to this post!