Section 19.2. Local Deployment

19.2. Local Deployment

All that is strictly necessary to deploy most ASP.NET applicationsto deploy most .NET applicationsis to copy the new files to the proper directories on the proper machine, overwriting any previous versions of files if they exist. This is referred to as XCOPY deployment .

XCOPY deployment is so simple as to cause experienced developers to ask, "Is that all there is to it?" It provides all the deployment benefits of .NET except for the ability to deploy assemblies globally (i.e., to use application code modules for multiple applications) and to pre-compile the application. To implement globally available code modules, you will use global deployment , described later in this section. Pre-compilation scenarios of local deployment will be covered shortly.

XCOPY is a command-prompt command that originated in the DOS days and has been enhanced for use in modern networks. It is used to copy files and directories from one location to another. The basic syntax is:

 XCOPY source destination switches 

Both source and destination can be either filenames or directories. There is full support for wildcards. There are a multitude of switches available that control such things as resetting (or not) the archive bit, copying (or not) any empty subdirectories, controlling the screen display during copying, and copying (or not) security information about the files. For a full list of the switches available, go to a command prompt and enter:

 XCOPY /? 

All command-prompt commands (known colloquially as DOS commands though DOS is no more) are case-insensitive, unless otherwise noted.

You can, of course, copy the files in any manner you wish, including dragging and dropping in Windows Explorer or FTP over the Internet. It is called XCOPY deployment to convey the essential fact that all that is required for deployment is to copy the application virtual root and all its subdirectories.

The CLR automatically handles any changes to application files seamlessly and invisibly to the user . If the global.asax or web.config file changes, the application will be automatically restarted. If a page, web service, or custom or user control file changes, the next request to come in to the application will get the new version. If an assembly file changes, the CLR will handle the transition from old version to the new one for any pending requests . It doesn't get much easier than this.

Since all the files necessary to the application are contained within the application virtual root and its child directories, this implies that if two different applications on a server use a dll of the same name , they will be two independent copies of the file. They may be identical copies, but they don't have to be. It is possible to have two or more different versions of a dll on the same machine, each in its own application directory structure, with no conflict between applications. This relegates DLL Hell to something that old programmers will tell war stories about, like 64KB boundaries or running out of conventional memory in DOS.

Within the category of local deployment, several scenarios are available, as discussed in the next several sections. You can use .NET's full compilation of all content and code at runtime, you can compile the assemblies manually, you can completely pre-compile all the content and code, or just the code.

19.2.1. Full Runtime Compilation

Compiling all the content and code at runtime is the easiest and most convenient way to compile applications, since no work is required on the part of the developer other than to place any source code files requiring compilation in the App_Code directory under the application root. You have seen this approach used in building the web service proxy in Chapter 16.

This is the preferred way for VS2005 to operate . Right-clicking on a web app root directory in the Solution Explorer, there is a menu item for adding a folder. One of the choices is App_Code . Further, if you attempt to add a class file to a web application, you will be prompted to place it in the App_Code directory. You can decline and place it wherever you wish, but VS2005 tries to guide you to this approach.

If a source file is located outside the App_Code directory, then you will have to take active steps to compile the file and make the resulting assembly available to the app, using one of other three scenarios described here.

Full runtime compilation is independent of VS2005. Even if you create all the application files in Notepad, as long as the source files are in the App_Code directory under the application virtual root, they will be compiled by the CLR at runtime.

The big advantage to this technique is convenience and automatic synchronicity between content and code files. If you have to remember to do a complete recompile before deploying, it is possible for deployment errors to slip in.

There are two downsides to this compilation scenario: performance and security. A page or class is not compiled until it is first called.

The lag time on first call is noticeable, sometimes significant, but it only occurs the first time a page or class is called. There is no performance penalty after the first hit because the compiled assemblies are cached on the server and immediately available on subsequent calls.

The other issue is security. Deploying an app in this manner means the source code and content files are all present on the server as plain text files. Though ASP.NET and IIS are configured to prohibit access to these files, there is always the possibility that a hacker might penetrate security and gain access to the server's file system (or that a disgruntled or unscrupulous employee will steal or corrupt the code). In a hosting scenario, where your web site is hosted by a commercial hosting service, your source files will be available for any prying eyes with sufficient access rights.

19.2.2. Manual Compilation of Assemblies

