Journey to Implementing Continuous Delivery for Dynamics CRM

In this post I will show you how you can implement Continuous Delivery for your Dynamics CRM solutions. Using the latest version of Team Foundation Server (TFS), Visual Studio Release Management and xRM CI Framework you will be able to implement one-click automated deployments across all your environments including production. This will enable you provide continuous business value to your stakeholders by releasing small changes more frequently, consistently and reliably. This is very much inline with Agile methodologies of software delivery.

Stage 1: Automate your Builds

Before you can automate your deployment and release processes you need to have an automated consistent way of building your Dynamics CRM components. In terms of deployment your components will be artifacts like CRM Solutions, Configuration Data, CRM Deployment Packages and others. Team Foundation Server provides an excellent Build Automation and Continuous Integration Engine that you can use for this.

Using xRM CI Framework you can easily create automated builds for your Dynamics CRM solutions with a few clicks. Follow the documentation on codeplex to create your build. The build will generate your CRM components and place them in the designated drop location. This can now be picked up by your Release Automation tool which in this case will be Visual Studio Release Management.

Stage 2: Automate your Deployments

Having a consistent build process in place, you can now move into automating the deployment of the components produced above. You will use PowerShell scripts to automate the deployment process. The latest Sdk for Dynamics CRM 2013 comes with PowerShell extensions that allow you deploy CRM Deployment Packages.

The xRM CI Framework comes with two generic PowerShell Scripts. The first one allows you to import CRM Solutions and the second one allows you to deploy a CRM Deployment Package. Depending your scenario you can get started by using either of these scripts and tweak them to your needs. Note the xRM CI Framework also contains many custom PowerShell Cmdlets (Commands) that you can use in your scripts. Check out the documentation on codeplex for more information.

Now you should have some scripts that you can run on to deploy your automated Build outputs.

Stage 3: Automate your Testing

You should be really thinking about this from the start and writing automated tests as requirements come in. The reason I put this at this stage is because as far as Continuous Delivery is concerned you can’t execute your automated tests without having first build and deployed your application to your stage or testing environment. Ideally you want to run Unit Tests during each Check-In and Integration and functional tests in your Continuous Integration and Nightly builds. Finally sanity tests can be run after deployment to your UAT & Production environments.

The xRM Test Framework contains lots of utility classes and productivity tools to allow to easily create Unit and Integration Test for your Dynamics CRM deployments. Check out the detailed documentation and webinars on codeplex. These tests can then be executed during your builds and post your release using Visual Studio Release Management.

Stage 4: Automate your Releases

Once you have your automated builds and deployment scripts ready, you can start thinking about release automation. Release automation allows you to do one click deployments across all your environments. Visual Studio also includes cool features such as security, audit, configuration and environment management and most importantly an easy visual tool to allow you to model your release process using workflows.

In the following post I will show you on how to use Release Management with Dynamics CRM.

Hope you found this post useful.


xRM CI Framework for Dynamics CRM 2013 SP1 is now available

The xRM Continuous Integration (CI) Framework is a set of tools that makes it easy and quick to automate the builds and deployment of your CRM components.

Implementing continuous integration is always a nice to have feature on Dynamics CRM projects which in most cases gets left for various reasons even though having this setup will save lots of time long term, reduce therisk and improve productivity. Using xRM CI Framework you can quickly implement a build->deploy->test workflow with a few clicks. This is achieved by providing easy to use templates and sample scripts. These can also be easily extend to meet any complex or specific scenarios you might have.

Dynamics CRM 2013 SP1 has been recently released and come with lots of new exiting features and capabilities. This includes an updated SDK. To compliment this release I have updated the xRM CI Framework to take advantage of these new capabilities. Hopefully this will allow you to put in these best practices and automation in place as you start your new Dynamics CRM 2013 projects.

Below is a list of updates from the CRM 2013 version:

  • Support for Dynamics CRM 2013 SP1 Online/OnPremise
  • Uses the latest Dynamics CRM 2013 SP1 SDK
  • Ability to Build and Deploy CRM Deployment Packages
  • Integration with Visual Studio Release Management
  • More Sample Scripts
  • More PowerShell Cmdlets
  • New custom Dynamics CRM Build Template  for TFS 2013 (see process below)



