Application-wide Settings

When Microsoft was designing the requirements for the .NET environment, the engineers had the opportunity to standardise even further. They wanted to introduce a system that combined the best features of the Registry and INI files, without some of the limitations. In addition to being able to support separate application files and user files they needed to support any data storage format (e.g. binary, hierarchical, flat). Importantly, they also needed to protect application settings and data from other .NET applications (helping to avoid problems with registry corruption at the same time). Furthermore from a security stand point a restricted area was needed that would fit in with the .NET Framework’s model of Code Access Security. Isolated Storage is Microsoft’s first draft at meeting all of these needs.

For Visual Studio .NET developers, the .config file largely replacing the .INI file and Registry in the .NET environment at least in so much as it provides application wide settings. The .config file for an application will live in the same directory as the .exe file and will share the same name. At design time the file is called App.Config, as you build the solution the run time version is renamed with the same name as the .exe file. If your application is called MyApp.exe then your App.Config file will be renamed as MyApp.exe.config.

Your App.Config file has an XML format and so is flexible and hierarchical. You’d store the kind of information here that you might store inside HKEY_LOCAL_MACHINE in the registry in as much as any user accessing that application in that directory shares the same configuration file. Developers often think that this is a good storage area for per-user information, but it’s not designed for that. And of course it’s read only storage and not really designed to store information that will change whilst your application is running (like state information).

The .NET Framework provides classes for working directly with Application Settings and in particular there is an AppSettingsReader class (but note the absence of a class to write settings). You can use this class to read from the appSettings section of the config file, containing name/value pairs.