Search

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

Closed
as Fixed Help for as Fixed

3
0
Sign in
to vote
Type: Bug
ID: 434335
Opened: 4/22/2009 6:20:21 AM
Access Restriction: Public
0
Workaround(s)
2
User(s) can reproduce this bug
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:
http://msdn.microsoft.com/en-us/library/ms228258.aspx
Details (expand)
Product Language
English

Version

.NET Framework 2.0
Operating System
Windows XP Professional
Operating System Language
English (US)
Steps to Reproduce
1.) Create a .NET 2.0 project
2.) Add Web.Config entries (see below) direclty after <configuration>
3.) Deploy website to IIS root (e.g. http://intranetserver/)
4.) Create ASP.NET MVC project
(optional) 5.) Add <clear /> or <remove name="system.web.extensions" /> in Web.Config at <configSections>
6.) Deploy website as subapplication of previous website (e.g. http://intranetserver/subapplication/
7.) Visit http://intranetuser/subapplication/default.aspx


Entry for root project web.config
---

<configSections>
<sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication"/>
<sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="Everywhere"/>
<section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication"/>
<section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication"/>
</sectionGroup>
</sectionGroup>
</sectionGroup>
</configSections>

---
Actual Results
Server error:
Section or group name 'system.web.extensions' is already defined. Updates to this may only occur at the configuration level where it is defined.
Expected Results
Display of default MVC website at http://intranetserver/subapplication/default.aspx while maintaining both root and sub web.config settings.
TAP Code (if applicable)
 
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey. [Details]

 

File Attachments
File Name Submitted By Submitted On File Size  
SampleProjects.zip (restricted) 4/22/2009 -
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 http://msdn.microsoft.com/en-us/library/ms228258.aspx 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
Sign in to post a workaround.