I have uploaded the source code to codeplex with lots of steps by step instructions to get your started quickly. This will also allow you to extend the framework to meet your needs.

Please post any feedback, comments, issues, discussion on the codeplex site.

Feel free to get in touch if you would like to contribute with ideas, enhancements and new features.

I have also created a download to the new Framework from the Visual Studio Gallery here.

I am presenting @CRMUG UK Regional Chapter (July 2014)


Join me for the next meeting of the CRMUG UK Regional Chapter Meeting on Thursday, July 17th at Microsoft Cardinal Place Victoria, London. The July meeting will focus on using Microsoft Dynamics CRM for managing Customer, Citizen, and other kinds of “Service”. Don’t miss this opportunity to experience what CRMUG has to offer you and fellow Dynamics CRM users in your area!

I will be presenting a session about “One-Click Dynamics CRM Deployments ” at 11:15 AM.

“Find out how you can automate the build and deployment processes for your CRM solutions. The session will demonstrate how the latest tools from the CRM SDK, TFS 2013, Visual Studio Release Management & xRM CI Framework can work together to implement end to end one-click deployments of your enterprise Dynamics CRM Solutions across all your environments. This will allow you to deliver CRM more frequently in a consistent and reliable way.

Don’t forget to take a look at the full Agenda in here. There will be multiple tracks with a range of topics to suite all roles.

Looking forward to seeing you all in there.

xRM Test Framework for Dynamics CRM 2013 is now available

The xRM Test Framework  is a set of tools that allows you easily and quickly create automated units and integration tests for your Dynamics CRM extensions.

Testing plug-ins and custom workflow activities can be quite challenging and time consuming using standard approaches. This sometimes discourages developers from writing automated tests for Dynamics CRM extensions. This can lead to quality issues and wasted effort and time down the line. The framework attempts to encourage the adoption of testing best practices in Dynamics CRM projects.

Below is what the framework provides.

Base Test Library

  • Bases classes for testing Plug-ins and Custom Workflow Activities. All tests extend from these classes.
  • These cover your Unit & Integration Tests
  • These do most of the ground work and allow you to focus on writing your test scenarios in your tests.
  • Available via NuGet
  • Support for Microsoft Fakes & Moq

Below is a high level diagram for the base classes.


To add the Xrm.Framework.Test assembly to your existing Test project.

  1. In your existing test project – Right click on References -> Manage NuGet Packages…
  2. Click on Online in the left tree and then search for “Xrm.Framework.Test”
  3. Click install – this will add the assembly and the NuGet package to your project

You should be able to see the below:


Productivity Tools

  • These provide templates to enforce standard patterns and best practices
  • Templates allow you to easily and consistently create your tests
  • Visual Studio Project Templates for creating Test Projects
  • Visual Studio Templates for creating Tests for different extensions
  • Available via the Visual Studio Gallery

To get start just install the extension from the visual studio.

  1. Open Visual Studio
  2. From the menu bar click on Tools -> Extensions & Updates…
  3. Click on Online in the left tree and then search for “xRM”
  4. Download and install the extension

You should be able to see the below:


You can also download it from Visual Studio Gallery directly.

After you install the extension you should be to create a new Test project by going into the “Dynamics CRM” category in Visual Studio. Below is what you should be able to see in addition to the CRM Developer Toolkit templates.


After you create the project you should be able to add new Tests to your project using the Framework templates. Again these will be in the “Dynamics CRM” category as you can see below.


Finally I would like to thank Ramon Tebar (MVP) for his help and contributions especially in making this Framework work with Microsoft Fakes and Dynamics CRM 2013.

So whats next? In future posts I will show how to create different types of tests for your CRM extensions.

I am presenting at extremeCRM 2014 Barcelona


