Am I the only one that has issues with the way web.config is implemented in ASP.NET web apps and web services? The idea of a central, extensible XML config file that automatically detects changes is a great one. But the fact that ASP.NET restarts the application any time the file changes - isn't that a little heavy handed? I realize that it tries to handle the restart as gracefully as possible, spinning up a new instance of the application while allowing the old one to die out after it processes any pending requests. But restarting the application has a couple of nasty effects - namely, the application loses its cache and in-memory session state. In my case, the web service that I work on stores a bunch of data in cache that can be expensive to fetch. Dumping the cache can have a significant performance impact as the server rebuilds it.
Now, I'm sure that there are times when restarting the application is absolutely required. But why should the application have to restart just to add a trace switch, install a trace listener, or tweak some minor application setting? The only solution is to create a separate, custom application configuration file and hooking up the file monitoring by hand.
I can imagine a couple of possible solutions. ASP.NET could support a separate config file that holds configuration settings that don't require a restart. Or, even better, it could know which web.config settings require a restart and act accordingly (flagged by an XML attribute, for example). I haven't looked at Whidbey enough yet to know if they've addressed this issue. I hope so.