ASP.NET MVC Web.Config <configSections> inheritance problem - by RopstahJ

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 434335 Comments
Status Closed Workarounds
Type Bug Repros 3
Opened 4/22/2009 6:20:21 AM
Access Restriction Public


When creating a new ASP.NET MVC project as a subapplication in IIS the Web.Config settings for <configSections> are inherited from the parent (root in my case) projects Web.Config. These settings cannot be cleared / removed by using <clear /> or <remove name="" /> thus a multiple definition error occurs.

The following page is giving wrong information:
Sign in to post a comment.
Posted by vcohen on 2/2/2010 at 2:45 PM
Well, then it would be nice if you updated the docs on the <remove /> element at and related pages. Those docs have two errors: 1) they don't actually give an example of using <remove />, but rather show the use of <clear />, and 2) they give no indication of the partial implementation you describe, in which configSections and sectionGroups are not affected by <remove />.
Posted by Microsoft on 7/23/2009 at 5:40 PM
<clear /> and <remove /> were never implemented for configSections and sectionGroups because of the difficulty involved attempting to merge different definitions of the same section-handlers and section groups.

We considered adding this type of functionality for the VS 2010 release, but we decided against it for two reasons.

The first one being the additional complexity it brings, in large part because section handlers and section groups are used to bootstrap the configuration system. As a result allowing for merge semantics in the middle of bootstrapping the configuration system is a non-trivial problem to solve.

The second reason is that usually section handlers and section group definitions are made in two distinct places - an initial set of registrations up in the root configuration files, and then an *additive* set of registrations in application level web.config. That doesn't mean a scenario where a developer wants to modify handler definitions isn't valid - its just a low likelihood scenario.

Thank you for taking the time though to submit your suggestion via Connect!
Posted by Microsoft on 6/11/2009 at 5:36 PM
To resolve this specific issue, update the web.config in the parent project to reference the *3.5* versions of System.Web.Extensions et. al. Having the same version information for configuration sections in the parent and child application is Ok and will not trigger any errors. The current errors are caused because the parent is using version numbers from the standalone 1.0 release of AJAX, while the child MVC project is using the newer version numbers from when AJAX was pulled into the .NET Framework.

Its unlikely that the parent and child applications are intended to use two different versions of System.Web.Extensions (and related types)
Posted by Microsoft on 4/22/2009 at 10:29 PM
Thanks for reporting this issue. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team