Monthly Archives: February 2010

ASP.Net Config Error: “This configuration section cannot be used at this path.”

I recently setup an ASP.Net 3.5 web application on a new Windows 2008 R2 server with IIS 7 and ran into a few issues.  I will post about them all under the tag: “asp.net 3.5 with iis 7“.

After setting up the file system and creating the application, I tried to load the default document in a browser and got:

HTTP Error 500.19 – Internal Server Error

The requested page cannot be accessed because the related configuration data for the page is invalid.

Module IIS Web Core
Notification BeginRequest
Handler Not yet determined
Error Code 0x80070021
Config Error This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault=”Deny”), or set explicitly by a location tag with overrideMode=”Deny” or the legacy allowOverride=”false”.

Module IIS Web Core Notification BeginRequest Handler Not yet determined Error Code 0x80070021 Config Error This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault=”Deny”), or set explicitly by a location tag with overrideMode=”Deny” or the legacy allowOverride=”false”.

The solution was to make a change in the applicationHost.config file.

  1. Browse to “C:WindowsSystem32inetsrvconfig” (you will need administrator rights here)
  2. Open applicationHost.config
  3. Find the section that showed up in the “config source” part of the error message page.  For me this has typically been “modules” or “handlers”
  4. Change the overrideModeDefault attribute to be “Allow”
  5. So the whole line now looks like:
  6. <section name="modules" allowDefinition="MachineToApplication" overrideModeDefault="Allow" />

After saving the file, the page loaded up fine in my browser.

Visual Studio 2008 Web Setup Project, Web Deployment Project, and MSDeploy

I have been developing a strategy for deploying an ASP.Net Web Application (Visual Studio 2008, .NET 3.5) to staging servers, and to production.  In the process, I have encountered 3 products from Microsoft that almost sound synonymous to the untrained ear, but are very different and are designed for completely different purposes.  I wish that this post would have been written by Microsoft to emphasize the differences and pros/cons from their perspective.

But after spending some time researching and playing around with each, here is my summary:

Web Setup Projects

  • Builds an MSI (installer) that will install and setup a web application on an IIS server.
  • Included in Visual Studio 2008 out of the box.
  • Accessed by: File > New Project, select “Other Project Types” > “Setup and Deployment” on the left side, then select “Web Setup Project” on the right side.

Web Deployment Projects

  • Uses MS Build scripts to pre-compile and prepare a web application for deployment.
  • Visual Studio “add-in” released by Microsoft.
  • Downloaded free at: http://www.microsoft.com/downloads/details.aspx?FamilyId=0AA30AE8-C73B-4BDD-BB1B-FE697256C459&displaylang=en
  • Accessed by: (after installing add-in) Right-click the web application project node and select “Add Web Deployment project…”
  • Lets you specify different “build configurations” (besides Debug and Release) that enable you to have web.config replacement for your different builds.
  • Pre-compiles aspx pages with two choices, allowing the .aspx (not the code behind) to be modified on the server, or even compiling in the data from the .aspx files.  In the second case, a “dummy” file is created with the aspx filename, but it is essentially blank–everything gets put into the dll.
  • Merges multiple dll’s into a single one for easier deployment.

MSDeploy

  • Written by the IIS team.
  • Enables easy syncing of content and configuration settings between IIS servers.
  • http://www.iis.net/?tabid=20111
  • Installed as an addition to the IIS Manager on either the source or destination server.
  • Easy to package up an existing virtual directory/application with all its content, settings, dependencies, etc.
  • Easy to push out this package to many servers in a farm to have identical web sites.

My understanding is that Visual Studio 2010 is much more prepared to interact directly with MSDeploy than Visual Studio 2008 is (though I haven’t tried these features out there yet).  It seems they have taken many of the concepts of “Web Deployment Projects” and built them in standard to VS 2010, and used that type of methodology to produce the packages for MS Deploy.