To promote code reuse and application interoperability, all your applications—Web, Windows, Web services, Windows services—should use application configuration files as a common method for managing application-centric information.
System configuration vs. application configuration
When .NET’s Common Language Runtime (CLR) executes your application, it uses a series of XML configuration files to set the basic attributes of the execution environment. For example, if you’re executing a Web application, the CLR will interrogate the Web.config file to determine the authentication mode (Forms, Windows, or None), authorized users, session state settings (InProc, StateServer, or SQL), and other key settings.
Likewise, the Machine.config system file provides ASP.NET configuration settings for the entire Web server and forms the base settings for Web.config files used within an ASP.NET application. Security.config and EnterpriseSec.config define systemwide security and code permission settings for Windows applications.
This default behavior is fine, if all your applications need to run in the same execution environment. However, if you need special configuration settings on an application-by-application basis, you can store this information in a special file recognized by the CLR upon the invocation of your specific application.
Storing application configuration information
.NET application-specific information should be saved in a .config file in the same directory as the application’s executable. The application’s full filename should serve as the configuration file’s surname, in the form: applicationname.exe.config
You can programmatically retrieve application settings from the XML .config file by using the SYSTEM.CONFIGURATION namespace. Here’s a sample application configuration file that you could use to store connection string information for your application:
<add key="ConnectionString" value="Provider=SQLOLEDB.1;..."/>
</configuration> Storing application configuration information in an external file lets you update certain application attributes without having to recompile the application. For example, suppose you’ve developed an application to access a database on a SQL Server and you chose to hard-code the connection information in the application. Now you want to move the database to a different server. Because the connection information is hard-coded in the application, you’ll have to modify, recompile, and redeploy the application to make this change. But if you’re using a .config file, the change is as easy as modifying the ConnectionString key in the .config file.
Playing by the rules
To use .config files effectively, you should create standard key names and value definitions for use by all your application developers. This will allow developers working on the same projects to use common project settings. Such standards will also be useful when you deploy the application and turn it over to production. If you standardize on .config settings, your operations group will know where to go first if it needs to troubleshoot problems relating to common application configuration settings.