Chapter 19. Deployment

Perhaps the single greatest improvement that .NET has made over previous generations of development environments, especially compared to classic ASP, is in the area of deployment, for the following reasons:

• Source code files need only be located in a specific directory ( App_Code ) to be automatically compiled and available.

• Precompiled dll files only have to be located in a specific directory ( bin ) to be visible to an application.

• You don't need to register objects, either in the Registry or elsewhere, for an application to use the contents of a dll . Installation does not require any registering of components with regsrvr32 or any other utility, though globally available components may be placed in the Global Assembly Cache.

• Web sites can be deployed with installer files ( .msi ) or using XCOPY.

• Web sites can be updated without stopping the web server or the application.

• There are no versioning issues with conflicting dll files.

All of this will be described in this chapter. In the meantime, shout it from the rooftops: No more DLL hell!

ASP.NET derives all this deployment bliss by virtue of being part of the .NET Framework. These deployment features are common to all applications developed under the .NET Framework.

Understand that with all the different deployment scenarios, the fundamental requirement is that you are deploying the web application to a web server (or to servers in the case of a web farm,) which is running IIS, as described in the previous chapter. Even if you developed the app in VS2005 using a File System location on a machine without IIS installed, you must deploy to a virtual directory on a server running IIS if you want your site to be visible to other users.

There are two broad categories of deployment: local and global. With local deployment , the entire application is self-contained within a virtual directory. All of the content and assemblies (described shortly) that make up the application are contained within the virtual directory and are available to this single application. With global deployment , assemblies are made available to every application running on the server.

Within the category of local deployment, there are several scenarios available:

Automatic runtime compilation of all content and code

This provides the most convenience and flexibility but provides the least security and slowest performance on first load. It is the default model used by VS2005.

Manual pre-compilation of assemblies

Assemblies are compiled and then placed in the application assembly cache, described below. This was the method used with ASP.NET Version 1.x and is still fully supported. It provides better performance the first time the assembly is called than automatic runtime compilation.

Full pre-compilation of all content and code

This provides the best performance and security at the expense of convenience and flexibility.

Pre-compilation of all code only

The content files are not pre-compiled, and remain available for update after deployment. This provides nearly the performance of full pre-compilation, but retains the ability to modify the content files after deployment, without a full redeploy.

Finally, two different techniques are available for deployment: XCOPY and Microsoft Installer . Your choice of which method to use will be driven by the requirements of your situation. All of this will be described, with pros and cons of each, later in this chapter. First, we will digress a bit to discuss assemblies, which are fundamental to the whole issue of deployment.