The trouble with web.config

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.

 

 




        

                

            



11 Comments


  • 



    

    


    
The Configuration application block allows you to have an external XML file from the web.config and not require a restart when its modified. 
    
 
    
 
    
 
    
Its available on MSDN where all the rest of the application blocks are. 
    


    


    

    

    



    • 

  • 



    

    


    
I believe this will also mostly fixed in 2.0 as well.  That is, there will be a number of sections where a change will not reset the application. 
    


    


    

    

    



    • 

  • 



    

    


    
This is fixed in ASP.NET 2.0. 
    
 
    
 
    
 
    
But in the short-run, why not just store your own items in a custom config file and use your own CacheDependency to monitor changes?  
    
 
    
 
    
 
    
On another note, how often do you really need to make changes? I always thought of the config section as a place to store machine/application related settings that really did not need change all that often. 
    
 
    
 
    
 
    
-Scott 
    


    


    

    

    



    • 

  • 



    

    


    
Paul - I've tended to avoid the app blocks for non-internal applications.  I've had the sense (perhaps unfounded) that there's a weaker commitment to ongoing maintenance and backward compatibility. Maybe that's just NIH syndrome silliness. :) 
    
 
    
 
    
 
    
Scott - good news that it's fixed in 2.0. One of these days I hope to have time to really dig into Whidbey. Too busy right now, unfortunately.  
    
 
    
 
    
 
    
Tracing is a good example of where web.config is changed on a running system. Debugging a production server by setting up trace switches to enable diagnostic logging is quite common. Dumping the cache to enable this is not ideal. BTW, that's also an example of where a custom config file isn't useful - the framework always uses web.config to control traceswitch behavior. 
    
 
    
 
    
 
    
I like the idea of using a faux CacheDependency with a callback, though. That's a bit easier than setting up a FileSystemWatcher. 
    


    


    

    

    



    • 

  • 



    

    


    
Not an issue because the use of Session variables is, overall, a bad architectual choice. 
    
 
    
 
    
 
    
Wally 
    


    


    

    

    



    • 

  • 



    

    


    
have problem with web.config 
    
 
    
 
    
 
    
can somebody help me pleaseeeeeeeeeeeeeee?? 
    
 
    
 
    
 
    
aljosa 
    
 
    
 
    
 
    
www.runtothe101.com/mail/ 
    
 
    
 
    
 
    


    


    

    

    



    • 

  • 



    

    


    
tell me how to fix web.conf under taxslayer.com 
    


    


    

    

    



    • 

  • 



    

    


    
You just have to turn off cookieless sessions in the web.config. Beware that this may cause you other problems that you don't want to encounter either. You only need to have cookieless sessions enabled if you don't want to require your users to have cookies enabled on their browsers. 
    


    


    

    

    



    • 

  • 



    

    


    
So where it to find?,  
    


    


    

    

    



    • 

  • 



    

    


    
Where it is possible to buy the,  
    


    


    

    

    



    • 

  • 



    

    


    
Your Site Is Great,  
    


    


    

    

    



    • 









    

        
Comments have been disabled for this content.