Solutions can be packaged as "unmanaged" or as "managed". Having a good understanding of the capabilities and limitations of each package type is very important for developers and CRM administrators, as it has deep implications on the way that CRM 2011 processes components. Let's take a look at the two different package types in detail.
It doesn't matter how you are creating the initial solution, every newly-solution is unmanaged. The new solution is just a container that holds references to components in the system. Adding components to the solution is as simple as selecting from any existing components, or creating new components from the context of the solution. Unmanaged solutions only have a reference to components in the system, and do not have a copy of a component. Multiple unmanaged solutions can have a reference to the same component, and changes made to the component will be visible in all other solutions regardless, of the solution that we performed the changes on. Exporting any solution that contains the component will export all of the changes made, irrespective of which unmanaged solution the changes were performed on. The following figure provides a visual representation of an unmanaged solution:
Any time we need to perform direct modifications to the solution metadata, or add or remove components, we will need to do so on the unmanaged solution.
Whenever we need to transport the solution from one development environment to another environment, and we intend to perform additional changes to the solution, we need to transport it as unmanaged. Importing an unmanaged solution is similar to how Microsoft Dynamics CRM 4.0 works, and always overwrites the components that it touches. When deleting an unmanaged solution, only the container is deleted, and the components will remain in the system. So in other words, components installed by an unmanaged solution cannot be uninstalled.
Managed solutions were designed for the final distribution of components. After initial development is done and the solution is ready to be consumed by customers we need to export it as managed. When a solution is exported as managed and subsequently imported in a different organization, the definition of the solution is locked and components cannot be added or removed. Components can still be customized, but customizations need to be carried out in an unmanaged solution. All changes are tracked as customizations performed "on top" of the solution:
The layering approach allows solutions to be built on top of each other, and also provides flexibility for end-customers to tailor the solution to fit their needs.
Another benefit of managed solutions is that they can be uninstalled. To uninstall a managed solution, we just need to delete the solution. Deleting a managed solution will delete all of its components, and will roll back any changes that were performed by the solution.
When exporting a solution as managed, Microsoft Dynamics CRM 2011 automatically figures out the items should be included in the customization. Some components in the solution file contain the delta whereas some components contain everything. CRM automatically figures out the appropriate action when importing a managed solution, some components get the delta whereas some components get overwritten. The following table shows the import behaviors for each of the solution components:
|
Component |
Export Behavior |
Import Behavior |
|---|---|---|
|
Entity | ||
|
Attributes |
Delta |
Delta |
|
Forms |
Delta |
Delta |
|
Views |
Full |
Overwritten |
|
Charts |
Full |
Overwritten |
|
Web Resources |
Full |
Isolated |
|
Reports |
Full |
Overwritten |
|
Processes |
Full |
Overwritten |
|
Global Option Sets |
Delta |
Delta |
|
Security Roles |
Full |
Overwritten |
|
Field Security Profile |
Full |
Overwritten |
|
Site Map |
Full |
Overwritten |
|
Application Ribbon |
Delta |
Delta |
Whenever we deploy an update to a managed solution, the changes are deployed to the corresponding layer, which allows the system to preserve customizations instead of blowing them. The system will automatically detect that the solution is already installed in the system and prompt us to confirm the installation of the update. We have the choice to preserve the existing customizations or replace them.
The solutions framework is optimized to handle updates to full solutions. Creating an update for a solution can be as simple as changing the version number of the solution in the development environment, performing the changes, packaging the solution, and delivering it to the customer. When we apply the update, the solutions framework will deploy the update and do its best to preserve the existing customizations. This approach works just fine when solutions have been properly modularized, but it can become a challenge for solutions that have a large number of components and only a small subset of those need to be mandatorily updated. This is commonly known as a "patch".
The best approach to "patch" a solution is to:
- Create another solution in the same organization that contains the solution to be patched. Let's call it the "patch" solution. The solution publisher used to create the patch solution must be exactly the same as the one used to create the original solution, otherwise the update might be prevented during import due to managed properties (see the managed properties section).
- In the patch solution, only include (add existing) the components that need to be updated.
- Perform the changes and package the update as a managed solution.
- Deliver the patch to the customer.
The "patch" approach allows us to deliver a subset of changes to our customers and will also allow us to uninstall the patch if something goes wrong. Do note that any customizations performed on the components being updated will be lost with this approach, but that should be ok as the components need to be mandatorily updated.
When two or more solutions perform changes to the same component, the system can resolve the conflict by using one of the following strategies:
- Merge: User interface components (Ribbons, Forms, and Sitemap) have the capability to merge. The system starts with the system solution and continues with any subsequent solutions installed on top of this, plus any additional customizations. At each step the system merges the changes, and what we see at run-time is the result of the merge.
- Last one wins: As the name implies, with this resolution, which is applicable to all components except the ones that support merging capabilities, the "top" change is the one that wins. For example, if multiple solutions rename an entity, what we will see at run-time is the last rename. The "top" change doesn't necessarily imply the last solution updated. If we install a solution update but chose to "preserve" the customizations, the top row will still be the customizations and not the contents of the update.
The following diagram provides a visual representation of conflict solution in Microsoft Dynamics CRM 2011:
If developers need to deploy a "patch" that affects only a subset of components and they want to ensure that the changes in the patch are effective, they can opt to deliver the patch as a different solution, but with the same publisher.
Most components that ship with CRM 2011 are customizable. For example, we can add or remove attributes from a specific entity, change the display strings of a particular object, change the user interface, and so on. Sometimes, however, certain behaviors of a component need to be restricted to prevent changes that would "break" the system, or to facilitate support/maintenance of the component in the future. For example allowing customers to delete key components on the system would lead to a malfunction. Developers creating CRM solutions face a similar challenge. We could inadvertently change or remove components that break the solution.
Managed properties provide granular control over specific aspects of a component. The most evident benefit of managed properties is that they allow developers to selectively restrict the customizability of a component. All that developers have to do is to set the value corresponding to the managed property to true or false, as indicated in the following screenshot:
Once a solution is installed as managed, the system will enforce the behavior specified by managed properties. Additionally, the system will prevent changing the value of the managed property itself. The only exception is the solution import. During import of a solution, the system matches the solution publisher specified in the package with the solution publisher on the target system, and if they match the system allows the value of the managed properties to be changed. However, once an operation is allowed and we perform the operation, the system will not allow the update of a managed property to make it more restrictive, as this could lead to an inconsistent state.
The solutions framework automatically tracks dependencies across components. Every core operation (create/update/delete) on a component automatically calculates its dependencies to other components in the system. The dependency information is used to maintain the integrity of the system, and to prevent operations that would lead to an inconsistent state.
- Deletion of a component will be prevented if other components in the system depend upon it.
- Export of a solution will warn the user if there are any missing components that could potentially cause failure when importing that solution in another system. Warnings during export can be ignored if the solution developer is purposely building a dependency on a "base" solution (for example, they are building on top of a solution, and require customers to install the base solution first).
- Import of a solution will fail if all required components are not contained in the solution and also don't exist in the target system. Additionally, when importing a managed solution, all required components must match the package type of the solution; in other words a component in a managed solution can only depend on another managed component (same or distinct solution). If, at the time of import, a required component exists on the target system but is not managed, the import routine will still report it as missing.
An important point to highlight is that dependencies are version agnostic. CRM 2011 tracks dependencies across components using their unique identifiers (unique name or GUID), which doesn't include any versioning information.