A PowerShell script to import/export solutions and data

Sep 26: A newer version of this post is available here: https://www.itaintboring.com/dynamics-crm/using-powershell-to-exportimport-solutions-data-and-word-templates/

I have never been a big supporter of the configuration migration tool simply because it seems strange that we need to export data manually while preparing a package for the package deployer. I am also on the fence when it comes to the package deployer itself – on the one hand, those packages can certainly do the job. On the other hand, one needs Visual Studio to develop a package.

At some point, we’ve developed EZChange  for one of the implementations – that’s an actual no-code approach utilizing mostly unmanaged solutions.

But when it comes to a solution that would work with both on-premise and Azure DevOps, it seems PowerShell sounds like a really good option. There are a few projects out there, such as Xrm CI Framework by Wael Hamze.

I just needed something relatively simple this time – with a twist, though, since I also needed a simple mostly automated data export/import feature (and, ideally, manual control over that data)

If you are curious to see how it worked out, keep reading… By the end of this post you should be able to set everything up so that you can export solution and data from one environment using one script and import to another using another script.

There is a github project where you can get the scripts

https://github.com/ashlega/ItAintBoring.Deployment

That project also includes a demo solution files for Dynamics

To set up your own project, do this

• Either clone or download the whole project from GitHub
• Browse to the PSModules subfolder and create deploymentSettings.psm1 file as a copy of deploymentSettingsTemplate.psm1:

• Open that file and configure connection strings for both Source and Destination connections

 

Essentially, that’s it. Since that GitHub project already has a demo solution and some data, you can try importing both into your destination instance. To do that, run Import.ps1 script from the SampleProject folder:

Note: it’s an unmanaged solution that has one demo entity. I don’t think there is any danger in installing it, but, of course, try it at your own risk

Below is a quick demo of what’s supposed to happen. Notice how, at first, there is no DemoDemployment solution in Dynamics. I will run import.ps1, will get the solution imported, but, also, will have some demo data added as you will see in the advanced find.

 

 

 

 

 

 

 

 

 

 

 

 

So how does import.ps1 script look like?

Here it is:

The work is, mostly, done in the last 4 lines:

• The first two of them are all about setting up CDSDeployment object and initializing it (the class for that object is defined in the PSModules\deployment.psm1 file)
• Once the object is ready, I can use it to import my solution
• And, finally, I’m importing demo data in the last line

What about 10 or so lines at the beginning of the script? That’s reading configuration settings from either the environment variables (for Azure DevOps), or from the deploymentSettings.psm1 file created above.

What if I wanted to export the solution file and/or the data?

This is what export.ps1 script is for.

It’s very similar to the import.ps1, but it’s using the other two methods of the CDSDeployment object:

ExportSolution method will export a solution. The second parameter there stands for “managed” (so, if it’s “false”, then it’ll be an unmanaged solution)

ExportData will export, well, data.

Now keep in mind that there are two files in the Data folder:

You can have more than two, since both ExportData and PushData methods will be accepting file name parameters. However, at least for now, you will need to manually create schema.txt file. That’s, basically, an entity metadata file in json format:

And, of course, data.txt is the actual data file:

You can either export data from the dev environment, or you can create that file manually (and, possibly, use it to populate all environment with the configuration data, including the dev environment)

Would it work with Azure Pipelines? Sure:

What about solution packager etc? That was not, really, the purpose of this set up, but it can certainly be added.