Select Page

The CRM Field Guide – How to CRM like an MVP with Dynamics CRM

The latest book, for which I am a contributing author, is now available for Online, Digital only purchase.

Get The CRM Field Guide now at

The CRM Field Guide is an essential guide to Microsoft Dynamics CRM that everyone should have on their (digital) bookshelf. This book offers you details not only on CRM fundamentals and extensibility points but also the tried and true best practices and strategies of the combined experience of some of the most recognizable global experts in the CRM industry. The field guide contains insights from many CRM MVP contributors and is intended to be a book you pick up over and over again as you use CRM.

Having the CRM Field Guide by your side is like having the “hotline” to the industry experts. When you hear the term Field Guide you likely think of nature; identifying key plants or animals in a new and exciting place. Obviously this book is not that type of a guide. This book is what you pick up when it’s Friday night and you are stuck with one last CRM problem between you and the weekend.

The CRM Field Guide is not a reference repeating all the contents of the CRM documentation, but it is designed to complement what Microsoft provides offering insights from real world deployments of Microsoft Dynamics CRM. There’s so much content in the CRM Field Guide, one of the MVPs joked it could probably have enough weight to hold down your desk if a tornado passes through your office!

In the CRM Field Guide you will find details that can help administrators, customizers and developers; not to mention power business users wanting to know all the details the admin never tells them. If you run CRM in the cloud or sitting in a server room at your office the information is useful

CRM 2013 QuickStart Book now available!

CRM 2013 QuickStart Book now available!

CRM 2013 QuickStart

CRM QuickStartBrought to you by the same team you’ve already learned from in The CRM Field Guide, Building Business with CRM and more.  As always we bring you internationally recognized CRM experts, all of the authors are current Dynamics CRM MVPs. (Myself,  David Yack, Joel Lindstrom, David Berry, Richard Knudson and Jukka Niiranen)

Go to the site and purchase your copy today.


Me and My CRM Developer Toolkit

I have been a big evangelist of the CRM Developer Toolkit for some time now and it continues to become more and more of a key component of all of the projects that my company engages in.

Our chosen project delivery methodology is Agile and as a result the Deployment optimisation in terms of ease of use and time to deploy provided by the CRM Developer Toolkit provide a significant benefit to our projects, so much so that when we recently took over a large project, the customer had previously been exposed to deployments of between 2 and 5 days and a 58 page installation manual for each deployment, that required step-by-step accuracy in order to complete a successful deployment.

Now deployment takes 15 mins, there is a 2 page installation guide and the deployment can be done by anybody.

Over the next few weeks I will be posting on how we make use of the CRM developer toolkit, some of the quirks and some changes and enhancements that me make to it, including how to make it fully support 64-Bit deployments on a Windows 2008 R2 CRM Server environment (Out of the box it only handles 32 Bit Windows 2003 deployments)

Creating a new CRM Development Project using the CRM Developer Toolkit

For todays post we are going to look at how I go about setting up a new Visual Studio project for a CRM Project using the CRM Developer Toolkit.

I am not going to go through how to setup your development environment or how to install the CRM Developer Toolkit bits as this is adequately covered in the Customizing CRM by Using the Microsoft Dynamics CRM Developer Toolkit guide that comes with the CRM Developer Toolkit

While the CRM Developer Toolkit talks about using TFS for source control, we have currently opted to use SVN (mostly as I find it a whole lot simpler than TFS) but you can use either.

So to start off you run the setup.cmd from the CRMSolutionFramework folder using the following syntax : Setup.cmd {InstallDir} {ProjectName} {Project Long Name} {Organisation Name}


So for me I called the project ToolkitDemo and put it in a folder C:\Projects and connected to a CRM organisation called MicrosoftCRM.


Next I add the Solution to SVN


The reason I add it now is so that we can ensure Source Control doesn’t have any unnecessary files that are generated by the build as it just makes the repository bigger, and all those files can be recreated just by doing a build.

Some Tweaks and Fixes

The following are some tweaks and fixes that I make to a new project.

The CRM Developer Toolkit includes a project called “BatchService” which enables the installation and use of a Windows Service to perform scheduled tasks. I like to disable the installation of this until you require it. To do that you need to modify the build events for the BatchService project, by right clicking on the BatchService project under Services in your solution and going to Properties, you then go to the Build Events section and comment out or remove the Pre-build and Post-build event command line.


Changed to :


Next I modify the website path (for the build) for both the CustomWebPages project and the CustomWebServices project to ensure that they deploy into the ISV folder where I want them to.

To do this you right click on the CustomWebPages and CustomWebServices projects under the ISV tree in your solution and select Unload Project and then right click again and select Edit Project.


For the CustomWebService project you need to modify the following code in the first PropertyGroup section to suite your requirements :

  1. <!– Custom Property: Defines if Website should be copied to CRM ISV Folder –>
  2.  <PublishWebsiteToCrm>true</PublishWebsiteToCrm>
  3.  <!– Publisht to an alternative folder – default is project name –>
  4.  <PublishedCrmFolderName>xRM\WebServices</PublishedCrmFolderName>

