Blog Archives

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.

Building the CRM Developer Toolkit Solution (CrmPackage) in the Cloud (TFS Online)

As most of you probably know, Microsoft released an online version of  TFS that is host in the cloud. You can find more information about this

This allows you to store and manage all the artefacts related to your application life cycle management in the cloud. This includes source control, work item management and testing.

One of the cool features that TFS provides is Automated Builds. This can among other things compile your code in a consistent way and also run automated tests and produce packages such as your CRM solutions.

TFS online comes with a hosted pre-configured build controller that you can use to build your software. This comes pre-configured with a list of software packages. These don’t include the CRM Developer Toolkit. As such trying to compile any Visual Studio projects created using the CRM Developer Toolkit will not work by default.

In this post I will show you how to configure your CrmPackage project to make it compatible with the hosted build controller.

A typical project created using the CRM Developer Toolkit will look something like the below. This contains Plug-in,Workflow and  XAML Workflow projects. It also contains the CrmPackage Project that is used to deploy all the previous components.

Once you created the projects, you will notice that all references to the CRM Sdk and Developer Toolkit Libraries are pointing to the local installation folder of the Developer Toolkit which will not be available on the Hosted Build Server.


To get everything to build online, you will need to store all CRM Sdk libraries in source control and change all the references in your projects (Plugins, Workflows, XAML Workflows) to point to the relative path in your workspace.


The next step is to fix the CrmPackage Project. Right click on the project and select Unload.


Then Right click and edit.


Locate the import statement below. This imports the developer toolkit targets from the installation directory.

  1. <ImportProject=$(MSBuildExtensionsPath32)\Microsoft\CRM\Microsoft.CrmDeveloperTools.12.targets />

Before you change that, you will need to copy the files from the installation directory below and store them in source control along with the CRM Sdk binaries.


Now change the import statement to the relative path in your source control workspace as below.

  1. <ImportProject=..\Lib\CrmSdk\Microsoft.CrmDeveloperTools.12.targets />

Now you can save and reload the package project.


At this stage you should be able to rebuild the package project successfully  and all the dependencies should be in your workspace together with your source code. Check-in all your changes into source control.

The next step is to create a Build Definition. For example you can create a build definition to compile your code and run your uni tests every time somebody check-in any code. This will ensure that the latest version of your code is always working.

More information on creating build definitions can be found

In my next posts I will show you how to configure and modify your Build definitions to make them more useful. This will include things such as producing CRM Solutions.