Setting Up Your Development Environment for Microsoft Dynamics CRM 4.0

Sonoma Partners and Microsoft Corporation

July 2009


As you develop solutions, keep in mind that Microsoft Dynamics CRM 4.0 uses the same recommended architecture and frameworks that most Microsoft developers are accustomed to seeing. You should build your development environment and use the tools in the way that makes the most sense for your organization.

For some insight, read this excerpt from chapter 2 of the book, Programming Microsoft Dynamics CRM 4.0 (ISBN 978-0735625945, copyright Microsoft Press 2008, all rights reserved).


As you begin your development with Microsoft Dynamics CRM, you might be wondering how to best get started. Common questions include: How do I configure a development environment? What do I test? What hardware should I be considering?

This chapter focuses on the available options for your development and also describes some useful development and deployment tools that can aid you in providing robust solutions on the Microsoft Dynamics CRM platform.

Development Environment

Obviously, any serious software developer uses a development environment to build and test any programming changes before updating the production system. When setting up your Microsoft Dynamics CRM development environment, you should consider the following factors:

  • The number of discrete projects or Microsoft Dynamics CRM organizations required

  • The number of developers

  • The types of customizations required

  • Deployment configurations

  • Available hardware

  • Iteration frequency and deployment schedule

Considering each organization has different needs based on these criteria, there is no “right way” to set up your development environment. The best option for your organization might not be appropriate for a different company.

The actual requirements of your production system dictate the environment you need to have in place for development (and testing). You should consider the following questions when beginning development on any Microsoft Dynamics CRM 4.0 project.

  • Do you use the Windows 2003 or Windows 2008 operating system?

  • Is your operating system 32-bit or 64-bit?

  • Do your customizations need to be multi-tenant-capable?

  • Will your application be accessed via the Outlook client?

  • Do your customizations require offline capability?

  • Do your customizations need to be SSL-compliant?

  • Will your application be accessed with IFD or Online deployments?

  • Do your customizations need to be Web farm–compliant?

  • Which version of Internet Explorer do your clients use?

  • Will your customizations be accessed in multiple languages?

  • What version of SQL Server is used, SQL Server 2005 or SQL Server 2008?

  • Will your solution need to be accessed via a mobile client?

Next we will review different alternatives regarding how you might want to set up your server and Outlook client development environments.

Server Environment Development Options

Because Microsoft Dynamics CRM requires several infrastructure components such as Active Directory, Windows Server and SQL Server, it’s not convenient to set up different physical server environments for developing and testing. In addition to requiring more servers (either physical or virtual), it can be time consuming just to set up these required components. Therefore, if you plan on having a team of developers working on Microsoft Dynamics CRM, you have a few other alternatives regarding how you set up your development server environment. The following sections explore four common development environment approaches:

  • Using an isolated development environment

  • Sharing a common Microsoft Dynamics CRM organization

  • Using a hybrid environment

  • Using different organizations in a single Microsoft Dynamics CRM deployment

Isolated Development Environment

An isolated development environment requires each developer to work from his or her individual (or isolated) copy of the Microsoft Dynamics CRM 4.0 application and database. This is most commonly done with a virtual image of Microsoft Dynamics CRM or when the base operating system of the developer's computer is Windows 2003 or Windows 2008 and Microsoft Dynamics CRM is installed directly on it.

This approach has the following advantages:

  • Complete isolation of the development experience, allowing for the developer to maintain his or her environment as appropriate

  • Simplified debugging of individual code

  • Easier to develop custom Web pages with Microsoft Dynamics CRM since you can reference and debug the pages directly on the server

The isolated development environment does have a few disadvantages, including:

  • You need to synchronize environment changes (customization changes) between multiple developers.

  • Managing backups of the environment is more challenging because each developer has a full copy of the Microsoft Dynamics CRM system.

  • Overall performance of the development computer may not be optimal because the developer's computer will be sharing resources with either the virtualization software or the Microsoft Dynamics CRM application.

  • Since you are installing the Microsoft Dynamics CRM software to each developer's computer or using multiple Microsoft Dynamics CRM virtual images, additional software licenses, such as SQL Server or the operating system software, may be required.

  • Properly testing Web farm scenarios is more challenging.

  • Large databases will take up more disk space and take longer to transfer between developer machines.