The <PublishWebsiteToCrm> tag determines whether or not to publish to the ISV folder and the <PublishedCrmFolderName> tag determines where to publish it in the ISV folder, so in this example our custom web services will be deployed to ISV/xRM/WebServices folder.

The resulting PropertyGroup section should look like this :

  1. <PropertyGroup>
  2.     <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
  3.     <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
  4.     <ProductVersion>9.0.30729</ProductVersion>
  5.     <SchemaVersion>2.0</SchemaVersion>
  6.     <ProjectGuid>{4C7AF20F-A0FB-4DAF-8F10-48C258E38510}</ProjectGuid>
  7.     <ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
  8.     <OutputType>Library</OutputType>
  9.     <AppDesignerFolder>Properties</AppDesignerFolder>
  10.     <RootNamespace>ToolkitDemo.WebServices.CustomWebService</RootNamespace>
  11.     <AssemblyName>ToolkitDemo.WebServices.CustomWebService</AssemblyName>
  12.     <TargetFrameworkVersion>v3.0</TargetFrameworkVersion>
  13.     <SccProjectName>
  14.     </SccProjectName>
  15.     <SccLocalPath>
  16.     </SccLocalPath>
  17.     <SccAuxPath>
  18.     </SccAuxPath>
  19.     <SccProvider>
  20.     </SccProvider>
  21.     <!– Custom Property: Defines if Website should be copied to CRM ISV Folder –>
  22.     <PublishWebsiteToCrm>true</PublishWebsiteToCrm>
  23.     <!– Publisht to an alternative folder – default is project name –>
  24.     <PublishedCrmFolderName>xRM\WebServices</PublishedCrmFolderName>
  25.   </PropertyGroup>

You will need to add these lines to the CustomWebPages project as they do not exist by default.

The above changes ensure that when running our DevBuild.bat process that these sites are deployed where we want them, in order to ensure that when we create our MSI’s for deployment using the DailyBuild.bat that the websites still go where we expect them we need to make some changes to the WIX (Windows Installer XML) templates for our MSI packages.

To do that we need to modify the Main.wxs.template files in \BuildScripts\Packaging\ToolkitDemo.ISVPages\Templates and \BuildScripts\Packaging\ToolkitDemo.ISVWebServices\Templates

For ISVPages you need to modify the following tags :

  1. <Directory Id="ISV_DIR" Name="ISV">
  2.               <Directory Id="CUSTOMPAGES_DIR" Name="Custom" LongName="xRM">
  3.               </Directory>
  4.             </Directory>

and change the LongName value to what you want, in my case “xRM” and for the ISVWebServices you need to make a similar change but also need to add a subdirectory called WebServices so it would look like :

  1. <Directory Id="WEBBIN_PATH" Name="bin">
  2.             </Directory>
  3.             <Directory Id="ISV_DIR" Name="ISV">
  4.               <Directory Id="CUSTOMPAGES_DIR" Name="Custom" LongName="xRM">
  5.                 <Directory Id="WEBSERVICE_DIR" Name="WebSvc" LongName="Webservices">
  6.                 </Directory>
  7.               </Directory>
  8.             </Directory>
  9.           </Directory>

If you are doing a deployment to the c: drive or another drive other than d: then you need to make a few changes as well (although you can change these at runtime of the installer, if you repeat the deployment process many times it gets a bit arduous)

Modify the DeploymentDefinitions.xml file in the BuildScripts\bin\Deploy\1.0\Framework directory. Change the following 2 properties to match the drives you are using :

  1. <Property
  2.         Name="DeploymentShareName"
  3.         Category="Connection"
  4.         Description="Which share to connect to on the deployment host.">d$</Property>
  6.     <Property
  7.         Name="DeploymentPath"
  8.         Category="Connection"
  9.         Description="On the deployment target, which drive is used.">d:</Property>


Also change the following property in the PropertyDefinitions file in \BuildScripts\Deployment\DeploymentProperties  :

  1. <Properties xmlns="urn:sdc-microsoft-com:deployment:properties:v2.0">
  2.   <Property Name="INSTALL_ROOT_DRIVE" Value="D:\\cf0 " Category="Setup" Description="The root drive into which install the application." />

You need to make the same changes to the Sample.proj and Sample.xml files in \BuildScripts\Deployment\RigTemplates

I also usually change the Import Batch Size key in the PropertyDefinitions file fro 5 to 20. The Deployment installer imports CRM customisations in batches of x entities at a time, so using 5 makes the install take a little longer than changing it to something like 20.

  1. <Property Name="CRMSVC_IMPORT_BATCHSIZE" Value="5" Category="CRM" Description="The number of entities to import together in a batch." />

I would then commit the above changes to Source Control.

Next I would run a DevBuild.bat


After the Devbuild has completed, do a commit and add everything to the Ignore list so that any files created by the build are never committed to Source control


Follow the same process as above but for the DailyBuild.bat

You are now ready to start using the CRM Developer Toolkit.

Look out for some of my upcoming posts which include the following and more :

  • Enabling Automatic Build Number Generation in the CRM Developer Toolkit
  • Adding a WorkflowPlugin Project to the CRM Developer Toolkit
  • Fully Enabling 64 Bit Support for the CRM Developer Toolkit
  • Understanding MSBuild Tasks
  • and more ……