Disabling Configuration Inheritance For ASP.NET Child Applications

by Colin Cochrane 11/15/2007 8:52:00 AM

Configuration inheritance is a very robust feature of ASP.NET that allows you to set configuration settings in the Web.Config of a parent application and have it automatically be applied to all of its child applications.  There are certain situations, however, when there are configuration settings that you don't want to apply to a child application.  The usual course of action is to override the setting in question in the child application's web.config file, which is ideal if there are only a handful of settings to deal with.  This is less than ideal when there are a significant number of settings that need to be overridden, or when you simply want the child application to be largely independent of its parent. 

There solution is Configuration <location> Settings which allows you to selectively exclude portions of an application's web.config from being inherited by child applications.  This made my job a heck of a lot easier yesterday in the installation of BlogEngine.NET for a client that had a CMS.  Naturally the CMS had a rather lengthy web.config packed with a significant amount of settings that were specific to the CMS application, and would generally break any child application that someone would install. Naturally the installation of the blog application was no exception, as I quickly found out there were at least 20 various settings that were preventing it from running.  I had the blog application configured as a seperate application through a virtual directory that was a subdirectory of the main website application (which included the CMS), so by default ASP.NET was applying all the settings the the main application to the blog application.  

The prospect of digging through the large web.config of the CMS and identifying every setting that I would need to override was not a prospect I was particularly thrilled about, so I turned to the <location> element to save me some time.  Since the blog application was essentially independent of the main application there were no inherited settings that it would depend on, so I modified the parent web application's web.config to the following (edited to protect client).


<location path="." inheritInChildApplications="false">
  <system.web>
  ...
  </system.web>
</location>

By wrapping the <system.web> element with the <location> element and setting the path attribute to "." and inheritInChildApplications attribute to "false" I prevented every child application of the main web application from inheriting the settings in the <system.web> element.  After making this modification I tried accessing the blog and just like that there were no more errors and it loaded perfectly.  I could have also set the <location> element to apply specifically for the blog by way of the path attribute if I didn't want to disable inheritance across every child application.  

Aside from the convenience that configuration <location> settings provided in this case, it is also a tremendously powerful way to manage configuration inheritance in your ASP.NET applications.  If you haven't read the MSDN Documentation on this topic, I really encourage you to do so, because there are so many scenarios that configuration <location> settings can be used that you will quickly discover that it is a incredibly valuable tool to have at your disposal. 

Tags: , ,

ASP.NET

Comments (2) -

3/8/2008 11:00:36 PM

You rock man, thanks for posting this on your blog. I was glad to find the solution after hours of searching...

Bruce United States

6/12/2008 3:54:47 PM

Good tip thanks.

Bolsa de Trabajo Mexico

Pingbacks and trackbacks (1)+

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading

Powered by BlogEngine.NET 2.5.0.6

All Content and Intellectual Property is under Copyright Protection | Colin Cochrane ©2007

About the author

Colin Cochrane

Colin Cochrane

SEO and ASP.NET Developer.

Recent comments

Recent posts

Archive

Authors

Disclaimer

This is a personal weblog. The opinions expressed here represent my own and not those of my employer. © Copyright Colin Cochrane 2014

Sign in