Paul Hammant's Blog: App.config in C#
OK, keeping this short ... App.config is a terrible idea. It does not make testing easy. It is very un-IoC. It is tightly coupled. refer updates below
Update - 23rd Dec 2003
OK OK, so I am somewhere between wrong and ineloquent on this. The big issue is that an exe assembly only has one entry point. If we are building reusable components, an application exe should be provide the thinnest of entry points to a DLL. The component class in the DLL that the EXE straps, should have a PicoContainer-esque (my opinion) constructor that takes configuration. The only thing that the EXE should provide is command line parsing and app.config loading in order to feed the main component. My former understanding was that app.config was the only way to pass configuration. Mike Royle pointed out that application classes can take command line parameter to override those parameters specified in the app.config. Thus the DLL is reusable without app.config. Don't put much functionality in the exe, put most in the DLL - it aids unit testing apart from anything else.
Update - 31st Mar 2004
OK, so apparently if this is top entry in Google for "App.confg C#", I have a duty to push people on to more authoritative articles.
.Net Config for experts : Configuration Management Application Block for .NET
Constructor Dependency Injection
Also, it is important to note that I am not advocating going back to the good old days of the registry (it was obvious in 1995-ish that is was not a magnificent step forward from INI files).
I am selling the merits of componentization. That is putting as little of your application in the .exe as possible. and as much in .dll(s) as possible. Coupled to that, and despite the Configuration Management Application Block for .NET link above, I'm advocating putting as little config processing in components as possible (components being in dlls). I'm suggesting that components should be programmatically configurable by the class that instantiates them (see Constructor Dependency Injection above). You are going to find it a lot easier to unit test a component if all of its configuration is declared when the beast is instantiated. See this forum posting on NUnit and App.Config (I'm sure google will help find more).