Config files are all over the place with .NET: WCF, Log4Net, everything comes with an XML config file even if you didn't ask for one.
But when you think about it, why do you need config files really? Usually that's because you want to change some behaviour without having to rebuild the code. Ok. But what is so bad about rebuilding the code?
In the Enterprise world if you intend to make a change to a config file in production, you’re not going to just change the file on the production server (unless you're Jack Bauer and you have a death wish after your wife was murdered). You're going to make the change in the staging environment first then test it. If the system didn’t collapse then you'll raise a change request, have it approved by change management and eventually release it in prod. Well now compare that with rebuilding the code... mmm? Same amount of hassle, you'd have to go through the same steps anyway.
I find the main benefit of config files in Enterprise server apps is to ease the pain involved in moving from development to staging and from staging to production. This is where the config files are really useful because you have one code base for many environments. Connection strings, timeout values, environment identifiers, log file paths, simulated dates, weekend definitions, job start times, retry windows, SMTP servers, Tibco RV transport settings... They all depend on where you run the code from.
