Developers commonly perform regular builds to their development environments. With Microsoft Dynamics CRM, each type of application extension, such as a plug-in or customization change, has its own set of steps required to compile the solution. We will not review each of those aspects again, as they are covered in depth in the other chapters of this book.

From an overall deployment perspective, be mindful of the additional requirements that your solution needs for a successful testing or production deployment. In each of these cases, not only do you need to have the additional components available during the build process, but they also must be available on the destination environment. For instance, Microsoft Dynamics CRM only requires the Microsoft .NET Framework 3.0, but you can’t always be sure that the .NET Framework 3.5 is present on the server or the client. If you decide to include references to .NET Framework 3.5 libraries, your installation process should perform a dependency check.

Tip

Be sure to include any dependencies required during the build phase in your installation process.

When building plug-in or workflow assemblies, those assemblies must be strongly typed. Also, you should use fully qualified assembly names for any Web site code. Typically this is done by including the full namespace of your project in the assembly name. These assemblies will be placed in the bin folder of the Microsoft Dynamics CRM Web site (see Figure 9-1) and therefore require unique names.

Figure 9-1. Visual Studio 2008 Web site properties

If you prefer the ASP.NET Web site approach, you need to download the Visual Studio 2008 Web Deployment Projects add-in for Visual Studio. This is a fully supported add-in released by Microsoft that offers additional and advanced build capabilities for Web sites. You can download it here: http://www.microsoft.com/downloads/details.aspx?FamilyId=0AA30AE8-C73B-4BDD-BB1B-FE697256C459&displaylang=en.

Important

Your Web application (project or site) should not rely on a Web.config. Your application will inherit the settings of Microsoft Dynamics CRM’s Web.config. Microsoft does not support modifying Microsoft Dynamics CRM’s Web.config (to prevent developers from breaking other solutions), so your code should never rely on any settings in this file.

Once you have built your application, you are now ready to install it to another environment. As part of the build process, you decide on and document the actions required to deploy the solution. We define installation as the process of applying the files, keys, and scripts that comprise your solution to target computers or servers. The installation process typically consists of the following two options:

More often, you might end up using a combination of these options for your final deployment package. Consider the following factors when choosing an installation process:

If possible, we recommend creating an installer program to help minimize the potential for error. Your installer program will bundle your plug-ins, workflow activities, and custom Web pages. As discussed in Chapter 2, you have numerous options and tools available to create an installation program. While we prefer to use NSIS from SourceForge, you can also use Visual Studio 2008, which has support for creating installers for Windows and Web applications, as shown in Figure 9-2.

Figure 9-2. Visual Studio 2008 Add New Project dialog box

Note that the installation step takes place at the overall deployment level. This means that the assemblies and files are potentially accessible by all organizations within a given deployment. You should handle organization-specific settings during the configuration step, which we describe next.

During the install process, you should not configure any information about a specific Microsoft Dynamics CRM organization for your solution. Instead, we recommend that you separate the installation from the configuration as much as possible. The various Microsoft Dynamics CRM clients (Microsoft Dynamics CRM for Outlook, Data Migration Manager, and E-mail Router) are all excellent examples of this pattern. Each has a Microsoft Installer Package (MSI) that copies files, adds standard registry settings, adds assemblies to the Global Assembly Cache (GAC), and registers the program with Add-Remove Programs (ARP). During installation of these clients, absolutely no organizational information is collected or stored. A separate configuration process covers this. The reason for this approach is simple: If users want to reconfigure the application, they don’t require the installer to do any action. It also allows for lower-privilege users to conduct configuration while still requiring administrators to install the solution.

It’s also important to remember that multiple Microsoft Dynamics CRM servers may be used in a deployment. You should run your installer on each Microsoft Dynamics CRM server separately, which is another good reason to separate the install step from the configuration step.

The configuration step of a deployment solution involves collecting organization-specific information and then storing or using those values for your solution to use. Assuming you are using the Microsoft Dynamics CRM Web services, your application may require such information as:

