Understanding D365 CE solution Deployment – Packaging – Part 2

In the previous post we created the new package template project and checked the default files which  are created in the solution.

In this solution, we need to add the exported solution(s) under package folder and if we have any configuration data files, that can also be added to this folder. Once we add these files, we have to set up the configuration file which guides the package deploy what is to be imported and how.

Setting up this file is one of the important task in creating the package. Let us  see in details

Refer to the below file which is modified by for this post.  This is an xml file and we have to mention the names of the added exported solution files and the data files etc here.

Myappconfigdata.zip is the data file and MyappSolution_1_0_managed.zip is the solution which is to be deployed .

<?xml version="1.0" encoding="utf-16"?>
<configdatastorage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    <configsolutionfile solutionpackagefilename="MyappSolution_1_0_managed.zip"
    <cmtdatafile filename="Myappcongigdata.zip"
                 usermapfilename="" />


Microsoft docs has very detailed explanation about this config files and there is explanation about all the tags and its importance . Hence I am not going in those details again in this  post. Kindly refer to below link for more details.

Specify the configuration values for the package

We have to mention all the solutions under <solutions>  tag . Here for example I have added only single solutions, but we can add multiple solutions. The order we mention the solutions in this, solutions will be imported in the same order. We can specify whether we want to overwrite the existing customization while importing and also whether we want to publish the workflows and activate plugins post import using the attributes\

  • overwriteunmanagedcustomizations
  • publishworkflowsandactivateplugins

If we have the data file, that also can be mentioned here. This data file can be created with the  help of configuration migration tool provided by Microsoft. We will discuss this in detailed  this in later posts. Kindly refer the Microsoft Docs link for more details on this

Using Configuration Migration tool 

Now we let see thMyappSolutione use of PackageTemplate.cs which helps us to write the custom code for our deployment. To make it simple, let us keep the default code in this file except the properties . We have to set the properties as per the names we have given to our files and folders. It helps the deployer to identify the solution(s) to be imported and data to to migrated.

#region Properties

/// <summary>
/// Name of the Import Package to Use
/// </summary>
/// <param name="plural">if true, return plural version</param>
/// <returns></returns>
public override string GetNameOfImport(bool plural)
return "MyappSolution";

/// <summary>
/// Folder Name for the Package data. 
/// </summary>
public override string GetImportPackageDataFolderName
// WARNING this value directly correlates to the folder name in the Solution Explorer where the ImportConfig.xml and sub content is located. 
// Changing this name requires that you also change the correlating name in the Solution Explorer 
return "PkgFolder";

/// <summary>
/// Description of the package, used in the package selection UI
/// </summary>
public override string GetImportPackageDescriptionText
get { return "My App created for learning solution deployment "; }

/// <summary>
/// Long name of the Import Package. 
/// </summary>
public override string GetLongNameOfImport
get { return "MyApp Solution Package created for learning the solution deployment using package deployer "; }


Microsoft Docs has very intuitive explanation about this file’s usage and what to change. Kindly refer below link to go the more details

Define custom code for your package

Now its the last step. If you observe carefully, any installation starts with some welcome page with few information/ instructions and after the installation is complete, it gives some information/Thank you message etc. Same process applies here during package deployment as well and we can add such pages in html format and different languages. Inside the pkgfolder, we see a content folder and which has default html files for English language. we can customize those as per our requirement and required language

Kindly refer to Microsoft Docs site below about more details

Update the html files

Now our package is ready for build. Let us build the package and see in bin folder, we will see the one dll along with pkgfolder. As we have set the copy always for all the files in folder, it is copied in the bin folder.

We have come to the final step of deploying the package. Let us see the same in next post.

Continue reading “Understanding D365 CE solution Deployment – Packaging – Part 2”

Understanding D365 CE solution Deployment – Patches – Part 1

In previous post we saw how to  deploy the solution using manual export and import method.