As mentioned above, another reserved subdirectory of the application root is bin , which is part of the application assembly cache. Any compiled assemblies located in this folder will automatically be made available to the application. The key here is that you must manually compile the assemblies, using the command-line compiler, as described shortly.

This was the normal method of operation in ASP.NET Version 1.x, and is still supported. Aside from the inconvenience of manual compilation (which can be automated with batch files or a make system), it provides good performance and security (at least for the compiled source code files; the content files are still present in plain text). In some cases, such as when using custom configuration sections (covered in the previous chapter), having a manually compiled assembly is a requirement.

To compile a class file manually, open a command prompt by going to Start All Programs Microsoft Visual Studio 2005 Visual Studio Tools Visual Studio 2005 Command Prompt, to open a command prompt window what used to be known as a DOS prompt, for you old-timers.

Change the current directory of the command window to be the directory containing the source file. The command to do this is something like this:

 cd \websites\MyWebApp 

The generic syntax for the C# compiler is:

 csc [parameters] inputFile.ext 

For example, the following command (the command is wrapped here for readability; in reality, it would be on a single line) will output an assembly file called MyClasses.dll in the bin directory, using \websites\MyWebApp\MyClasses.cs as the input source code file:

 csc /out:bin\MyClasses.dll /t:library /r:system.dll,system.web.dll,        MyClasses.cs 

The command-line compiler has a large number of parameters available to it, three of which are used here. To see the complete list of parameters available, enter the following command at the command prompt:

 csc /? 

Table 19-2 lists the parameters used in the preceding command lines.

Table 19-2. Compiler parameters

Parameter	Short form	Description
/out:<filename>		Output filename. If not specified, then the output filename will be derived from the first source file.
/target:library	/t: library	Build a library file. Alternative values for target are exe , winexe , and module .
/reference:<file list>	/r:	Reference the specified assembly files. If more than one file, either include multiple reference parameters or separate filenames with commas within a single reference parameter. Do not include any spaces between filenames.

19.2.3. Full Pre-Compilation

If you do not want to subject the web site users to any compilation delay the first time a page or class is hit, you can pre-compile the entire application, including the content files. This allows you to deploy only compiled assembly files, which will have no delay the first time they are called and will keep them resistant to prying eyes. There will be no plain text source code files deployed.

For greater security, you can obfuscate the compiled assemblies to make them more difficult to decompile and reverse-engineer . An obfuscator, called the Dotfuscator Community Edition , is included with VS2005 under the Tools menu.

This full pre-compile can be accomplished from the command line using the aspnet_compiler.exe utility. However, the easier way to do it is by using the Build Publish command in VS2005, which integrates in the MSBuild build engine .

After clicking that command, you will get the dialog box shown in Figure 19-3. The default target location, if you're using a File System location, will be a folder called PrecompiledWeb under the VS2005 project file location. You can enter an FTP or HTTP URL to deploy to a remote server.

For a full pre-compile with maximum security, i.e., including the content files, uncheck the checkbox labeled "Allow this precompiled site to be updateable."

To use strong names with a key file, as described previously, check the checkbox labeled "Ename strong naming on precompiled assemblies" ("Ename" must be a typo in the Beta 2 checkbox label, it should be "Enable"), and enter or browse to the key file location. There is a checkbox to implement Delay signing as described above. The Key container controls allow you to use RSA Key Containers (a topic beyond the scope of this book) rather than a key file.

The result of this pre-compile will be a directory structure, suitable for XCOPY deployment to a production server, in the location specified in the dialog box. In that directory structure will be a bin directory containing all the compiled dll s, plus compiled

Figure 19-3. Publish Web Site dialog box

versions of the content files. The content files will not be present, although stub files named identically as the original content files will be there. These stub files provide a target for browser requests but are used only to redirect the request to the compiled version in the bin directory.

If you want to make any changes to any file, you must do so in VS2005 and recompile.

19.2.4. Pre-Compilation of Code Only

Often times, the full re-compile is what you need, but you want the flexibility to make minor modifications to the content files after they have been deployed, without the hassle of a full recompile and redeploy. In this case, check the checkbox in Figure 19-3 labeled "Allow this precompiled site to be updateable."

The result will be the same as with a full pre-compile, except that the content files will be the original version rather than stub versions. These content files can be edited after deployment and those changes will take effect with any subsequent requests, transparently to any users of the site.