Manually Deploying an ASP.NET Application | Visual C#. NET 2003 Unleashed

It seems almost like overkill to dedicate a chapter to ASP.NET deployment because it is such a breath of fresh air compared to previous deployment models for COM and legacy ASP. Before the chapter gets into building setup projects using Visual Studio .NET, it covers how to deploy your web application manually. Knowing where the files go, how you can get them there, and how to configure the target environment will make it easier for you to build setup applications later. The next section will show you how to deploy your ASP.NET applications manually using Visual Studio or using the command-line tool, XCopy. Finally, you'll see some of the problems with XCopy deployment and when you can and cannot make use of it.

Deploying via "Copy Project"

Within Visual Studio .NET is an option under the Project menu called Copy Project. This option is a double-edged sword, unfortunately. On one hand, it gives you nearly one-click deployment of your application (typically residing on your local PC) to another server somewhere in your network. On the other hand, the method used to publish that application will almost never be sufficient to get your production applications out the door. For copying simple applications to other servers that are unsecured for development use, it is an ideal tool. Figure 26.1 shows the dialog box that opens when you choose Project, Copy Project.

Figure 26.1. The Copy Project dialog box.

There are two publish methods: FrontPage and file share. If your production machine is even remotely secured against attack, you know that neither of these publishing methods will work, regardless of how much administrative access your account has on the remote server. FrontPage extensions are typically disabled when IIS security is locked down for a production machine. File sharing is almost always disabled on production web servers.

If you are lucky enough to be able to deploy to a machine this way, it is a handy way of duplicating web sites. There is even an option to exclude source code files from the deployment so that only those files necessary to run the application are copied.

The real issue with Copy Project is that you can't control how your dependencies are deployed or whether they are deployed at all. Referenced assemblies will show up in the bin directory on the website, but if you have any other complex dependencies, such as COM objects or requirements for the global assembly cache, the Copy Project tool won't help you deploy your application.

XCopy Deployment

XCopy deployment doesn't actually refer to deployment that you must do using the XCopy command-line utility. It actually refers to dependency-free deployment that can be accomplished simply by copying files from one location to another location. This means that you can XCopy deploy using FTP, drag-and-drop file copy, file sharing, or any other means of transferring files to the destination server.

To XCopy a web application from one location to another is a very simple command-line task. To do so, open any command prompt (you don't need the Visual Studio .NET command prompt) and type the following command:

 xcopy c:\inetpub\wwwroot\devapplication z:\prodapplication

That's all you need to do. Specify the source directory and the destination directory and XCopy will copy the files and preserve the tree structure.

When to XCopy

A few guidelines and pieces of advice can be given with regard to when you should XCopy your projects to deploy them:

If it is physically possible to XCopy deploy your project, you should XCopy deploy your project.

Determining whether or not your application qualifies for XCopy deployment is something else entirely. Also, keep in mind that when this chapter discusses deploying, it is discussing deployment of the application as a functional unit. If some pieces of the application don't work after XCopy deployment, but some do, the application doesn't support XCopy deployment.

The following is a quick list of some of the most common things that can cause your application to be unable to take advantage of XCopy deployment:

Your application makes use of COM objects.
Your application makes use of components assumed to be in the global assembly cache.
Your application is a Windows service.
Your application is a COM+/Enterprise Services package that cannot be auto-registered.
Your application makes use of event logs, performance counters, message queues, and other system resources that must be preconfigured before your application can run properly.

If your application is built to run without any dependencies on things such as COM objects, preconfigured OS services, and so on, you can probably XCopy deploy your application.

If your application requires any kind of configuration outside the setup of the web.config file, has COM/COM+ dependencies, or depends on things such as the GAC or even operating system resources such as event logs and the like, it will be unable to take advantage of XCopy deployment and you will have to create a setup application for deployment.