eXtremeCRM is the hub where Microsoft Dynamics CRM partners come together to forge business relationships, gain knowledge from real-world experiences and dive deep into current and future technologies.  For Microsoft Dynamics CRM partner organizations, it is the annual conference to attend to nurture best practices, facilitate business growth, and educate each organization member.  The highly anticipated conference will be held in Barcelona, Spain, 9 – 12 February, 2014.

Join me on Tuesday 11 Feb at 16:45 in room H3 for my session on “Continuous Delivery – Deliver CRM More Frequently in a Consistent and Reliable Way“. Summary of the session below. You can find all the details in here.

“In this session I will show you what it takes to achieve Continuous Delivery in an enterprise environment through automating the build, deployment and testing of your CRM solutions. I will include a demo of an end to end journey of taking a requirement from definition all the way into production using the latest Automation Tools and best practices (Team Foundation Server 2013, Release Management for Visual Studio, PowerShell & xRM CI Framework for Dynamics CRM 2013). I will discuss suitable implementation options for your target infrastructure to cover on-premise and cloud implementation.

This session will be particularly useful for delivering Dynamics CRM into organizations where there is demand for quick results, quality, efficiency, controlled processes and audit.”

Looking forward to seeing you all in there. Don’t forget to take a look at the full Agenda in here.

Dynamics CRM Parallel Development with Solution Packager

The Solution Packager is a very useful tool that has been released with Dynamics CRM 2011 Update Rollup 10 and is currently also available in Dynamics CRM 2013 Sdk. Traditionally you can only move CRM components around between two environments using CRM Solutions. You will soon start to see the limitations of this if you are doing one of the below:

  • You are working on a team where each developer has their own virtual machine or CRM organization for isolation purposes
  • You are on a project with one or more parallel streams of work where each stream has their own environment and different release schedule but working on the same CRM Solution

In all of the above cases you will need to bring all the pieces together once the work is ready and release them into your main CRM environment for testing or further packaging as CRM solutions. You will find that the only way to merge these changes with the existing solution is to place your changes into a new/existing solution and deploy that to your main CRM environment that contains the existing changes (Note these could have moved on since you started to work your specific feature). Below are a few issues you might encounter with that approach:

  • When you deploy the CRM Solution containing your changes this might potentially override customizations that are already in there. You might end up re-doing some of work manually in two places.
  • It is difficult to track what changes were made to implement that specific feature. You can track your source control items such as JavaScript files and CSharp code files but not your CRM customisations such as changes to data model, workflows, user interface and others.

The solution packager allows to extract your customizations from your own/team environment after you are done with a feature and check-in your changes into source control along with changes you have made to the files that are normally in source control such as JavaScript & other code files for your plug-ins for example. By default when you run the extract operation this will include everything that is contained in the solution zip files so it will include things like your plug-in assemblies and JavaScript that you already have in source control. The solution packager allows you to provide a mapping file so that during the extract operation it can skip the files you already have in source control and use the files you already have in source control and use the newly complied assemblies from the latest source code. Below is a diagram so you can picture this.

Extract Solution

To help make this easier I have created a sample PowerShell script that automates some of the activities discussed above.This is included in the latest xRM CI Framework along with the required assemblies. This script will do the below.

  • Check-out your existing extracted files from TFS (optional)
  • Export your managed and unmanaged solution from CRM
  • Find the deltas and mark the files under TFS with add/delete/check-out accordingly
  • Check-in the updated files back into TFS (optional)

You can use the sample script below and make any changes as required. Don’t forget to download and install the assemblies for the xRM CI Framework or plug-in your own utilities.

