ASP.NET web sites (instead of solutions with projects) are just ghetto and their Web.config files will freak out when you run them as IIS applications it seems.

I am able to run a web site as a web site just fine in IIS, but when I turn around and run it as an application, it starts to break on the sixth line of the Web.config as seen here.

<?xml version="1.0"?>
<configuration>
   <configSections>
      <sectionGroup name="system.web.extensions"
      type="System.Web.Configuration.SystemWebExtensionsSectionGroup,
      System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
      PublicKeyToken=31BF3856AD364E35">
         <sectionGroup name="scripting"
               type="System.Web.Configuration.ScriptingSectionGroup,
               System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
               PublicKeyToken=31BF3856AD364E35">
            <section name="scriptResourceHandler"
                  type="System.Web.Configuration.ScriptingScriptResourceHandlerSection,
                  System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
                  PublicKeyToken=31BF3856AD364E35" requirePermission="false"
                  allowDefinition="MachineToApplication"/>

 
 

This isn't the only point of pain as I can remove this line and hit another hurdle too. The solution seems to be to dumb way down the Web.config, only for IIS applications, like so:

<?xml version="1.0"?>
<configuration>
   <system.web>
      <compilation debug="true" targetFramework="4.0"/>
      <httpRuntime requestValidationMode="2.0" />
      <webServices>
         <protocols>
            <add name="HttpGet"/>
            <add name="HttpPost"/>
         </protocols>
      </webServices>
      <customErrors mode="Off"/>
   </system.web>
</configuration>

 
 

Why so? I don't know yet. Maybe the app pool for 4.0 struggles to provide for the 3.5 stuff? It really doesn't make a lot of sense to me. The Web.config stuff is the most obtuse and murky part of the whole of the ASP.NET/Visual Studio experience in my opinion. None of the wireups are intuitive. You have to just learn the hard way how to deal with stuff not unlike having your car break down on you in order to learn how to maintain an automobile. Trying to hide Web.config doctorings within a NuGet package's magic kind of makes sense and also kind of admits aloud there is something painful that none of us want to think about.