IanG on Tap

I seem to write about this often enough in news groups and mailing lists that I thought I'd put it up here - that way I can just post a link next time...

.NET applications can have a configuration file associated with them. In web apps, the file is called web.config. For a normal Windows or console application, it is has the same name as the executable with .config tacked on the end. So if your app is called Foo.exe, you would put the configuration file in the same directory and call it Foo.exe.config. In Visual Studio .NET projects, the file will be called App.config - VS.NET copies it into your build output directory and changes the name appropriately.

.NET itself looks for certain settings inside this file. For example, the assembly resolver can be configured this way. It can also be used to store some application-specific settings in its <appSettings> element. Because of this, a frequently asked question emerges:

How do I write settings into the application configuration file at runtime?

The short answer is: "Don't do that."

The slightly more informative but still fairly succinct answer is: "You quite often can't, and even when you can you don't want to."

Here's the long answer.

Why the Config File Might Not Be Writable

The configuration file is stored in the same directory as the executable itself. It's pretty common for users not to have permission to write to this directory. Indeed that's just common sense and good practice - ensuring that the user doesn't have permission to write into directories where executables are stored prevents a lot of viruses, spyware, and other malware from wreaking havoc.

This is why the Program Files directory is configured not to allow normal users to write to it.

Unfortunately, not everyone runs as a normal user - lots of people run as administrators on their Windows machines. This is a shame as it means they are throwing away a lot of the protection Windows can offer them. Of course one of the reasons so many people run as administrators is because of crappy applications that attempt to write into their installation directories.

Don't make your application one of those crappy applications. Don't try and write into the directory where your application is installed, because if you do that, your program won't run properly unless the user is an administrator.

Of course there may be other reasons that the file isn't writable. If your application is deployed via HTTP, the configuration file will live on the web server, and you are unlikely to be able to modify it.

Why You Wouldn't Want to Write Into It Even If You Could

Let's suppose you've ignored the above, and have decided to write a crappy application that writes into the directory it runs from. (Welcome to Keith Brown's Hall of Shame by the way.) You still don't want to be writing user settings in there. (And there's no need to put application-wide settings there either.)

Lots of machines have multiple users. And not just terminal servers - all my home machines have multiple users because I'm not the only person who logs into them. They don't tend to have multiple simultaneous users, but that's not the point. I don't want someone else's configuration choices to affect my account.

For example, I have a separate login I use on my laptop for doing presentations. All of the fonts are configured to be extra large and legible. The resolution is set for a projector rather than the laptop's own screen. It would be hugely annoying if these things were configured on a per-machine basis, because I'd have to keep reconfiguring them, rather than simply being able to switch user accounts. (Actually ILDASM stores font settings in a machine-wide way, and it really bugs me.)

If you store user settings in the application configuration file, you will be storing one load of settings that apply to all users on the machine. Of course you could fix that by rolling your own mechanism to keep each user's settings isolated. But you'd be mad to build such a thing when there's already a perfectly good system for doing this built into Windows!

Where Should I Put This Information Then?

The user's profile directory is the appropriate place for user settings. Since there is a profile directory for each user, this keeps the settings separate. Moreover, if the profile is configured as a roaming profile, the user's settings will then follow them around the network as they log into various machines. And if they back up their Documents and Settings directory, your application's settings will be backed up as a part of that operation. What's not to like?

So how do you locate this directory? .NET makes that very easy, thanks to the System.Environment class:

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)

That will return a string, containing the path of the Application Data subdirectory of the user's profile. (If you want to store data that does not become part of the roaming profile, use LocalApplicationData instead.) You should create a subdirectory named after your company, and inside that a subdirectory named after your program. (If you look inside your profile's Application Data directory, you'll see that this is the structure applications usually use.) You may also choose to put a version-specific subdirectory underneath the application name directory.

(If your code might need to run with partial trust, look at the Isolated Storage APIs. These are a bit more cumbersome than just creating files in the right directory, and create some funny-looking paths. But they have the considerable advantage of working in partial trust scenarios.)

Note that even if you want to store application-wide settings, you still don't have to write into the application installation directory. Just do this:

Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)

That returns a path for machine-wide settings. Not all users will have write access to this by the way, so be careful.

So What Exactly Is The Configuration File For Then?

The configuration file is really only for settings configured at deployment time. It can be used to deal with versioning issues with .NET components. And it's often used for connections strings - it's useful to be able to deploy an application to connect to a test or staging server, but this is not something you'd normally change in production once the application is deployed.