Figure 2-1 shows each developer's computer as a stand-alone Microsoft Dynamics CRM installation. You can (and should) share Active Directory and a development Exchange setup. The diagram also shows a build server used to aggregate Microsoft Dynamics CRM customizations and custom code from the development computers for deployment to a quality-assurance environment.


Figure 2-1 An example of an isolated Microsoft Dynamics CRM development environment

Although you should consider each of the disadvantages of the isolated approach, the most critical drawback that you should take into account is the merging of customization files. With multiple developers making schema and Microsoft Dynamics CRM customization changes on their discrete systems, you might have difficulty getting to a baseline set of final changes. It is possible to manually merge individual customizations changes between environments, but that process is tricky and often would negatively impact the efficiency of your developers or quality assurance team. If you plan to use this development environment approach, you should plan on including a programmatic approach to synchronize the environments between developers. For more information on manipulating system customizations with code, buy the book and read Chapter 8 “Developing with the Metadata Service”.

A hybrid environment approach, discussed later in this excerpt, offers a possible solution to the problem of merging customizations. But let's first look at a different development environment option, sharing a common Microsoft Dynamics CRM deployment.

Sharing a Common Microsoft Dynamics CRM Deployment

The shared approach requires all of your developers to work from a common shared Microsoft Dynamics CRM deployment. They still develop their code on their individual computers, but they reference the customizations (that is, schema) from a common installation.

This approach uses a common Web server or set of Web servers against a single database instance, so that each developer is always working on the most up-to-date schema and Microsoft Dynamics CRM customizations. You can also extend this approach by bringing up additional virtual servers pointed at the same Microsoft Dynamics CRM database, allowing you to use different server setups when developing and testing.

This approach has the following advantages:

  • Schema and Microsoft Dynamics CRM customizations are accessed from a single location.

  • Environment management is centralized for backups, storage space, and so on.

  • No additional server software licensing is required.

  • The load and specifications of each developer computer are reduced.

  • Accommodating environment permutations (32 or 64-bit servers, Web farms, IFD, and so on) is easier.

The shared development environment also has the following disadvantages:

  • The environment shares the asynchronous processing service and file system. This makes deploying and debugging changes more challenging for multiple developers working on any asynchronous logic (such as async plug-ins and workflow assemblies).

  • Remote debugging must be used.

  • Environment issues affect all developers.

Figure 2-2 shows a Microsoft Dynamics CRM installation shared by multiple developers. Each developer develops locally on his or her computer, but uses the schema and database from the shared Microsoft Dynamics CRM setup. The build server in this example merely compiles the custom code and extracts the customizations before applying them to a quality-assurance environment.


Figure 2-2 An example of using a shared Microsoft Dynamics CRM development environment

The key downside to the shared approach involves the Async service. Unfortunately, the Async service scans and executes against all organizations in the mscrm_config database. As you scale organizations to a centralized SQL Server computer, all of your developers are forced to use and debug against a single instance of the Async service.


Microsoft Dynamics CRM does not include an automated build server; you must set up your own if you want to leverage this functionality.

Using a Hybrid Environment - Option 1

Now another variation of the third alternative combines different facets of the first two environments. We start by assuming you provide isolated Microsoft Dynamics CRM environments for each developer. That means each developer's computer requires a separate version of SQL Server 2005 or SQL Server 2008 and Microsoft Dynamics CRM 4.0 and the developer programs his or her changes against the separate instance of Microsoft Dynamics CRM. Just as with the other approaches, you use the existing Active Directory infrastructure and a development Exchange environment. This provides all of the benefits described in the earlier section “Isolated Development Environment.”

To help mitigate the main challenge of synchronizing Microsoft Dynamics CRM customizations between each development computer, you can create a shared customizations environment and force your team to make all Microsoft Dynamics CRM–related customization changes (such as schema updates) through that environment. Then you can automate a database backup/restore back to the individual developer environments either on a schedule or manually kicked off as needed. You need to be sure to backup/restore the common mscrm_config as well, since Microsoft Dynamics CRM has some identifiers stored in there.