Code Snippet
  1. # Filename: ExtractCustomizations.ps1
  2. param([string]$solutionPackager, #The full path to the solutionpackager.exe
  3. [string]$solutionFilesFolder, #The folder to extract the CRM solution
  4. [string]$mappingFile, #The full path to the mapping file
  5. [string]$solutionName, #The unique CRM solution name
  6. [string]$connectionString, #The connection string as per CRM Sdk
  7. [switch]$checkout, #Optional – pass if you want to Check Out the existing files in the extract location
  8. [switch]$checkin) #Optional – pass if you want to Check In the updated files after extraction
  9. $ErrorActionPreference = “Stop”
  10. Write-Host “Solution Packager: $solutionPackager”
  11. Write-Host “Solution Files Folder: $solutionFilesFolder”
  12. Write-Host “Mapping File: $mappingFile”
  13. Write-Host “ConnectionString: $connectionString”
  14. Write-Host “Check In: $checkin”
  15. Write-Host “Check Out: $checkout”
  16. # CI Toolkit
  17. $scriptPath = split-path -parent $MyInvocation.MyCommand.Definition
  18. $xrmCIToolkit = $scriptPath + “\..\PowerShell Cmdlets\Xrm.Framework.CI.PowerShell.dll”
  19. Write-Host “Importing CIToolkit: $xrmCIToolkit”
  20. Import-Module $xrmCIToolkit
  21. #TF.exe
  22. $tfCommand = “C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe”
  23. #Check Pending Changes
  24. $pendingChanges = & “$tfCommand” status /recursive /noprompt “$solutionFilesFolder”
  25. if ($pendingChanges -like “*no pending changes*”)
  26. {
  27.     Write-Output $pendingChanges
  28. }
  29. else
  30. {
  31.     Write-Output $pendingChanges
  32.     Write-Error “Pending Changes Detected. Undo your changes and try again.”
  33.     return
  34. }
  35. #Before Files
  36. [string[]]$beforeFiles = [System.IO.Directory]::GetFileSystemEntries($solutionFilesFolder, “*”, [IO.SearchOption]::AllDirectories)
  37. Write-Host “Before Files: ” $beforeFiles
  38. #Check Out
  39. if ($checkout -and ($beforeFiles.Length -gt 0))
  40. {
  41.     & “$tfCommand” checkout /recursive /noprompt “$solutionFilesFolder”
  42. }
  43. #Export Solutions
  44. Write-Host “Exporting Solutions to: ” $env:TEMP
  45. $unmanagedSolution = Export-XrmSolution -ConnectionString $connectionString -Managed $False -OutputFolder $env:TEMP -UniqueSolutionName $solutionName
  46. Write-Host “Exported Solution: $unmanagedSolution”
  47. $managedSolution = Export-XrmSolution -ConnectionString $connectionString -Managed $True -OutputFolder $env:TEMP -UniqueSolutionName $solutionName
  48. Write-Host “Exported Solution: $managedSolution”
  49. #Solution Packager
  50. $extractOuput = & “$solutionPackager” /action:Extract /zipfile:”$env:TEMP\$unmanagedSolution” /folder:”$solutionFilesFolder” /packagetype:Both /errorlevel:Info /allowWrite:Yes /allowDelete:Yes /map:$mappingFile
  51. Write-Output $extractOuput
  52. if ($lastexitcode -ne 0)
  53. {
  54.     throw “Solution Extract operation failed with exit code: $lastexitcode”
  55. }
  56. else
  57. {
  58.     if (($extractOuput -ne $null) -and ($extractOuput -like “*warnings encountered*”))
  59.     {
  60.         Write-Warning “Solution Packager encountered warnings. Check the output.”
  61.     }
  62. }
  63. #After Files
  64. [string[]]$afterFiles = [System.IO.Directory]::GetFileSystemEntries($solutionFilesFolder, “*”, [IO.SearchOption]::AllDirectories)
  65. Write-Host “After Files: ” $afterFiles
  66. #Get the deltas
  67. $deletedFiles = $beforeFiles | where {$afterFiles -notcontains $_}
  68. $addedFiles = $afterFiles | where {$beforeFiles -notcontains $_}
  69. if ($deletedFiles.Length -gt 0)
  70. {
  71.     Write-Host “Deleted Files:” $deletedFiles
  72.     $_files = [System.String]::Join(“”” “””, $deletedFiles)
  73.     & “$tfCommand” undo /noprompt “$_files”
  74.     & “$tfCommand” delete /noprompt “$_files”
  75. }
  76. if ($addedFiles.Length -gt 0)
  77. {
  78.     Write-Host “Added Files:” $addedFiles
  79.     $_files = [System.String]::Join(“”” “””, $addedFiles)
  80.     & “$tfCommand” add /noprompt “$_files”
  81. }
  82. # Checkin
  83. if ($checkin)
  84. {
  85.     & “$tfCommand” checkin /noprompt /recursive /override:”PowerShell Extract” “$solutionFilesFolder” /bypass
  86. }
  87. # End of script

