Managed Solutions in MS Dynamics CRM
All CRM developers knows and understand difference between managed and unmanaged solutions in CRM. If your project uses managed solutions next details and tips can help you.
Additive nature of solution
Nothing can be deleted from system with solution import. This property is valid for both types of solutions. But it's not a problem, because it's easy to delete elements from managed solution with "Holding solution" technique (or just delete for unmanaged solution components).
This property is advantage for deployment of managed solution. Unlike unmanaged solution, it's complex to update only set of components with managed solution. In huge projects, managed solution(s) deployment takes really long time. And it's becomes frustrating, when import of one small script or entity change requires to re-import whole solution. Of course it's possible to change source unmanaged solution by removal of all unused components, and export small version of managed solution. But, in this case, information about changed during the solution development will be lost. There are two simple ways to resolve this problem:
This property is advantage for deployment of managed solution. Unlike unmanaged solution, it's complex to update only set of components with managed solution. In huge projects, managed solution(s) deployment takes really long time. And it's becomes frustrating, when import of one small script or entity change requires to re-import whole solution. Of course it's possible to change source unmanaged solution by removal of all unused components, and export small version of managed solution. But, in this case, information about changed during the solution development will be lost. There are two simple ways to resolve this problem:
- Keep all changed components on mirrored unmanaged solution in the development organization. Idea is simple: two unmanaged solutions in system, just duplicate component linking to mirror solution and you'll always will have list of affected by your development components.
- Replace solution header. Here is used the same idea as in "Holding solution", but in other direction.
- Create unmanaged solution with components, you want to update. It's important to use the same publisher, which is used in your main solution
- Export new solution as managed
- Replace UniqueName tag value in Solution.xml file to UniqueName of you main solution
Keep plugins separately
It's better to keep plugins in separate solution. Plugin assembly import takes a lot of resources and often increases import solution time, and increases chances of error production in import process. But according to dependencies in this solution also should be placed SDKMesageSteps and workflows. Because both of them depends of Assembly (workflows can contains custom steps). This solution should be imported after customization solution, because SDKMesageSteps and workflows depends on customizations.
Order is important
In projects with more than one managed solution, try to keep order of importing of managed solutions. Managed solutions contains only changes and not the whole definition of components (SiteMap, ApplicationRibbon, Ribbons, FormXML). Some of this components are dynamically generated, for some components main point of this generation is value in column ModifiedOn in table SolutionBase. In case of change solution import order, changes from latest imported values becomes more valuable. It's easy to prove if you have two managed solutions with different buttons on ApplicationRibbon, re-import of each solution will bring its buttons on ApplicationRibbon and hides changes of second solution.
Comments
Post a Comment