A few disadvantages also exist with this approach. The main disadvantage of this approach is that you will need to develop your own code and process to set up the automatic synchronizations of the database and customization changes. Further, your staff needs to remember to make all customization-based changes to the centralized environment and synchronize back down to their environment. Finally, if you have a very large CRM database, then the time it takes to copy the backup file may be a concern.

Figure 2-3 demonstrates a possible example of the hybrid development environment approach.


Figure 2-3 An example of a hybrid Dynamics CRM development environment

The next section discusses another variation of the hybrid environment that provides some level of isolation, while still maintaining a centralized environment for customization changes.

Using a Hybrid Environment - Option 2

In this approach, we provide a partially isolated environment, but one that is much easier to maintain than the previous hybrid environment option discussed. Start by providing Microsoft Dynamics CRM environments for each developer, but instead of pointing the installation to a local instance of SQL Server, point it to the centralized environment's SQL Server. Now, the developer can access CRM and any local web files and services directly from the development server. Just as before, all of the CRM customization changes are managed through the centralized server. However, since the local development Web server points to that centralized database, no changes need to be synchronized.

This approach also allows you to avoid having to install and manage another SQL Server instance. The main negative is the developer will have to share an Async service with the centralized CRM server as described with the Sharing a Common Microsoft Dynamics CRM Organization approach, discussed previously.

Using different organizations in a single Microsoft Dynamics CRM deployment

While the first three options provide the most flexibility for developers, another potential and simplified development environment option exists. By taking advantage of the multi-tenant functionality within the enterprise edition of Microsoft Dynamics CRM, you can simply create additional separate organizations for each environment (development, testing, and so on).

This approach has the following advantages:

  • Provides development and testing environments that share a common set of hardware with no additional cost.

  • You can be confident that the development system hardware specifications match the production system.

The multiple organization development environment has the following disadvantages:

  • Server problems caused during development and testing will negatively impact production (or the other organizations on the server).

  • Common development tasks such as resetting services or debugging code will affect production.

  • Any custom Web page or Web service development becomes more challenging since you are sharing Web servers with production.

  • Requires the enterprise edition of Microsoft Dynamics CRM.

Since the multi-tenant option reuses the same hardware as your production system, it works best when the configuration of Microsoft Dynamics CRM focuses mostly on native customizations and workflow. Native customization and workflow changes are contained within the Microsoft Dynamics CRM application and are easily developed and deployed between organizations.

When possible, we recommend separating your development environment on its own set of hardware. However, if you are unable to use separate hardware for the development environment, then consider the multi-tenant option over making programming or customization changes directly on the production organization.

Developing Customizations Accessed From Outlook

In addition to setting up your Microsoft Dynamics CRM development server, you should also think about how you will test your programming customizations within Microsoft Dynamics CRM for Outlook. In general, most of your customizations should execute equivalently from the Outlook interface, but if you have offline use as a requirement, you need to ensure that your logic works properly when disconnected from the server.

Microsoft Dynamics CRM for Outlook allows you to target only one Microsoft Dynamics CRM organization at a time. We recommend that you install the Outlook client on a separate desktop computer for testing and development. If you need to change your Outlook client from one organization to another, you can do so using the Outlook CRM client's Change Organization menu option. Virtualization offers an excellent option for Outlook client environments.

Because Microsoft Dynamics CRM for Outlook synchronizes contacts, activities, e-mail, and appointments into Outlook, you probably don’t want to install this software on your normal Outlook profile. Therefore, it’s a good idea to setup a separate test user and use that profile for testing, avoiding accidentally contaminating your Outlook file with data from the test and development environments.


You can only install Microsoft Dynamics CRM for Outlook with Offline Access for a single user on a computer. However if you’re using the non-offline version, you can login to a computer with multiple users to access the software. Therefore, you could set up a single machine for testing the non-offline version, and log on to the computer using different users (one for each organization).

