To conclude, we want to discuss a sample deployment sequence. In this example, we discuss the deployment steps of a simple and hypothetical application built by our favorite fictional company, Contoso.
We will install an application that provides enhanced privacy functionality in the form of a Do Not Email (DNE) list. Many companies maintain such lists to ensure that they do not violate privacy policies when conducting outbound sales and marketing activities.
The hypothetical DNE application maintains the list of e-mail addresses in a custom entity. Plug-ins assist with intercepting any outbound e-mail sent by Microsoft Dynamics CRM and validates the e-mail address against the DNE list. A custom Web page, shown in an IFRAME on the Account, Contact, and Lead forms shows the user if a record is in the DNE list.
We list an inventory of a solution’s components to analyze the various techniques that will be required to install, configure, and uninstall our solution. For our sample application, we need the following:
Custom DNE entity
IFrame configured on the Account, Contact, and Lead forms
Custom Web page
Plug-in
Now that we have our components, let’s review each of the deployment steps.
The DNE application consists of two components to build: the plug-in and the Web form. In this case, both will be compiled using Visual Studio 2008. They will use CLR 2.0 and require the .NET Framework 3.5 SP1.
Our common set of files in the DNE application will be the Web files. As such, we want to ensure that this application is multi-tenant friendly and only deployed one time to each of the Web servers in our deployment. The Web page will be installed using a custom installer to deploy the files to each Web server used by the Microsoft Dynamics CRM environment. The installer follows the Microsoft Dynamics CRM recommendation and copies the files to the following locations:
wwwroot$in: the compiled Web application assembly for the Web site will be placed here. Note that the assembly has a strong name such as Contoso.DoNotEmail.WebSite.dll.
wwwroot$ISVContosoDoNotEmail: Any ASPX, CSS, and image files for the solution will be placed here.
The installer should also check for the .NET Framework 3.5 SP1 to be present on all the Web servers.
The configuration of the DNE application deploys all of the components unique to the organization. In this example, we perform the following steps during the configuration step:
Import the DNE entity
Update security roles to allow access to the DNE entity
Modify entity forms to add IFrames
Publish customizations
Register the plug-in
The configuration steps are packaged using a configuration application called DNE Provisioning Utility. The DNE Provisioning Utility can be a simple console application, a Windows Presentation Foundation (WPF) application, or client executable. The tool requires the following information and then begins configuring the application:
URL of the Microsoft Dynamics CRM server
Organization name
Authentication information
Since this solution contains a plug-in, the DNE Provisioning Utility will use the RegisterSolution message from the CrmService Web service. Therefore, use Windows Authentication to authenticate to the CrmService, and the user must be a member of the Microsoft Dynamics CRM deployment group.
The removal of the DNE application can be achieved by uninstalling the Web files from each Microsoft Dynamics CRM Web server (from Add/Remove Programs or by re-running the installer) and by manually deleting the customizations in the CRM organization.
Alternatively, you could augment the DNE Provisioning Utility to remove the components provisioned during the configuration step. Manual removal of customizations is often preferable for customers to avoid unintended removal of data or if other customizations are dependent on the new entity. You need to provide a programmatic way to remove the plug-in, or use the plug-in registration tool provided by Microsoft.