Chapter 3. Configuration


Ask any three traditional ASP developers what they like least about building applications in ASP and you will always get three different answers. Of course, it will always be the same three different answers. One of the developers will claim that debugging is absolutely the worst part of ASP development. A second developer will state emphatically that deployment is by far the worst part of ASP development. And the third developer will claim that no one thing is the worst, but the combination of debugging and deployment is the worst part of ASP development.

When the ASP.NET team set out to design the next version of ASP, many of their top priorities were to remedy the most glaring deficiencies of ASP. The debugging of ASP.NET applications is covered in Chapter 5, but fear not, it does improve. As for deployment improvements, Chapter 1 discussed the solution to one of the most frustrating aspects of deployment with ASP applications: the fact that you had to stop IIS to replace any DLLs (usually COM libraries) that were used by your application. ASP.NET remedies this by introducing the shadow copy mechanism for all referenced assemblies placed in the /bin directory of the application, so neither the ASP.NET worker process nor IIS has to be stopped to replace components associated with an application. This feature is often categorized as part of the xcopy deployment feature of ASP.NET ”the fact that for most ASP.NET applications, installing or upgrading an application is as simple as using xcopy (or a similar copy utility) to place new files on the server.

The xcopy deployment of ASP.NET would not be complete, however, if it were not also possible to configure ASP.NET applications by copying a file. For a traditional ASP application, all the configuration settings are stored in the IIS metabase, which is a binary repository managed through a set of COM APIs. Installing an ASP application on a server means that the metabase must be updated to reflect the configuration settings of the application, which means that a person with adequate privileges must run a script on the server. Similarly, updating an ASP application requires running a script on the server to update the metabase. In addition, it is not trivial to discover what the current settings for an application are, because the metabase is stored in the registry in a proprietary binary format, unreadable by any means except the COM APIs.

In keeping with ASP.NET's goal of supporting xcopy deployment, the configuration for an ASP.NET application is specified through an XML file, named web.config , placed at the top of the virtual root for the application. In fact, this file uses the same configuration layout that all .NET applications use, where the configuration file is named after the application, such as myapp.exe.config . The web.config file is just a specially named file whose settings apply to the pages and classes within that directory for an ASP.NET application, since ASP.NET applications are housed in the larger aspnet_wp.exe containing process. Because the web.config XML file is stored as plain text, it is easy to view with any text editor or to manipulate programmatically with any XML API. It is also easy to deploy, simply by copying a new version of the text file to the server. When the next request is serviced, ASP.NET will notice that the timestamp on the web.config file has changed and will immediately apply the new settings to that request and all subsequent requests .



Essential ASP.NET With Examples in C#
Essential ASP.NET With Examples in C#
ISBN: 0201760401
EAN: 2147483647
Year: 2003
Pages: 94
Authors: Fritz Onion

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net