For more information, buy the book and read Chapter 10, "Developing Offline Solutions," which discusses developing with the Outlook client in greater detail.

Development Tools

Every organization that develops software relies on development tools. One of the great benefits of Microsoft Dynamics CRM is that you use the same tools to develop solutions with Microsoft Dynamics CRM that you use when developing solutions for any Microsoft technology. Therefore, none of the tools discussed in this section is unique to working with Microsoft Dynamics CRM.

This section examines some of the common software development tools you should have in place when working with Microsoft Dynamics CRM, including:

  • Integrated development environment (IDE)

  • Source control

  • Continuous integration

  • Installer

  • Additional development utilities

Integrated Development Environment (IDE)

Microsoft Visual Studio is most likely to be your primary integrated development environment (IDE). Because Microsoft built Microsoft Dynamics CRM on the .NET architecture, you may use any .NET client tool for your development experience (including Notepad)! However, most developers working with Microsoft Dynamics CRM choose Visual Studio as their development tool.

Source Control

Source control defines the means of keeping track of changes and versions to all software files during a project. Numerous tools exist to perform this function and typically a source control system already exists within your environment, including Microsoft Visual Studio Team System, Microsoft Visual SourceSafe, CVS, ClearCase, Vault, and so on.

If you don't have a version control tool in place or you are investigating an alternative, we recommend a free, open-source tool call Subversion (SVN). SVN provides the core file control logic and integrates to most systems. Additional tools talk to SVN for actual file access; the most popular is Tortoise, as shown in Figure 2-4.


Figure 2-4 TortoiseSVN browser menu

More Information Learn more about SVN version control system and the TortoiseSVN browser at: and

Continuous Integration Tool

Often as you bring up your development environment, setting up a continuous integration environment tends to get overlooked. However, a continuous integration system, especially automated builds, provides the following benefits:

  • Ensures a more robust application during development by finding build defects quickly

  • Simplifies deployments by ensuring a consistent set of files and steps

  • Can include additional post-build steps and processes

  • Labels source code at each build version, allowing you to branch and fix issues easily

  • Can be used to export and store customizations as a backup file

  • Can provide additional automated testing

SourceForge.NET provides an excellent free tool called CruiseControl.NET to manage automated builds for your code. You can use also CruiseControl.NET in conjunction with MSBuild from Visual Studio or a free tool such as NAnt from SourceForge.NET.

You may download and review more information regarding CruiseControl.NET at and NAnt at


Some of your Microsoft Dynamics CRM customizations may not deploy with the Microsoft Dynamics CRM import/export customizations functionality, including:

  • Custom Web pages

  • Plug-in assemblies

  • Workflow assemblies

  • Custom reports

  • Data migration

When you deploy files and changes that are not encapsulated within Microsoft Dynamics CRM's import/export customization functionality, you should consider whether you need to use an installer.Multiple installer programs exist on the market, including one that comes with Visual Studio. Each installer program has its own set of features, functionality, and benefits. In addition to the Visual Studio installer, we also regularly use the Nullsoft Scriptable Install System (NSIS) from SourceForge.NET.

NSIS provides robust Windows installers in a very easy, scriptable, and extensible framework. Using NSIS you can create common installation wizard pages that can take information from the user and use built-in or custom functions to properly deploy and provision your application.

NSIS contains a tool that allows you to compile NSI scripts into executables, as shown in Figure 2-5. Additionally, you can access numerous additional plug-ins, starter code, and help documentation to provide a solid start to your installation development.


Figure 2-5 NSIS Menu


You can also use a development tool such as Eclipse with an NSIS plug-in to author and build your installation scripts. You can learn more about EclipseNSIS at

The following example shows a very simple script that generates an installer that copies a simple help file to a defined location.

Name "NSIS Test"

# Defines
!define REGKEY "SOFTWARE\$(^Name)"
!define TRUE 1

# MUI defines
!define MUI_ICON "${NSISDIR}\Contrib\Graphics\Icons\modern-install.ico"

# Included files
!include Sections.nsh
!include MUI.nsh

# Installer pages
!insertmacro MUI_PAGE_WELCOME
!insertmacro MUI_PAGE_FINISH