Below is also a sample script that invokes the script above with some predefined parameters to get you started.

Code Snippet
  1. & “C:\Program Files (x86)\Xrm CI Framework\CRM 2013\PowerShell Cmdlets\ExtractCustomizations.ps1” -solutionPackager “C:\workspace\CISample\Src\Sample2\Lib\CrmSdk\solutionpackager.exe” -solutionFilesFolder “C:\waelcrm2013\CISample\Src\Sample2\SolutionFiles” -mappingFile “C:\workspace\CISample\Src\Sample2\LocalSolutionPackagerMapping.xml” -solutionName “Sample” -connectionString “ServiceUri=; Domain=domain; Username=username; Password=******” -checkout

If you this approach and you are using TFS for managing your backlog, I would strongly recommend you associated your check-in of the CRM Customizations (Extracted using the above) and any source files developed in visual studio with your product backlog item. This way you can later see what were the changes that were done to meet that specific requirement or bug.

Having said all of the above, parallel development adds an overhead and additional complexity. So only go for that option if you really need to. If you decide to ahead anyway, avoid making changes to the same customizations and components by different team  members/teams and remember communication and a good process in place is always important. Bare in mind you can still use the solution packager for keeping a backup or your customizations and viewing deltas overtime which can be helpful in troubleshooting as well.

In the next post I will showing you how to automate the build of these extracted solution files and produce solutions that you can then deploy to other environments or ship to your customers.

How to create an Automated TFS Build for Dynamics CRM Solutions?

In this post I will show you how to fully automate the build of your Dynamics CRM Solutions using TFS and the xRM CI Framework. Creating an automated build when you start a new project is probably the least things on your mind when you have so many requirements to worry about. For this reason I tried to make this process easy and intuitive so you can get this up and running with a few clicks. This will definitely save you time down the line and make your overall process more consistent and reliable.

For this post I am going to show you how to do a Dynamics CRM Online Automated Build. I do not mean the cloud version of Dynamics CRM in this case. I mean creating CRM Solutions by exporting them from an available CRM environment. In this scenario the development team have decided that they want to use Dynamics CRM as their golden source of customizations as opposed to source control. I will assume that you are using the CRM Developer Toolkit to develop your custom assemblies and web resources.

Before you proceed. Follow the instructions in my previous posts to learn more about the xRM CI Framework for CRM 2011 & 2013. Also make sure you have completed the setup instructions detailed in this post.

The first thing is to create a TFS Build Definition. This provides all the configurations values that define what takes place once your build is triggered. The main difference is that instead of using the default build template we are using the customised build template that comes with the xRM CI Toolkit. This will give you the additional options that will allow to build your CRM solution as I will describe below. The default parameters are still available. These form the basis of all builds. If you need more information around these I suggest you read this msdn article. Below is a screen shot of the customised template so you can see what I mean.

