Coming from SharePoint, solutions are not new to me. In fact it was the only good way in SharePoint to distribute your functionality across servers. In SharePoint building a solution was a tedious task; tons of XML to write, custom event receivers (on premise), solution scopes, dependencies, etc.
When I was introduced to solutions in CRM, I was amazed. How could this be so simple? Where did the SharePoint team go wrong? But then I took another look at solutions and noticed that there are unmanaged and managed solutions. What’s the difference and how could I benefit from it?
In order to understand the concept of solutions, it is time to go back to the fundamentals…
Solutions and layers
According to the “ALM for Microsoft CRM 2011:CRM Solution Lifecycle Management” document, a Solution is a container for functionality that needs to be deployed as a single unit. This means that when I start doing customizations and development within CRM, I should open an existing solution or create a new solution.
As soon as I do my customizations outside my solution, the customizations are done in the default solution of CRM. The default solution can be seen as the base layer of the CRM system. In terms of maintainability you don’t want to do modifcations on the base layer, as this affects the default behaviour and functionality of the system.
The idea of solutions is that you can build up your environment in layers, each layer is adding new functionality. All layers together, form the system you are using.
The advantage to work with multiple solutions is that it is easy to apply bug fixes or upgrades on the environment. You can simply upload an updated solution and activate it. The system will start to process and reapply all upgrades from the default solution up.
The beauty of this mechanism is that it doesn’t matter in what sequence you apply the solutions, in the end the result will be the same. As soon as you upload a new version of a solution, the old version disappears from the system which means “no more version hell”. *applause*
The downside of the mechanism is that all solutions are stacked towards the end result, there is no standard mechanism of removing fields from entities, webresources etc. In the end this can clutter up the system.
Managed versus Unmanaged
Where CRM’s solution mechanism differs from the solution mechanism in SharePoint, is that there are two kinds of solutions, managed and unmanaged. The difference between a managed and an unmanaged solution, is that the unmanaged solution can be changed by the users. The managed solution is sealed and cannot be changed by the users.
The official CRM ALM documentation says that unmanaged solutions are only using within the development enviroment. Once the developers are done, the solution is packaged into a managed solution and deployed to test, acceptance and production. In case something is wrong with the package, fixes are made in development and the managed deployment cycle starts all over.
This might work for environments in which development is done incidentally or where development is done following a fixed release calendar. In an agile environment the software development process is a continuous process, this means that software is being developed, tested and used at the same time.
Suppose you create a managed solution and deploy the package to test, acceptance and production, you might get in trouble when a blocking issue occurs in the production environment.
In that case it would be convenient to copy the solution in production to an alternate acceptance test environment. In that environment the issue could be resolved and the solution could be tested on the alternate production environment. Once the solution is approved, the solution is installed in the official production environment and the changes are implemented in the development environment.
Using managed solutions this wouldn’t be possible! Heck, the agile process wouldn’t be possible.
Depending on your development process you might reconsider to work with managed or unmanaged solutions.