As we mentioned, Microsoft Dynamics CRM for Outlook uses a stand-alone configuration tool called the Microsoft Dynamics CRM Configuration Wizard to bind the client to an organization, as shown in Figure 9-3. When you configure Microsoft Dynamics CRM for Outlook, you will need to enter your Microsoft Dynamics CRM Web server and select an organization (if you have access to more than one).

Figure 9-3. Microsoft CRM 4.0 Outlook Client Configuration Wizard

As part of your installer, you may want to cache information you retrieve from the Discovery Service (for example, the URLs of the CrmService Web service, MetadataService Web service, application user interface, and so on) to prevent having to make multiple calls to the service. However, it is important that you not treat this information as static because it is subject to change.

If your custom application uses Microsoft Dynamics CRM filtered views or any database scripts, you should also collect the Microsoft SQL Server connection string information during the configuration process (authentication, server name, database name). As a reminder we highly recommend that you use Integrated Windows Authentication to connect your custom code to the filtered views in the SQL Server database.

Tip

If end users are conducting the configuration, it’s ideal to use a wizard-style experience to guide them through the process. If your application is configured by IT professionals, you may want to use an XML file of configuration settings.

If you decide to create a stand-alone configuration application for your solution per our suggestion, the following steps demonstrate how this wizard application might function:

Tip

Be careful when using IFD for your configuration wizard. Plug-ins and workflow activities cannot be registered using the IFD authentication method.

As soon as you configure your application it should be ready for use. Your application should also allow users or administrators (whichever is appropriate for your scenario) to reconfigure the application at any time.

While many developers spend a lot of time worrying about the software installation process, uninstalling an application is often overlooked. However, providing a good uninstall process is a good practice for your organization. In some cases, the uninstall process can be relatively straightforward if you choose an automated installer approach such as MSI. Be sure that your uninstall process also cleans up any installation files or components as well as any configuration information (registry settings, XML files, and so on) added by your application.

During uninstall, you must decide whether or not to change any Microsoft Dynamics CRM modifications made to the organization. You should carefully examine the usage scenarios for your application and determine whether these modifications (for example, new custom entities and data) might be required after the solution is uninstalled. For example, when a user uninstalls a word processor, he doesn’t expect all his documents to be deleted.

Tip

Create a separate cleanup package to remove any organization modifications. Allow users and administrators to run this package separately. This ensures that critical data is not accidentally deleted during uninstall.

The uninstall process of a Microsoft Dynamics CRM solution has two primary components:

Removing the Solution Components

An MSI is the best way to remove your static files, registry keys, and assemblies from the GAC. When you create your MSI with most installer programs, the uninstall process is automatically included. Simply run the MSI executable again or select Uninstall from Add/ Remove Programs in Control Panel.

Caution

You need to be sure that items (such as registry keys, common files, etc.) required by other programs aren’t accidentally removed by your uninstall process. Be careful to review and test what parts of your solution will be removed.

Deleting Metadata and Transactional Data

The removal of organization-specific data can be more challenging. You should be mindful of scenarios where deleting the data is unacceptable (for example, when you uninstall Microsoft Dynamics CRM it never deletes the Microsoft Dynamics CRM databases to avoid the accidental loss of critical information).

The simplest approach would be to restore the database from a previous backup. This approach works fine for some development and testing environments (such as to facilitate rollback scenarios when testing an installer), but does not work in a live production environment. For the production environment, consider creating a cleanup program, similar to the Configuration Wizard described earlier, that gives an administrator the choice to remove some or all of the metadata and data related to the solution on the system.

For deleting entities, use the DeleteEntity message located within the MetadataService Web service. For modifying the user interface, use the same techniques that you used to add this data (export, modify the XML schema, and then re-import). You can use the UnregisterSolution message to remove plug-ins and workflow activities.

Tip

Encourage your customers to make a database backup before uninstalling your solution. This simple step can save big headaches later on if the decision to uninstall was the wrong one!