Understanding Configuration Files

for RuBoard

Most software applications need to maintain bits of information about how the software is supposed to run. Web applications are no different.

In ASP.old, you had a limited number of ways to manage application configuration data. You could

• Embed configuration data in the registry and hope that the person who deploys your application can insert the necessary registry settings properly.

• Use script files such as global.asa or constants located in your own script files.

• Use custom text files that could be read and written to as needed.

All three of these techniques have significant drawbacks. Registry-based configuration is difficult to manage. Changing a script file often requires a programmer, and errors inserted into script files can sabotage an entire application. Custom text files alleviate this problem, but in many cases using an external file means that a reference to that file must be explicitly included in every script file that accesses it.

The designers of ASP.NET recognized that application configuration was never as straightforward as it could have been. In .NET, Web applications have a number of new configuration options and features (which we'll discuss in this chapter and elsewhere in this book). But more importantly, the manner in which you configure your Web application is now totally standard and fairly simple to manage. In ASP.NET, applications are configured with just two XML files ”Machine.Config and Web.Config. You can easily make changes to and redistribute these to enforce settings in your applications, as you'll see in the next section.

for RuBoard