Chapter 5. Configuration and Deployment

for RuBoard

IN THIS CHAPTER

• Understanding Configuration Files

• Global and Local Configuration Files

• Structure of Configuration Files

• Accessing Configuration Files Programmatically

• Editing Web Configuration Files in Visual Studio .NET

• Initializing Web Applications Using Global.asax

• Using XCOPY for Deployment

• Managing the Global Assembly Cache

Deploying applications under ASP.old was fairly simple ”most of the time. You designated a folder as scriptable under Internet Services Manager, copied your script files into that folder, and requested the ASP pages through a Web browser. If something went wrong, you got a 404 Not Found error, which sent you back either to Windows Explorer to locate the missing file or into Internet Services Manager to change an incorrect setting. On paper, it all looked pretty simple.

Under this old model, the trouble came when your ASP application depended on external resources to run. For example, if your application needed to periodically retrieve or store information from the system registry, or (even worse ) if your application depended on one or more COM components , you found yourself in a situation in which you could not easily and automatically replicate your Web application on another server. This meant that for all but the most trivial ASP.old applications, it was a pain to move your application from a development server to a production server. The problems involved in replicating external dependencies got much worse in situations in which you were required to deploy your application to a series of identical servers (such as a Web farm).

ASP.NET promises to make the process of deploying your Web applications much easier, no matter what kind of application architecture or server you're working with. It does this by doing away with certain dependencies (such as the system registry and the IIS metabase) and minimizing the impact of others ”most notably, it got rid of the requirement that a precompiled component be registered, as is the case with COM components.

In addition to making deployment simpler, ASP.NET makes the process of configuration much easier, as well. In the past, IIS and ASP configuration files were stored in the registry and were accessible only through the registry editor or (more com-monly) Internet Services Manager. But in many cases, important configuration information would get lost in the GUI of the management console, which changed from one version of Windows to the next .

Storing IIS and ASP configuration data in the registry also meant that configuration itself became a new kind of deployment problem, too, because you couldn't easily provide registry settings for your Web applications to suit multiple machines or multiple customers.

In ASP.NET, many application-level settings are available through XML configuration files that you can view and change using any text editor. This has advantages and disadvantages, as we'll discuss later in this chapter. But by and large, the capability to easily distribute your configuration file along with the application itself is a huge boon to application developers.

for RuBoard