# Installer languages
!insertmacro MUI_LANGUAGE English

# Installer attributes
OutFile setup.exe
CRCCheck on
XPStyle on
ShowInstDetails show

# Installer sections
Section "Help Sample" Main
    SetOutPath $INSTDIR
    SetOverwrite on
    # Copies HelpSample.htm to the path specified in the installation wizard.
File "HelpSample.htm"
    WriteRegStr HKLM "${REGKEY}\Components" "Help Sample" 1

# Installer functions
Function .onInit

Figure 2-6 displays one of the sample wizard pages for a Windows installer using the sample NSIS script in Listing 2-1.


Figure 2-6 Sample Windows installer

For additional information regarding NSIS, please visit

Additional Development Utilities

If you develop solutions with any Microsoft technology, including Microsoft Dynamics CRM, you definitely should consider having the tools listed in the following table.

Additional Development Utilities

Tool Download


A free code best practice analyzer. You can incorporate it into your automatic builds and it is highly customizable.


A free tool to merge multiple assemblies into a single assembly. Perfect for deploying referenced assemblies with a plug-in or workflow assembly.

.NET Reflector

An excellent tool for analyzing .NET assemblies.


A free HTTP debugging proxy tool. Fiddler is essential for tracking and parsing the HTTP traffic between Microsoft Dynamics CRM both for development and debugging purposes.


A licensed Web development tool that integrates directly within Internet Explorer. Allows you to quickly navigate the DOM of a Microsoft Dynamics CRM Web page.

IE Dev Toolbar

A free Web development tool with functionality similar to the DebugBar tool.


A free, open-source unit-testing framework.


Another free, open-source unit-testing framework.

Additional Development Considerations

In addition to the topics discussed in depth within this chapter, please keep the following items in mind as you prepare your environments.

  • Thoroughly review the Implementation Guide for installation and configuration details about Microsoft Dynamics CRM deployment and environment options.

  • Understand the business requirements for your Microsoft Dynamics CRM project and how they affect development and testing. You should have an environment for each configuration you plan to support that mirrors production.

  • Create both a development and a staging environment. You can make use of virtualization to help mitigate hardware costs.

  • Use a source control system (for example, Visual Source Safe or Subversion) for your custom files and consider a continuous integration tool (such as CruiseControl.NET) as well.

  • Back up your databases and any custom source files. You can use the Microsoft Dynamics CRM API to easily export your customizations and include that in your backup procedures.

  • Multi-tenant deployments require Microsoft Dynamics CRM 4.0 Enterprise Edition.

  • You can add and delete organizations only through the Deployment Manager installed on the Microsoft Dynamics CRM Web server.

  • Microsoft Dynamics CRM 4.0 stores all of its transactional data and metadata in one database called <organization>_mscrm, where <organization> is the name of the organization you configured when you deployed. In addition to this database, Microsoft Dynamics CRM uses one configuration database (mscrm_config), which manages the different organizations and their settings installed on that SQL Server instance.

  • Microsoft Dynamics CRM 4.0 allows only one installation per SQL Server instance. You need to install another brand-new Microsoft Dynamics CRM environment to another SQL Server instance or a completely separate SQL Server instance.

  • You can share SQL Server, Reporting Services, and Exchange Server hardware between your staging and development environments, provided that you use multi-tenancy.

  • You can use virtual servers to create complete instances of Microsoft Dynamics CRM or any of the components. Monitor performance and determine whether you need to apply more resources to the virtual image or possibly move to a physical server.

  • Remember that each organization is an isolated environment of customizations and data. You cannot natively share data or records between organizations, although you can write tools (or find third-party tools) to synchronize the data.

  • Create organizational units (OUs) in your development Active Directory domain for each separate installation so that it is easier to keep track of your installation groups in Active Directory.

  • Use the new import organization feature of the Deployment tool to synchronize your data between Microsoft Dynamics CRM deployments in different domains. You cannot simply restore the databases to the new domain because the system GUIDs will not match.

To read more about development with Microsoft Dynamics CRM 4.0, buy this book.