Application Deployment
Application Deployment
Installing a .NET application in general, and an ASP.NET application in particular, is a matter of performing an XCopy that is, a recursive copy of all the files to the target folder on the target machine. Aside from some inevitable emphasis and promotion, the XCopy deployment expression, which is often used to describe setup procedures in .NET, communicates the gist of .NET deployment: you don't need to do much more than copy files. In particular, there's no need to play with the registry, no components to set up, and no local files to create. Or, at least, nothing of the kind is needed just because the .NET Framework mandates it.
XCopy Deployment
The deployment of a Web application is a task that can be accomplished in various ways depending on the context. As far as copy is concerned, you can use any of the following: FTP transfer, any server management tools providing forms of smart replication on a remote site, or an MSI installer application. In Visual Studio .NET 2005, you can even use the Copy Web Site function that we discussed earlier in this chapter.
Each option has pros and cons, and the best fit can only be found once you know exactly the runtime host scenario and the purpose of the application is clearly delineated. Be aware that if you're going to deploy the application on an ISP host, you might be forced to play by the rules (read, "use the tools") that your host has set. If you're going to deliver a front end for an existing system to a variety of servers, you might perhaps find it easier to create a setup project. On the other hand, FTP is great for general maintenance and for applying quick fixes. Ad hoc tools, on the other hand, could give you automatic syncup features. Guess what? Choosing the right technique is strictly application-specific and is ultimately left to you.
Copying Files
FTP gives you a lot of freedom, and it lets you modify and replace individual files. It doesn't represent a solution that is automatic, however: whatever you need to do must be accomplished manually. Assuming that you have gained full access to the remote site, using FTP is not much different than using Windows Explorer in the local network. I believe that with the Copy Web Site functionality of Visual Studio .NET 2005 in place, the need for raw FTP access is going to lessen. If nothing else, the new Copy Web Site function operates as an integrated FTP-like tool to access remote locations.
The new copy function also provides synchronization capabilities too. It is not like the set of features that a specifically designed server management tool would supply, but it can certainly work well through a number of realistic situations. At the end of the day, a site replication tool doesn't do much more than merely transfer files from end to end. Its plusses are the user interface, and the intelligence, built around and atop this basic capability. So a replication tool maintains a database of files with timestamps, attributes, properties and can sync up versions of the site in a rather automated way, minimizing the work on your end.
Building a Setup Project
Another common scenario involves using an out-of-the-box installer file. Deploying a Web application this way is a two-step operation. First, create and configure the virtual directory; next, copy the needed files. Visual Studio .NET makes creating a Web setup application a snap. You just create a new type of project a Web Setup Project select the files to copy, and build the project. Figure 2-25 shows the user interface of the setup project.
Figure 2-25: Creating a Web setup project.
The Web Application Folder node represents the virtual directory of the new application on the target machine. The Properties box lets you configure the settings of the new virtual directory. For example, the AllowDirectoryBrowsing property lets you assign browsing permission to the IIS virtual folder you will create. You can also control the virtual directory name, application execute permissions, level of isolation, and default page. The Bin subfolder is automatically created, but you can ask the setup to create and populate as many subfolders as you need.
When you build the project, you obtain a Windows Installer .msi file that constitutes the setup to ship to your clients. The default installer supports repairing and uninstalling the application. The setup you obtain in this way which is the simplest you can get does not contain the .NET Framework, which must be installed on the target machine or explicitly included in the setup project itself.
What Else Do You Need to Do?
One of the coolest features of .NET assemblies is that they are self-describing components. An application that wants to know about the internal characteristics of an assembly has only to ask! The .NET reflection of an API is the programming interface by which a client can interrogate an assembly. This fact eliminates the need of using the registry (or any other sort of centralized repository) to track paths and attributes of binary components. Another pleasant effect of the assembly's structure is that side-by-side execution is now a snap, and ASP.NET applications take advantage of it on a regular basis. In practice, whenever you update a page, two versions of the "same" assembly live side by side for awhile without interference and conflict.
So the XCopy deployment model rocks. Is there something more you need to do to finalize the deployment of your application? Sure there is. Let's detail some additional tasks.
If you use read/write files (XML files, configuration files, Access databases), you need to grant proper writing permission to the application. Likewise, if your application or control generates temporary files, you need to make accommodations for a proper folder with proper writing permissions. These tasks must be accomplished in one way or another before the application goes live. Note that in an ISP scenario you are normally given an isolated disk subtree with full write permissions granted to the ASP.NET account. You must design your applications to be flexible enough to support a configurable path for all their temporary files.
| Note | We're not saying anything specific about database configuration here. We're simply assuming that all required databases are in place, properly working, and entirely configured. If this is not the case, you might want to add this task to the list too. The same holds true for any remote application and network services you might need, including Web services and COM+components. |
Configuring the Runtime Environment
Another aspect to consider is runtime configuration. When you develop the ASP.NET code, you test it on a machine with its own machine.config file. When you deploy the application on a production box, you might not be able to restore the same settings. One possible reason is that the administrator does not want you to modify the current settings because they proved to be great for other applications. (This is especially true in an ISP host scenario.)
You can work around the issue by simply replicating any needed machine.config settings to the application's web.config. However, if you are deploying your code to a service provider, you might find that many machine.config settings have been locked down and cannot be overridden. In this case, you should ask (or more exactly, beg) the administrator to let you tweak the server's configuration in a way that suits you without hurting other applications. This normally entails creating an application-specific <location> section in the server's machine.config file.
Deploying an ASP.NET application in a Web-farm scenario poses a few extra configuration issues you must be aware of. All machine.config files in the Web farm must be synchronized to the value of a few attributes. You can achieve this in two ways, the simplest of which is packing all attribute values in the application's web.config. This approach greatly simplifies the deployment because you only have to run the setup on all machines and no other changes are needed. If any of the required sections are locked down (once more, this is likely to happen in an ISP scenario), you find yourself in the situation described previously, that of begging the administrator to create a new <location> section for you.
| Note | The <location> section can be used in both machine.config and web.config to limit Web settings to the specified application path. In a deployment scenario, the section assumes particular importance in the machine.config file and subsequently requires administrative privileges. The <location> section is normally used in a web.config file in case of a deployment with a main application and a bunch of subapplications. |
