Mocha Brain Freeze: HTTP Error 500.19 - Internal Server Error + IIS 7.5

This is the error that faced me the first time I deployed a .net Framework 3.5 web site to IIS via Visual Studio 2010 and then tried to run it. After a couple of hours of digging I traced it back to the application pool but I thought it worthy of a write-up.

Problem

Attempting to run a .net framework 3.5 web site hosted in IIS 7.5 (deployed via Visual Studio 2010) gives the following error information:

Error message:

There is a duplicate ’system.web.extensions/scripting/scriptResourceHandler’ section defined

The error points to sections in the web.config file that ships with the site, a clearer view of which is here:
1: <configSections>
2:   <sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
3:     <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
4:       <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
5:       <sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
6:         <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="Everywhere"/>
7:         <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
8:         <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
9:         <section name="roleService" type="System.Web.Configuration.ScriptingRoleServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
10:       </sectionGroup>
11:     </sectionGroup>
12:   </sectionGroup>
13: </configSections>
This is strange because:

The site runs fine in Visual Studio 2010.

It works when deployed into IIS via Visual Studio 2008 (on a different development machine and in live).

This site works if you alter the framework target to be .net 4.0 and then deploy to IIS and run as normal.

History

This web site was originally developed in Visual Studio 2008 but desperate to try 2010, I followed the procedure below:

Installed 2010 on a clean machine (nothing in IIS).

Converted the 2008 solution but kept the framework target as 3.5.

Ran from Visual Studio.

Deployed to IIS and attempted to run from there.

Fault Finding

My first thoughts were:

That IIS thinks this is a .net Framework 4 site rather than a 3.5. I find this hard to check as aspnet_regiis –lk does not work on Windows 7 (my development OS) and finding anything in IIS 7 is a pain in the neck.

Visual Studio 2010 has messed something up.

Confirming the versions of the target assemblies for the site was problematic however. When the site was built as .net 4 and so worked, I was able to view the Handler Mappings for the site. When it was built for .net 3.5 and so broke, I couldn’t view the mappings as IIS displayed the same error as at run-time:

Solution

It turned out that IIS was confused about the .net framework to use after all, or at least about the application pool version to use.

Viewing the application pools in IIS showed that I had the following:

As you can see, my application was sitting with the default web site inside the DefaultAppPool, which is configured to target .net 4. Moving the site into the Classic.NET AppPool fixed the issue and worked a treat.

It would have been nice for this to have worked out of the box but you live and learn.

This entry was posted on Tuesday, April 20th, 2010 at 19:02 and is filed under .Net Framework, ASP.Net, Errors, IIS, Misc. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.