The configuration section 'system.web.extensions' cannot be read because it is missing a section declaration (Happens with a specific branch of Code)

I have noticed that one of the Web applications I work with on a daily basis was having issues running earlier today. The code compiles fine and when the app starts running I receive the HTTP Response 500.19 - Internal Server Error.

Detailed Error Information:

Module     IIS Web Core
Notification       Unknown
Handler    Not yet determined
Error Code     0x80070032
Config Error       The configuration section 'system.web.extensions' cannot be read because it is missing a section declaration
Config File    \\?\C:\TFS\Source Control\ManagementSystem\Prod\MS\App\web.config
Requested URL      http://localhost:40095/Ship/AddEditOrder.aspx
Physical Path      
Logon Method       Not yet determined
Logon User     Not yet determined
Request Tracing Directory      C:\Users\{User}\Documents\IISExpress\TraceLogFiles\

Down below this I see the following:

More Information:

This error occurs when there is a problem reading the configuration file for the Web server or Web application. In some cases, the event logs may contain more information about what caused this error.

If you see the text "There is a duplicate 'system.web.extensions/scripting/scriptResourceHandler' section defined", this error is because you are running a .NET Framework 3.5-based application in .NET Framework 4. If you are running WebMatrix, to resolve this problem, go to the Settings node to set the .NET Framework version to ".NET 2". You can also remove the extra sections from the web.config file.

This sounds like an issue with IIS and I've checked suggested solutions for this issue as follows:

• The configuration section 'system.web.extensions' cannot be read because it is missing a section declaration
• https://www.codeproject.com/Questions/723045/How-can-I-solve-this-problem-The-configuration-sec
• https://gyorgybalassy.wordpress.com/2013/12/02/cleaning-up-iis-express-configuration/

The last article looked the most promising but I was unable to find any trace of the application I was attempting to run.

I finally solved this one!

The message is a bit misleading but after connecting the dots with some of these articles I've come up with the following solution. It appears that my local solution had saved it's own IIS Settings for that specific "site" prior to our .Net Framework upgrade from 3.5 to 4.0. In other words, the IIS entry had a stale app pool framework declaration.

Many of these articles reference the need to change IIS Express Settings that typically point you to a user-based folder directory such as

C:\Users\User\Documents\IISExpress\config\applicationhost.config

However as I mentioned in my original post, there were no remnants of any of my projects here.

I kept digging and found that the solution itself actually keeps a local copy of these settings as well! You'll be able to find them near your local Project Solution in a ".vs" Folder!

Example:

C:\TFS\Source Control\WMS\Prod\WMS.vs\config\applicationhost.config

From there I tracked down my site that was having issues

<site name="WHSMGMTApp" id="3">
                <application path="/" applicationPool="Clr2IntegratedAppPool">
                    <virtualDirectory path="/" physicalPath="C:\TFS\Source Control\WMS\Prod\WMS\WHSMGMTApp" />
                </application>
                <bindings>
                    <binding protocol="http" bindingInformation="*:40095:localhost" />
                </bindings>
            </site>

I navigated to the app pool node for my site and found that it was still on .Net version 2.0 but it needed to be 4.0.

Look for the "Application Pools" Node and find your App Pool

In my case it was Clr2IntegratedAppPool

   <applicationPools> 
<add name="Clr2IntegratedAppPool" managedRuntimeVersion="v2.0" managedPipelineMode="Integrated" CLRConfigFile="%IIS_USER_HOME%\config\aspnet.config" autoStart="true" />
            </applicationPools>

I changed the managedRuntimeVersion from "v2.0" to "v4.0" and boom, it worked!

This seems to be a very niche scenario where you've upgraded your .Net Framework within a solution AND you already have a Local IIS Express entry against a specific branch of code. (This explains why my QA branch was working and not my Prod branch, because they have separate entries in the .config file)

Any insight into why visual studio needs it's own version of this .config is welcome!