Dynamics CRM Solutions

Everything about the Dynamics CRM solutions we can get in MSDN articles however I have tried from my side to include major points on one page.

[ https://msdn.microsoft.com/en-in/library/gg334576.aspx]

Generally, solutions can be imported into organizations less than two versions higher than the version the solution was exported from.

Solutions can only add new solution components or overwrite existing solution components. Solutions can’t be used to delete solution components.

Unmanaged and managed solutions

•  A managed solution is a completed solution that is intended to be distributed and installed. An unmanaged solution is one that is still under development or isn’t intended to be distributed. When the unmanaged solution is complete and you want to distribute it, export it and package it as a managed solution.

Unmanaged solutions

When you install an unmanaged solution, you can perform the following actions at the target environment:

• Add components.
• Remove components.
• Delete components that allow for deletion.
• Export and import the unmanaged solution.
• Export the solution as a managed solution.

ü  When you create an unmanaged solution, you create a way to group a subset of the available customizable solution components. 

ü  Include those solution components that are relevant to a particular functionality, this allows for a smaller size package when you export your solution and makes a more manageable set of components.

ü  If you delete an unmanaged solution, you just delete the group used to contain references to solution components. The solution components in an unmanaged solution remain in the system but they are no longer associated with the unmanaged solution you delete.

ü  If you delete a solution component in an unmanaged solution, it is deleted from the system and is no longer available from any other unmanaged solution. Use “remove” instead of “delete” if you just want to remove a solution component from an unmanaged solution.

Managed solutions

After you install a managed solution, the following applies:

• You can’t add or remove solution components in a managed solution.
• ·         You can’t export a managed solution.
• Deleting a managed solution uninstalls all the solution components in it. (Only non-OOB components with data will be deleted from the system)

ü  After you install a managed solution you may be able to customize the solution components if the creator of the managed solution has configured the managed solution to enable it. You must access the customizable solution components using Customize the System instead of through the managed solution itself.

Managed properties

• Using managed properties, the creator of a managed solution can control whether a solution component is customizable and which specific parts of it can be customized.
• Managed properties must be set in an unmanaged solution. The managed property settings are only applied after the managed solution has been packaged and installed.

Create managed solution updates

There are two basic approaches to updating a managed solutions:

• ·         Release a new version of your managed solution
• ·         Release an update for your managed solution
• The preferred method is to release a new version of your managed solution. Using your original unmanaged source solution, you can make necessary changes and increase the version number of the solution before packaging it as a managed solution. When the organizations that use your solution install the new version, their capabilities will be upgraded to include your changes. If you want to go back to the behavior in a previous version, simply re-install the previous version. This overwrites any solution components with the definitions from the previous version but does not remove solution components added in the newer version. Those newer solution components remain in the system but have no effect because the older solution component definitions will not use them.
• During the installation of a previous version of a solution Microsoft Dynamics 365 will confirm that the person installing the previous version wants to proceed.
• When only a small subset of solution components urgently requires a change you can release an update to address the issue. To release an update, create a new unmanaged solution and add any components from the original unmanaged source solution that you want to update. You must associate the new unmanaged solution with the same publisher record as was used for the original solution. After you finish with your changes, package the new solution as a managed solution.
• When the update solution is installed in an organization where the original solution was installed the changes included in the update will be applied to the organization. If an organization needs to ‘roll back’ to the original version they can simply uninstall the update.

ü  Release a new version of your managed solution

ü  Release an update for your managed solution

Conflict resolution

When two or more solutions define solution components differently, Microsoft Dynamics 365 resolves the conflict using two strategies, Merge and Top Wins.

Merge

User interface components (command bar, ribbons, forms, and site map) are merged. This means that the solution components are re-calculated from the lowest level to the highest so that the organization’s unmanaged customizations are the last to be applied.

Top Wins

For all other solution components any conflict is calculated in favor of the customization that is applied last. For managed solutions this usually means that the last solution installed is applied. However, there is a special case when an update to a managed solution is installed.

PATCHES [https://msdn.microsoft.com/en-us/library/mt593040.aspx]

ü  Simplifies solution updates

ü  include only changes to entities and related entity assets

ü  Patches do not contain any non-customized system components or relationships that it dependents upon because these components already exist in the deployed-to organization

ü  Patches are stored in the Dynamics 365 database as Solution entity records. A non-null ParentSolutionId attribute indicates that the solution is a patch. 

ü  <major>.<minor>.<built>.<release> only bold are editable when patching

ü  The patch parent can’t be a patch.

ü  Patches can only have one parent solution.

ü  A patch creates a dependency (at the solution level) on its parent solution.

ü  You can only install a patch if the parent solution is present.

ü  You can’t install a patch unless the unique name and major/minor version number of the parent solution, as identified by ParentSolutionId, do not match those of the parent solution installed in the target organization.

ü  A patch version must have the same major and minor number, but a higher build and release number, than the parent solution version number. The display name can be different.

ü  If a solution has patches, subsequent patches must have a numerically higher version number than any existing patch for that solution.

ü  Patches support the same operations as solutions, such as additive update, but not removal. You cannot remove components from a solution using a patch. To remove components from a solution perform an upgrade.

ü  Patches exported as managed must be imported on top of a managed parent solution. The rule is that patch protection (managed or unmanaged) must match its parent.

ü  Don’t use unmanaged patches for production purposes.

ü  Patches are only supported in Dynamics 365 organizations of version 8.0 or later.

 Once you create the patch, the original solution becomes locked and you can’t change or export it as long as there are dependent patches that exist in the organization that identify the solution as the parent solution.

ü  When to use:

If you add an entity to a solution and export the solution, the entity and all of its related assets are exported in that solution. These assets include attributes, forms, views, relationships, and visualizations, and any other assets that are packaged with the entity. Exporting all objects means that you can unintentionally modify objects on the target deployment, or carry over unintended dependencies. 

To address this, you can create and publish solution patches that contain subcomponents of entities rather than publishing the entire entity and all of its assets.  The original solution and one or more related patches can be rolled up (merged) at a later time into an updated version of the solution, which then can replace the original solution in the target Microsoft Dynamics 365 organization.

Delete a patch

ü  You can delete a patch or base (parent) solution by using DeleteRequest or, for the Web API, use the HTTP DELETE method. The delete process is different for a managed or unmanaged solution that has one or more patches existing in the organization.

ü  For an unmanaged solution, you must uninstall all patches to the base solution first, in reverse version order that they were created, before uninstalling the base solution.

ü  For a managed solution, you simply uninstall the base solution. The Dynamics 365 system automatically uninstalls the patches in reverse version order before uninstalling the base solution. You can also just uninstall a single patch.

Update a solution

Updating a solution involves rolling up (merging) all patches to that solution into a new version of the solution. Afterwards, that solution becomes unlocked and can once again be modified (unmanaged solution only) or exported.

For a managed solution, no further modifications of the solution are allowed except for creating patches from the newly updated solution.

To rollup patches into an unmanaged solution, use CloneAsSolutionRequest or the CloneAsSolution Action.

Cloning a solution creates a new version of the unmanaged solution, incorporating all its patches, with a higher major.minor version number, the same unique name, and a display name.

For a managed solution things are handled slightly differently. You first clone the unmanaged solution (A), incorporating all of its patches and then exporting it as a managed solution (B). In the target organization that contains the managed version of the (A) solution and its patches, you import managed solution (B) and then execute DeleteAndPromoteRequest or the DeleteAndPromote Action to replace managed solution (A) and its patches with the upgraded managed solution (B) that has a higher version number.

Understanding version numbers for cloned solutions and patches

A solution’s version has the following format: major.minor.build.revision. A patch must have a higher build or revision number than the parent solution. It can’t have a higher major or minor version. For example, for a base solution version 3.1.5.7, a patch could be a version 3.1.5.8 or version 3.1.7.0, but not version 3.2.0.0. A cloned solution must have the version number greater than or equal to the version number of the base solution. For example, for a base solution version 3.1.5.7, a cloned solution could be a version 3.2.0.0, or version 3.1.5.7. In the UI, you can only set the major and minor version values for a cloned solution, and the build or revision values for a patch.

CLONING

• "Clone a Solution" - It creates a copy of solution with new version in which all patches released from base solution are merged
• §  You can only clone an unmanaged solution. If you clone an unmanaged base solution, it will create a new solution with higher version(Major & Minor) than base solution. And all the patches released from base solution will be merged into the cloned solution.
• A cloned solution can be exported both Managed and Unmanaged

Importing cloned solution in target system:

Import feature of clone solution is a bit different from normal solution, when you import a clone solution you will see a message - "This solution package contains an update for a solution that is already installed"

• Click on NEXT
• Here you get option "Stage for Upgrade". If you select this option a holding solution will be created. It means you will see both base solution and upgraded solution. But the upgrade will not take place, to apply upgrade you need to click on "Apply Solution Upgrade" on Solution explorer form.
• Maintain Customizations: Selecting this option will maintain any unmanaged customizations performed on components but also implies that some of the updates included in this solution will not take effect. 
  
  Example: Suppose you have customized a field in default system solution and change its length from 50 to 100. If in case the cloned solution contains the same field with length 50. In this case maintain customization will retain the unmanaged customization i.e. field length will remain 100.
  
  Overwrite Customizations: Selecting this option will overwrite any unmanaged customizations previously performed on components included in this solution. All updates included in this solution will take effect

EXAMPLE WITH USECASE & DETAIL

Solution Patching

https://debajmecrm.com/2015/12/23/dynamics-crm-solution-patching/

Solution Cloning

https://debajmecrm.com/2015/12/27/dynamics-crm-solution-cloning/