Let us discuss a scenario where we have frozen the solution,  have the sign offs on the SIT and there is one critical CR or a bug which is to be resolved. Assume that the change really small and is required to be done in an entity. However if we do the changes in our solution and export the solution, all entities and related assets will get exported and there are chances that any unnecessary changes might getting imported in the target solution. To avoid such situation, we can use patches in Solution deployment

Let us understand patches in details

Unlike the solutions, patches include only changes related to the entity and related entity assets. It does not contain any non customized system components or any relationships on which it is dependent on as this would be already included in the original solution, deployed in the target system.

Few important facts about Patches:

  • Patches can only be created from a parent solution and hence we can not create a patch based on any 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 in the target instance and its major and minor number are matching with the major and minor number of patch. Additionally the patch should have higher release and build number than the original solution in target instance
  • The rule is that patch protection (managed or unmanaged) must match its parent.
  • 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
  • For managed solutions, when we uninstall the original solution, all related patches would get uninstalled automatically, however for unmanaged solutions, we have to first we need to uninstall all the patches in reverse order based on the version and then we will be allowed to uninstall the based solution

Let us now see how to create patches. As we saw in the last post we have two CRM instances and we have a solution named deployment already deployed from source to target. Let us consider one requirement where I have to add few fields in the account entity

To learn the patch deployment, let us follow below steps

  1. Create solution in source instance and export
  2. Import the solution in the target instance
  3. Create first patch in source instance and export the patch
  4. Import the first patch in target instance
  5. Create second patch in source instance and export
  6. Import the second patch in the target instance
  7. Delete the second patch from target instance
  8. Merge the patches to original solution in source instance
  9. Export the merged solution from source instance
  10. Import the merged solution in target instance (target solution has first patch already)

All above steps would help us to make the concepts of patch deployment clear. Let us start following the steps one by one

  1. Create solution in source instance and export

In this step let us create new solution,

  • Add existing Accounts entity to the solution and do the changes in the Description field’s max length
  • Create new entity named project and do the changes in the description field’s max length
  • Publish the customization
  • Export the newly created solution

Kindly refer to previous post for creating new solution and export. I am using the same solutions from last post

Click Add existing and select Entity


Select the Account Entity


Let us add new Component, select Entity and add Entity Details Patch8

Let us add new field to it as DescriptionPatch9

Kindly note that the field length is 100Patch10

Finally we have two entities in the newly created solution


Once the solution is published, let us export the solution as managed.


Now we have the zip file downloaded of the managed solution.

2.  Import the solution in the target instance 

In this step, let us import the solution in the target instance.

Go the setting- solutions – click on Import as we seen in the previous post


Now we have first solution deployed in the target instance.

3. Create first patch in source instance and export the patch 

As discussed above, let us consider a requirement comes where we just need to change the length of Description fields of both the entities Project and Account.  I am giving a simple example, but the original solution might be quite complex and large solution and changes required can be unique. Hence we would create a patch and only add those particular fields in the patch and do the changes as depicted in below stage.

Again go to the settings-solutions, select the original solution and click clone the patch


Make a note here that we are allowed to change the build and release number of the version


Once saved, we can see the patch solution is available under solutions


Now we can do add our changes in the patch solution.We we try to do any changes in the original solution, its not allowed as depicted in below snippet


Let us open the patch solution and do required changes. Add Account entity and select only description field to be added in the patch solution


Also select the custom entity Project and add its description field as well.


Let us change the description fields of both Account and Project entities as required

Project’s description field’s max length is set as 50


Account’s description field’s max length is set as 1000


Let us publish the customization


Once published, let us export the patch solution by clicking Export button


We might not include the missing components as those would be already present in the original solution.


We have to make sure that we select Managed while export as the original solution was exported and imported as Managed


We have downloaded the zip file of exported managed solution patch.

4. Import the first patch in target instance 

Let us import patch to the target instance.

Go to Settings, Solutions, click on Import button


Select the exported solution and click on Import button




Once the solution is imported successfully, we can verify and see if the max length of the description field is changed


We have followed first four steps in this blog. Please check next blog for for rest of the steps.

Happy deploying and patching  🙂

Continue reading “Understanding D365 CE solution Deployment – Patches – Part 1”