Solutions and layering are fundamental concepts within CRM that need to be fully appreciated and understood to construct an approach to lifecycle management for Dynamics CRM applications. There are three key concepts that need to be introduced:
§ Solution Packages: Act as containers for functionality required to be deployed as a unit
§ Layers: The consequence of a specific component being affected by change within one or more solutions
§ Managed Properties: The mechanism to control how layers interact with each other
Note: This appendix provides a “quick reference” overview of more detailed information that is presented in the Dynamics CRM 2011 SDK, in the section Package and Distribute Extensions.
Solution packages are the container mechanism to transport Dynamics CRM configuration and customization between organizations. There are two types, unmanaged and managed.
§ Contains only customizations from the unmanaged layer
§ Will not include dependent components
§ Imports only into the unmanaged layer:
• Ideal during development
• Everything within could be changed
• Overwrites existing customizations
§ Contains a complete copy of each component
§ Will get its own layer on import.
§ Analogous to an installer “.msi” file; it is a distribution package.
§ Contents cannot be directly changed.
o This does not mean DRM.
§ Components may be customized where managed properties allow.
§ Contains only deltas for component that supports merging (FormXML, Ribbon & Sitemap).
Layers should be considered on a per-component basis. Although typically drawn to convey the effect of a solution on another solution, this is always at a component level.
§ There is only one. It always exists.
§ All customizations made on this server/organization will reside here.
§ “Solutions” exist here as containers.
• Ownership by solutions is weak; by-reference only.
• No independence between solutions. If one component exists in two solutions, they both see the current state of the component equally.
§ New customizations made will trump all prior customizations. (They override the lower layers.)
§ Customizations cannot be undone, but they can be deleted.
§ There can be many:
o Always one for the “system” solution.
o Discrete layer for each managed solution package imported (at a per-component level).
§ Only created by importing a managed solution.
§ Time of import sets order of precedence.
§ You cannot customize components inside the layer.*
§ They can be deleted, replaced, and versioned.
§ Deleting a layer may delete data.
Managed properties control how layers interact with each other; they control the level of customization achievable on top of components from a managed solution that has been imported. After releasing a managed solution, the managed properties can only be changed to reduce how restrictive they are.
§ Control order of precedence (which customizations to allow on top of an imported solution’s managed layer).
§ The ability to customize cannot be removed or disabled during solution update.
§ The ability to customize can be enabled during solution update.
§ The default ability to customize is fully customizable.
In general, if the consumers of the solution are not known or trusted or the changes that may be made could break the solution, it is recommended to lock down the managed properties for the solution. These managed properties can be opened back up to enable specific components to be customized at a later date as needed.
New customizations trump all prior customizations, overriding the lower layers.
Important: Changes applied by importing an unmanaged solution cannot be uninstalled. Do not install an unmanaged solution if you want to roll back the changes.
Managed (No Overwrite)
§ Customizations in unmanaged layer are preserved.
§ Importing newer versions creates new managed layers directly above the previous version’s managed layer.
§ Importing the same version replaces contents within the existing layer.
§ Importing cannot remove pre-existing components.
§ Generate and import a minimal solution to “hotfix” a larger solution.
§ Reports, E-mail templates, and plug-in assemblies skip updates if they are not the “top” layer.
The recommended approach is to always preserve customizations (no overwrite). If the updates are mandatory for the solution to function appropriately, then overwrite is needed:
§ Replaces the content of the “unmanaged” layer and makes the managed solution the top layer.
§ Ensures that updates included in the solution are effective.
§ Overwrites all customizations and should be used with caution.
§ Greater use of managed properties makes this approach less necessary.
The solutions framework automatically tracks dependencies across components.
§ The following operations perform dependency checks/operations:
• Individual components: CRUD, Add Existing (to a solution).
• Solution: Import, Export, Delete (uninstall).
§ Dependencies are version agnostic. As long as the unique name/id of the component and the package type matches, a dependency is considered valid.
• Managed components cannot depend on unmanaged components.
§ Components in managed layers will be owned by the solution publisher.
§ Publisher owns the component, not the solution.
§ Components with same name and publisher will be considered the same thing.
§ Removing a solution does not remove a component when it is referenced by another solution using the same, shared publisher.
§ Be wary of predictable names and collisions.
• For web-resources, create names that imply virtual directories