Check my previous post to learn about the flow of this build. Below are step by step instructions to create your first Dynamics CRM Build definition.

  1. Enter your build name. This should take into consideration the CRM Solution name, the source control branch, the build type and any other criteria you want to include.
  2. Select the trigger. I suggest you start with a Manual trigger until your build is working as expected, you can then change it to run on check-in or scheduled basis.
  3. Select the source. This would be the folder containing the visual studio solution that contains the projects for your plug-ins etc…Ideally this should have been created using the CRM Developer Toolkit. But this is not a requirement.
  4. Set the build controller. TFS online comes with a default build controller. For on premise version you will need to have this setup. Make sure you have configured the build controller with the custom toolkit assemblies as detailed in the installation guide. Also set the Drop Folder. This is where all the outputs will be placed including the exported CRM solutions.
  5. Process. This is where the build workflow is configured. Select the Dynamics CRM Build template from the toolkit as per the installation guide.
  6. Set the items to build and configurations. In this case this is your visual studio solution contains all the things you want to build. If you only have customizations in CRM, you can skip this step.
  7. Configure your test settings if you want any unit tests to run as part of your build. Then set the build number format. Use a format similar to the below if you are planning to use this number for your CRM Solution versioning as well. You can update this later if needed to increment your major or minor versions.
  8. Set the CRM connection string. The format follow the CRM Sdk connection string. Note if you click on the dots in the field you will be able to provide this using a wizard. Don’t worry you can still update the field manually later to add things such as timeout settings. Then provide the unique solution name. These settings will be used in the following sections for connecting to the Dynamics CRM Server.
  9. Complete this section if you are using the CRM Developer toolkit and you want to perform the equivalent of deploy from visual studio to ensure that the target CRM environment is inline with your source code before doing the export. The parameters are self explanatory except for the table below.

    Parameter Name Description
    Check-In Register File When you perform a deploy on the CrmPackage project using the CRM Developer Toolkit this updates the RegisterFile.crmregister file with the assembly and step GUIDs from CRM. Set this to true to check-in these changes post deployment or false to discard.
    Copy Dependent Packages If you add any dependent CRM Solutions to your package project, setting this to true will copy all of these solutions to the drop folder.
    Enable Deploy If this is set to False then this section will be skipped and no deployment will take place.
  10. Final and most important step. This export the CRM Solution from the specified environment into the drop location. You can optionally publish customizations and increment the Solution version number inline with the build number.

    Parameter Name Description
    Enable Solution Export Setting this to False will inform the build to skip this section completely
    Publishes Customizations Publishes all the customizations prior to the export operation
    Update Solution Version to Build Setting this to True will inform the build to update the version number of the CRM Solution in the specified CRM Environment to the Build version number (the part after the ‘_’). This happens before the export operation.
  1. Save the build definition. Trigger a new build and wait until this complete. If everything went ok you should see something similar to the below. Notice that I also get my unit test results and the code coverage.
  2. Finally go to the drop location for that build. You should see all the outputs including the exported CRM Solutions. Notice in this case my solutions have the same version as the build number.

By now you should have a fully automated build. That you can re-use. Off course not all builds are simple as this. But this will cater for many scenarios.

Watch out for the up coming posts. I will show you how you can use the CRM Solution packager to do your builds and implement Continuous Integration including extending your builds to deal with more complex scenarios.

Asynchronous Solution Import in Dynamics CRM 2013

One of the new features in the Dynamics CRM 2013 SDK is the ability to execute operations asynchronously. At the moment this feature is limited to only solution imports.

Previously in Dynamics CRM 2011 you were only able to import solutions synchronously. This means that the caller had to wait until the solution import process completes. This resulted in time out errors when importing large or complex solutions. Customers had to increase their time out settings significantly for on-premise deployments. For CRM online, the only option was to catch the exception and do some queries to figure out if the solution import was actually successful or no.

In Dynamics CRM 2013, the “ExecuteAsync” message solves this problem. All we have to do is submit a request to the Dynamics CRM Organization Service using this message. The message would kick off a server side process asynchronously to process the request and return the id of the server side process immediately to the caller. The caller then can query the status of the server side process to figure out if the request was processed correctly.

Take a look at the example below. This method supports both synchronous and asynchronous imports. For asynchronous imports, it can optionally wait for the import job to finish and report on the status.

