Tuesday, January 3, 2012

Managed or unmanaged solutions in CRM 2011: Best Practices

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 directly once they are managed. In order to delete such components from managed solutions you need to follow a set of steps described here. Feel free to add your personal experiences to this post!

20 comments:

  1. Hi Gonzalo,
    Managed solutions do look tempting after reading about their benefits. But when you start putting them in practice at the enterprise level, you soon realise the amount of pain they cause in the production environments. One does not see the downside of managed solutions until they have to "update" a heavily customised managed solution.

    There are numerous scenarios on the 'forums' where the unexplained behaviour of Managed Solutions kick in, cited few links below
    http://social.microsoft.com/Forums/en/crmdeployment/thread/57e87dc5-e01c-42a3-b436-e9cce17b21e1
    http://social.microsoft.com/Forums/en-IE/crmdeployment/thread/7c9c3d07-50fa-4280-969d-fae1ecfee890
    http://social.microsoft.com/Forums/en/crmdevelopment/thread/80f9be38-1e55-4de8-953c-2143fb7e5510
    http://social.microsoft.com/Forums/et-EE/crmdevelopment/thread/b8c8ccfa-8d8e-441b-b475-938f611b7fde

    "Capability to roll back to a previous version of the managed solution" - How feasible is this feature, when you know the moment to uninstall the managed solution for rollback, you are going to lose all your enterprise data.

    I am speaking from experience after having heavily used managed solutions and would not recommend them as they take away the flexibility from the deployment process and adds humungous burden on the deployment process.

    Thanks,

    ReplyDelete
  2. With the disadvantage are you talking about taking the unmanaged solution, removing an entity, updating the solutions version number and exporting as a managed solution. Then when we import the upgraded managed solution over the top of a previous version its not removing the entity as part of the update?

    ReplyDelete
  3. Hi David, unfortunately not, importing a solution (managed or unmanaged) will never result in the removal of an entity, even if the entity is not in the solution anymore.

    ReplyDelete
    Replies
    1. It's SOOO important to note however when saying this Gonzalo that when using MANAGED solutions in that scenario - you're stuck with that solution component in forward facing environments. When you go into that solution component expecting to remove it manually, you can only do so in an unmanaged production environment :)

      Delete
  4. Hi Luka, thanks for your feedback. I would like to understand specifically what pains and burdens you are talking about which do not exist in the case of unmanaged solutions.
    I understand that there is a restriction in which certain managed components cannot be deleted unless you remove the entire solution (which is not the case of unmanaged solutions). However, the other 3 links that you provided are mostly problems that are not specific to the use of managed solutions or come as a result of the miss-use of managed solutions. Definitely managed solutions give you the option of shooting yourself in the foot, that's why it is important to understand how to use them and how not to use them.

    ReplyDelete
  5. Hi,

    We recintly installed an unmanaged solution. We now need a managed one to add the multiple layer feature. One person told me we need to do all the customization back to the managed version, there were no way to copy things between managed and unmanaged solution. Is he right?

    Thanks.

    Julie

    ReplyDelete
  6. Hi Julie,

    You can always convert an unamanged component to managed. All you need to do is to add all the components you want to convert to a solution. Then export the solution as managed and store the zip file somewhere. Then delete the solution from the system and import the managed solution you just exported. This will convert your customizations to managed. It would be a good idea to take a backup before so you can always roll back if something goes wrong!

    ReplyDelete
  7. Peter BjörkmarkerJune 6, 2012 at 9:03 AM

    Having similiar experiences to Luka I would argue that managed solutions is for a special corner case rather than the standard way to go. It would need to handle true version control and merging to be really useful. The corner scenario where it seems to do its job reasonably well is for pure ISV scenarios/marketplace . This, from what I am guessing also seem to have been the core design goal.

    To counter your arguments:
    Solutions can be installed into multiple layers.
    You can build solutions on top of other solutions (solution-level dependencies).

    Why would you want to create artificial dependencies? I have tested a scenario of having a core solution and applying different business solutions on top of those. However, in practice I have always gotten issues with managed components when adding a new version of changes in the core solution. Unless of course you keep components completely separate. However, that pretty much invalidates the whole idea of a core solution. I could see it being used for branching and merging in such scenarios once we get more fine grained version control (i.e. the ability to merge views, forms, etc).

    Additional change management control.
    If you have a process issue where you can't trust internal IT I would really urge you to fix the process. If you wont let them add that field because of managed solutions you can be sure they will try to update the tables in the database instead. Or maybe uninstall your managed solution without understanding what they are doing. Also, just removing them from the system customizer/sys admin role is easier and quicker and a lot less to managed than all the properties you can set.

    Option to turn on managed properties on solution components.
    I would rather work with a client that I trust than look down the system so they cant do those changes. For the ISV scenario it does make sense. For any kind of consulting engagement, it just limits my options and doesn't really help.


    Capability to uninstall a solution and roll-back to a previous customization state.
    So uninstall sounds like a good idea in the ISV scenario. Tested the solution, didn't like it, uninstall and everything is back to normal. Again in an enterprise scenario, I would really want to know what data I will be losing. Also retracing a failed deployment would be another argument. However, how often do we actually do that? I see people issues hotfixes instead, not pulling back what they just released.

    Solution publisher can truly own solution components.
    Again, nice for the ISV. For consulting engagements, it just gives us the ability to add extra technical limitations.

    The concept is very promising but we would really need something that gives us true version control and layering of all components before it is useful. Hoping that what the PG has in mind.

    Unmanaged solutions frees a lot of time to improve processes and build a good system. Even the default solution is a good option as it is today. The named unmanaged solution is a nice way of keeping things a bit tidier in terms of knowing what you have actually customized. However, with a default solution, it simplifies the process and my devs don't have to remember to add the components in the right places (and the customize ribbon works nicer too). Also I can be sure that I deploy exactly the same components from dev to test to uat to production, which gives me more control and as a result better quality.

    ReplyDelete
  8. Hi Luka,

    I don't think managed solutions is a special corner case, there is a lot more into solutions than a simple transport mechanism. What you are suggesting is to continue to use the CRM 4.0 approach of transporting everything in one single layer that gets overwritten for each import. Using managed solution is not meant to cost you more time, quite the contrary, you should become more efficient; in my experience, using the "Default" solution like you mention is actually harder to maintain and ends up getting messy for large projects and thus becomes costly. Point taken that there are bugs with managed solutions but most of these have been fixed in the early update rollups and keep in mind that although managed solution provides additional flexibility, it does not mean you are forced to use the additional features (such as managed properties), you need to figure out in which cases those features make sense and in which ones it does not.

    I appreciate your thorough feedback on this post!

    ReplyDelete
  9. Thanks for solution.
    The second affect of a quality CRM application is realized as a result of the automation of each business process; creating a series of benefits, which include the integration of systems that are immune from system deviation.

    ReplyDelete
  10. Hello Gonzalo,
    As you I like working with managed solutions. I think they have some advantages above unmanaged solutions, but if after having deployed the solution the customer makes certain changes to the entities (fields, views, etc) then you have a problem to maintain the solution as managed, because if you import the solution as managed and you publish it in their environment after the customer have been modifying certain entities, some changes do not apply more.
    What do you think would be in these cases the best approach? Does creating a new solution in dev support and export as unmanaged?
    I hope your suggestions.
    Thank you for your contribution, you have really interesting topics within CRM.

    ReplyDelete
  11. Hi seamoc,
    Are you talking for example when they change a form directly in production environment?

    ReplyDelete
  12. It seems to me that managing managed solutions is a pain. This reminded me of a slogan on a meeting via Compuserver (prior to Internet) over 30 years ago: "Using a computer should be easier than not using a computer." If a software is difficult to use, and then it failed as a software. If a feature is difficult to use, and then it failed as a feature.

    What is wrong with using unmanaged solutions? What advantages do managed solutions have over unmanaged solutions? If managed solutions are difficult to update/maintain, and then it is not worth to use managed solutions.

    ReplyDelete
  13. Hi Gonzalo, Great post! very clear! but I still have douths, I have this situation with the solutions, I am in development environment, I have created a unmanaged solution with all the customization after that I used Parrot (Webforbis) which is managed solution, after I imported Parrot, I created another unmanaged solution including some fields from parrot when I tried to import the new unmagened solution into another CRM online, I couldn't do it, I do not want to create a managed solution because it could be more changes and more stages, What should you suggest when it comes to all that?

    ReplyDelete
  14. Having similiar experiences to Luka I would argue that managed solutions is for a special corner case rather than the standard way to go. It would need to handle true version control and merging to be really useful. The corner scenario where it seems to do its job reasonably well is for pure ISV scenarios/marketplace . This, from what I am guessing also seem to have been the core design goal.

    To counter your arguments:
    Solutions can be installed into multiple layers.
    You can build solutions on top of other solutions (solution-level dependencies).

    Why would you want to create artificial dependencies? I have tested a scenario of having a core solution and applying different business solutions on top of those. However, in practice I have always gotten issues with managed components when adding a new version of changes in the core solution. Unless of course you keep components completely separate. However, that pretty much invalidates the whole idea of a core solution. I could see it being used for branching and merging in such scenarios once we get more fine grained version control (i.e. the ability to merge views, forms, etc).

    Additional change management control.
    If you have a process issue where you can't trust internal IT I would really urge you to fix the process. If you wont let them add that field because of managed solutions you can be sure they will try to update the tables in the database instead. Or maybe uninstall your managed solution without understanding what they are doing. Also, just removing them from the system customizer/sys admin role is easier and quicker and a lot less to managed than all the properties you can set.

    Option to turn on managed properties on solution components.
    I would rather work with a client that I trust than look down the system so they cant do those changes. For the ISV scenario it does make sense. For any kind of consulting engagement, it just limits my options and doesn't really help.


    Capability to uninstall a solution and roll-back to a previous customization state.
    So uninstall sounds like a good idea in the ISV scenario. Tested the solution, didn't like it, uninstall and everything is back to normal. Again in an enterprise scenario, I would really want to know what data I will be losing. Also retracing a failed deployment would be another argument. However, how often do we actually do that? I see people issues hotfixes instead, not pulling back what they just released.

    Solution publisher can truly own solution components.
    Again, nice for the ISV. For consulting engagements, it just gives us the ability to add extra technical limitations.

    The concept is very promising but we would really need something that gives us true version control and layering of all components before it is useful. Hoping that what the PG has in mind.

    Unmanaged solutions frees a lot of time to improve processes and build a good system. Even the default solution is a good option as it is today. The named unmanaged solution is a nice way of keeping things a bit tidier in terms of knowing what you have actually customized. However, with a default solution, it simplifies the process and my devs don't have to remember to add the components in the right places (and the customize ribbon works nicer too). Also I can be sure that I deploy exactly the same components from dev to test to uat to production, which gives me more control and as a result better quality.

    ReplyDelete
    Replies
    1. What do you do when one managed solution is referencing components of another managed solution, and you would like to uninstall one of the solution? You cannot uninstall either one, because this situation caused a deadlock between the two managed solution.

      Delete
  15. Great post and comments! Thank you all for sharing your insights on this topic, found it very helpful!

    ReplyDelete
  16. Great post, however I just want to ask a question to be certain...

    Scenario: I have sandbox and Production environments. I export a solution containing customisations to the forms of the Account entity and a custom entity, say Project, as a managed solution. I then import this managed solution into Production, which brings the new customisations into Production. What would happen if I were to delete (uninstall) the managed solution? Would the custom entity be deleted (as the managed solution contains the entity component) or just the customisations to the entity? And what would happen with the customisations made to the Account form?

    Thanks

    ReplyDelete
  17. Hi Gonzalo, very helpful post to understand difference between managed and Unmanaged solution. I need one suggestion from you.

    There is a scenario of CRM 2013 on-premise. We are developing a managed solution for a client who is currently running on 1.0.0.5 version of their basic solution.

    When I had started development few months ago, they provided their basic solution of version 1.0.0.2. Now, they have installed my managed solution on their environment and they are complaining about entities gets overwritten.

    What should be the best way to get solution to this problem now? As part of our solution, we have created plugins, dialogs, workflow activities and few custom entities.

    1. I have first we need to get their latest solution and install on our development environment.
    2. Do we need to rework for all the things we had done?

    You answer will be much appreciated on this.

    Thank you,

    ReplyDelete
  18. I too am against Managed solution except if you are a third party provider for the reasons outlined above.

    ReplyDelete