Section 9.7. Deployment Models

9.7. Deployment Models

Some of the most attractive features of .NET are the deployment options. Microsoft has realized the hectic nature of application deployment and provided several simple standards.

9.7.1. XCopy Deployment

Remember the DOS days when you could transfer applications from computer to computer via a simple XCOPY command? Well, those days are back. Several features make this possible:

• You no longer have to register DLLs (or assemblies) on the system to use them. You can include private assemblies within the application's folder structure.

• Registry access is discouraged. Because of the variety of deployment options and the limited permission set granted to code, in some situations registry access is even prohibited. You can store configuration information and settings in XML files within the application's folder structure.

• The runtime monitors web application files for changes. When changes are made, they are reflected live in the application.

XCOPY deployment does not require that you use the XCOPY utility. You should use Windows Explorer, FTP, batch files, or whatever suits you best. The concept to digest here is that .NET applications have broken many of the system-level dependencies present in application builds on previous technology.

Occasionally, you'll have to take additional actions to configure the system for an application. This is needed when the application requires system-level environment changes. This can include actions such as creating a performance counter or an Event Log. In most cases you can perform these manually, but if you have some really slick developers, they might have embedded the configuration actions into the application's assemblies. In this case, meet installutil.exe, located in %SystemRoot%\Microsoft.NET\Framework\<version>\. This command-line utility can easily install and uninstall assemblies. You can invoke the utility on multiple assemblies, which causes it to operate in a transactional manner, meaning that if one part of the installation fails, the entire installation will be "rolled back." The following example shows the commands for the installation and uninstallation of two assemblies:

installutil application.exe application2.exe installutil /uninstall application.exe application2.exe

9.7.2. No-Touch Deployment

No-touch deployment is an effort to bring the simplicity of deploying a web application to thick client applications. This has been achieved by mimicking the web application deployment model.

In this model the only deployment is done to the server. The application assemblies sit within web server directories just as an HTML document would. When a user requests an executable assembly, either from a hyperlink or through manual entry, Internet Explorer retrieves and examines the assembly. The assembly is launched if it's found to be a valid .NET assembly. The CLR is aware of the originating URL and requests dependent assemblies and configuration files from the web server as needed.

Figure 9-4 demonstrates the deployment of a simple application.

Figure 9-4. Deploying the assembly

Once deployed, you can run the application assembly simply by keying the URL into Internet Explorer. You also can accomplish this from the Run menu or by creating a shortcut. Figure 9-5 shows the simple Hello application being run from Internet Explorer.

Figure 9-5. Running the assembly from the URL

The assembly is requested through Internet Explorer. After an initial examination, the control is passed to the .NET runtime. Example 9-4 is a fragment of the HTTP log file listing the requests the .NET runtime made to run and configure the assembly. As you can see, the process of interrogating the environment can be somewhat intense, especially with more complex applications that might require more assemblies. However, you can save a wealth of CPU cycles on the server by offloading the application processing onto the client machine, as opposed to a pure ASP.NET web application.

Example 9-4. Log file of activity used to run assembly

#Software: Microsoft Internet Information Services 5.1 #Version: 1.0 #Date: 2003-11-30 00:51:20 #Fields: time c-ip cs-method cs-uri-stem sc-status  00:51:20 127.0.0.1 GET /Hello.exe 304 00:51:20 127.0.0.1 GET /Hello.exe.config 404 00:51:21 127.0.0.1 GET /Hello.exe.config 404 00:51:21 127.0.0.1 GET /Hello.DLL 404 00:51:21 127.0.0.1 GET /Hello/Hello.DLL 404 00:51:21 127.0.0.1 GET /bin/Hello.DLL 403 00:51:21 127.0.0.1 GET /bin/Hello/Hello.DLL 403 00:51:21 127.0.0.1 GET /Hello.EXE 304

9.7.3. Windows Installer

The Windows Installer is provided for scenarios that do not lend themselves to one of the other deployment methods. These include times when complex tasks need to occur with the install or when deploying to users that would rather run a simple install package. Windows installer packages are simple .EXE or .MSI files that you can run from the Windows shell.