Code Snippet
  1. public Guid? Import(string solutionFilePath,
  2.                     bool publishWorkflows,
  3.                     bool convertToManaged,
  4.                     bool overwriteUnmanagedCustomizations,
  5.                     bool importAsync,
  6.                     bool waitForCompletion,
  7.                     int sleepInterval,
  8.                     int asyncWaitTimeout)
  9. {
  10.     Guid? asyncJobId = null;
  11.     byte[] solutionBytes = File.ReadAllBytes(solutionFilePath);
  12.     ImportSolutionRequest importSolutionRequest = newImportSolutionRequest()
  13.     {
  14.         CustomizationFile = solutionBytes,
  15.         PublishWorkflows = publishWorkflows,
  16.         ConvertToManaged = convertToManaged,
  17.         OverwriteUnmanagedCustomizations = overwriteUnmanagedCustomizations
  18.     };
  19.     if (importAsync)
  20.     {
  21.         ExecuteAsyncRequest asyncRequest = newExecuteAsyncRequest()
  22.         {
  23.             Request = importSolutionRequest
  24.         };
  25.         ExecuteAsyncResponse asyncResponse = OrgService.Execute(asyncRequest) asExecuteAsyncResponse;
  26.         asyncJobId = asyncResponse.AsyncJobId;
  27.         if (waitForCompletion)
  28.         {
  29.             DateTime end = DateTime.Now.AddSeconds(asyncWaitTimeout);
  30.             while (end >= DateTime.Now)
  31.             {
  32.                 AsyncOperation asyncOperation = OrgService.Retrieve(“asyncoperation”, asyncJobId.Value,
  33.                     newColumnSet(“asyncoperationid”, “statuscode”, “message”)).ToEntity < AsyncOperation>();
  34.                 switch (asyncOperation.StatusCode.Value)
  35.                 {
  36.                     //Succeeded
  37.                     case 30:
  38.                         return asyncJobId;
  39.                     //Pausing //Canceling //Failed //Canceled
  40.                     case 21:
  41.                     case 22:
  42.                     case 31:
  43.                     case 32:
  44.                         thrownewException(string.Format(“Solution Import Failed: {0} {1}”,
  45.                             asyncOperation.StatusCode.Value, asyncOperation.Message));
  46.                     default:
  47.                         break;
  48.                 }
  49.             }
  50.             thrownewException(string.Format(“Import Timeout: {0}”, asyncWaitTimeout));
  51.         }
  52.         return asyncJobId;
  53.     }
  54.     else
  55.     {
  56.         ImportSolutionResponse importSolutionResponse = OrgService.Execute(importSolutionRequest) asImportSolutionResponse;
  57.     }
  58.     return asyncJobId;
  59. }

You can start using this feature immediately by downloading the xRM CI Toolkit. This will provide you with a PowerShell Cmdlet to do exactly the above. See an example on how to use this below. This script invokes the solution import asynchronously and waits until the import completes.

Code Snippet
  1. Import-Module “C:\Program Files (x86)\Xrm CI Framework\CRM 2013\PowerShell Cmdlets\Xrm.Framework.CI.PowerShell.dll”
  2. $connection = “ServiceUri=; Domain=XRM; UserName=Wael; Password=******”
  3. Import-XrmSolution -ConnectionString $connection -SolutionFilePath “C:\” -PublishWorkflows $true -ConvertToManaged $false -OverwriteUnmanagedCustomizations $true ImportAsync $true -WaitForCompletion $true

Check my previous post to learn more about the xRM CI Framework and how you can use it in your projects.

xRM CI Framework for Dynamics CRM 2013 is now available

The xRM CI Framework is a set of tools that allows you to quickly and easily implement Continuous Integration for your Dynamics CRM solutions. This includes fully Automated Builds & Deployments.

Dynamics CRM 2013 has been recently released and come with lots of new exiting features and capabilities. These include an updated SDK. To compliment this release I have updated the xRM CI Toolkit to take advantage of these new capabilities. Hopefully this will allow you to put in these best practices and automation in place as you start your new Dynamics CRM 2013 projects.

Below is a list of updates from the CRM 2011 version:

  • Support for Dynamics CRM 2013 Online/OnPremise
  • Uses the latest Dynamics CRM 2013 SDK
  • Compatibility with the new CRM Developer Toolkit for Dynamics CRM 2013
  • Asynchronous Solution Imports (Check my other post here)
  • Sample PowerShell Scripts

Check my previous post for a list of the CRM 2011 version features that are still supported in this release.

Watch out for more posts regarding the above new features and new releases. This will include compatibility and new features for Visual Studio and Team Foundation Server 2013.

Note that even this release you can use the existing automated build templates with TFS 2013. However at this point in time the CRM Developer Toolkit does not work with Visual Studio 2013.

