The only "gotcha" about web.config is that changing it causes a restart of the application. You really don’t want global settings in web.config that change often and don’t require an application restart. If you are essentially adding settings to web.config that rarely or never change, that is fine. Volatile settings should be tossed in an XML file or database, depending on your application needs.

The application block is cool, but could be overkill for smaller applications. I tend to use separate XML files and my own serialization which I showed in a separate post. You can add the global settings to the cache with a dependency on the XML file to remove it from the cache when a change is detected. This is part of my web page inheritance model that I will toss up sometime this weekend I hope. It is pretty basic and gives you another option for your web applications.

Would you use this method for setting storage in an ASP.NET application over the web.config file? If so, why? Advantages/disadvantages?

The application block provides a bit more functionality, however, than what I have mentioned. The "Encrypt" attribute is necessary, because you can actually specify and create your own encryption algorithms. I assume they would need this attribute to know when to encrypt and decrypt the information.

The application block also allows you to create and specify other storage providers and data transformers. It happens to come with XML-based solutions now, but you can certainly roll your own solutions to work with a database, etc. The hope is that others will also roll their own solutions and we could share efforts. The code in your application would stay the same and all you would do is make modifications to the config file specifying the new storage providers and data transformers.

The application block will also fire off events if changes occur to the underlying storage provider so you can reload any changes in your application.

Then you have the warm-and-fuzzy benefits that may or may not interest some people. Such as the fact that the solution is community supported and thus will have bug fixes and come out with new enhancements as time goes on (we hope!). From an employer’s perspective, it also makes it easier to swap out developers and contract out work if code isn’t so much developer or company specific, but more standard in nature.

All-in-all, however, your comments are valid. Sometimes these application blocks can be overkill and if one has a good solution already in-house, this may not be the way to go. However, for those people who don’t have a solution and can’t or don’t have time to write a solution themselves, it took me all of about 30 minutes to get this running.

What don’t I like about this? Well, it really has nothing to do with configuration, so I think the name is misleading. Serialization can get ugly pretty fast for configuration files though. No defaults. Look at the encrypt attribute for example. Why does that even need to be there?

Instead you could write an XmlActivator that takes in an XmlDocument and returns you an instance based on Type specified in the document. Basically your document would look pretty much like sitesettings.config, except with the root tag have the type attribute. Then you can get rid of the xmlSerializerSection and SiteSettings sub elements. Like so: (here’s hopin’ this works)

<SiteSettings type="SiteSettings, configtest">

<Name>DavidHayden.com</Name>

<Url>http://www.davidhayden.com/</Url>

<EmailAddress>nospam@nospam.com</EmailAddress>

</SiteSettings>

</code></pre>

You pass this into your XmlActivator, it parses it out (in a version a friend recently wrote you could also specify the Type for each parameter, or it would default to string if the attribute was not present though this could also be inferred from the parameter Type through reflection), and uses System.Activator to give you an instance.

This doesn’t do the same thing though you might say. You’re right. If you want to be able to specify a different xmldocument through app.config, you’re also going to need to write a configurationSectionHandler. There lots of examples on the web, and it’s actually a whole lot easier than I thought before I wrote one, so don’t worry, if I can do it anyone can. Instead of all that nasty markup though, you only need your section element specifying the handler to use, and the element named in the section element. That element only needs to contain two attributes: A name for the instance, and the path to the xmldocument. Sure you could add encryption and all that, but I’d recommend you do it manually. Parsing Xml is actually really easy, and it lets you do things like default to no encryption if the attribute is missing.

With this sort of design, for the same example, your xml files would be half the size, and you’d get the same functionality and more.

The config app block could allow other stuff I’m not seeing here, so this is just based on what I see. I’m not familiar with it personally. But from the example it looks like the hard way to do it.

That’s my 2c anyways.