Finally you can download the new Framework from the Visual Studio Gallery here.

Automate your Dynamics CRM Builds and Deployments with PowerShell

Using the xRM CI Framework and Windows PowerShell you can easily extend the build and automate the deployment of your CRM Solutions.

PowerShell allows you to automate various processes by scripting the tasks that are normally performed manually on servers and applications. PowerShell is built on the .NET Framework. That allows you to use any .NET library in your scripts and allows you to work with and manipulate standard .NET objects in a friendly syntax that is close to C# and JavaScript.

Microsoft provides lots of PowerShell commands “cmdlets” that allow you to manage Windows Servers (IIS, File System, Registry) and applications such as Microsoft Office.

The Dynamics CRM SDK includes some PowerShell cmdlets but these are limited to managing CRM organizations through the Deployment Web Service. Check this post for more information about these.

The xRM CI Framework provides you with PowerShell “cmdlets” to allow you to script some of the task that are done manually during the build and/or deployment of Dynamics CRM Solutions.

Using the custom “cmdlets” you are able to assemble a script that can be triggered during your TFS build process or executed on demand from your desktop or other automation tools.

Below is a list of “cmdlets” that are available in the initial release:

CmdLet Name Description SDK Message
Import-XrmSolution Imports a CRM Solution ImportSolutionRequest
Export-XrmSolution Exports a managed or unmanaged CRM Solution ExportSolutionRequest
Get-XrmSolution Retrieves CRM Solution details using the unique solution name Not Applicable
Publish-XrmCustomizations Publishes all customizations for a CRM organization PublishAllXmlRequest
Add-XrmEntity Create a new entity in CRM CreateRequest
New-XrmEntity Creates a new instance of the Entity class Not Applicable
Set-XrmEntity Updates an existing entity in CRM UpdateRequest
Remove-XrmEntity Deletes an existing entity from CRM DeleteRequest

Note that most cmdlets will accept the “ConnectionString” parameter. The format is based on the SDK connection string and the cmdlet will use that parameter to connect to CRM.

To get started follow the setup instructions in my previous post.

To get more information about the parameters each cmdlet provides, run the Get-Help cmdlet as shown below from the PowerShell Console. More information on PowerShell can be found in  the PowerShell getting started manual. All the parameters are inline with the Dynamics CRM SDK messages of the corresponding cmdlets as shown in the table above.


The next step is to write your first PowerShell Script. Below is a sample script that checks the version of the currently deployed CRM solution and updates the target system if the version deployed is older than the latest version.

Write-Host “Deployment Started…”

# Import the xRM CI Framework Dynamics CRM Cmdlets
Import-Module “C:\Program Files (x86)\Xrm CI Framework\CRM 2011\PowerShell Cmdlets\Xrm.Framework.CI.PowerShell.dll”

#Define the CRM connection
$targetCrmConnectionUrl = “ServiceUri=http://test/testorg/XRMServices/2011/Organization.svc`;”

# Retrieve the solution details from CRM

$testSolution = Get-XrmSolution -ConnectionString $targetCrmConnectionUrl -UniqueSolutionName “TestSolution”

if ($testSolution -eq $null)
Write-Host “Test Solution not currently installed”
Write-Host “Current Test Solution version: “ -NoNewline $testSolution.Version

if (($testSolution -eq $null) -or ($testSolution.Version -ne “”))
$importPath = “”
Write-Host “Importing Solution: $importPath”

# Import CRM Solution
Import-XrmSolution -ConnectionString $targetCrmConnectionUrl -SolutionFilePath $importPath -PublishWorkflows $true -OverwriteUnmanagedCustomizations $true
Write-Host “Skipped import of Test Solution”

This library contains only a subset of what you can do with Dynamics CRM. You can expose any Dynamics CRM SDK message as a PowerShell cmdlet and use it to automate anything that you could be doing manually today.

Having your builds and deployment automated will allow you to build and deploy quickly and will give you the added consistency and reliability.

In future posts, I will show you how you can implement continuous integration by combining the automated builds discussed in this post and the PowerShell cmdlets for Dynamics CRM.