500.22 HTTP Error After Implementing Bundles in Web Forms Application and Publishing to IIS

So that was a very long title, but this really threw me for a loop. I implemented bundling via the Microsoft ASP.NET Web Optimization Framework NuGet package and it worked great in my ASP.NET development web server. The issue came when I deployed the site to the (previously working) development environment running IIS 7.5. All of the CSS and JS files referencing the bundles returned 404 errors. I looked through the Web.config and verified that everything was correct. I put Event Log entries into the Global.asax and found that they were all adding as expected.

I did some digging through Google but the number of people adding Bundles to their Web Forms application is smaller than I had expected and didn't find to much (nothing useful). Not having setup the environments, I thought that would be a great place to investigate further.

Investigating the web site in inetmgr, yielded nothing out of place. I am not sure why I looked at the application pool, but I did, and noticed that the pipeline was set to Classic, so I tried changing it to Integrated (just trying something). When I refreshed the page, I received a 500 HTTP internal server error and no other information. There was no information in the Event Log and the debugger never caught any breakpoints.

I went back to inetmgr and I turned on logging, recreated the error, and looked at the log. I found that the status code was 500 and the sub-status was 22 (500.22). This was a key bit of information. Googling this code yielded gold. I found this site, ASP.NET 2.0 Breaking Changes on IIS 7.0, which contained the status code I was looking for. Below is the important section:

1. ASP.NET applications require migration when specifying configuration in <httpModules> or <httpHandlers>

You will receive a 500 - Internal Server Error. This can include HTTP Error 500.22, and HTTP Error 500.23: An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode. This occurs because ASP.NET modules and handlers should be specified in the IIS <handlers> and <modules> configuration sections in Integrated mode.

Workaround

A. You must migrate the application configuration to work properly in Integrated mode. You can migrate the application configuration with AppCmd:

> %windir%\system32\inetsrv\Appcmd migrate config "<ApplicationPath>"

B. You can migrate manually by moving the custom entries in in the <system.web>/<httpModules> and <system.web>/<httpHandlers> configuration manually to the <system.webServer>/<handlers> and <system.webServer>/<modules> configuration sections, and either removing the <httpHandlers> and <httpModules> configuration OR adding the following to your application’s web.config:

<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>

I opted for the first part of B. The latter part may have been a little easier, but the first part seemed cleaner.

Refreshing the page allowed the bundles to be served up without issue. Apparently the Microsoft ASP.NET Web Optimization Framework requires the application pool to be in Integrated mode. That was a very weird error and obscure solution.

IIS Application Pool Disable "Ping Enabled" Via Powershell

Probably one of the most frustrating features of debugging Visual Studio is that it will stop debugging an IIS process after a short amount of time and display a dialog box which says:

The web server process that was being debugged has been terminated by Internet Information Services (IIS). This can be avoided by configuring Application Pool ping settings in IIS. See help for further details.

To add insult to injury, it makes you click OK for every application pool that has timed out. In an environment where you have a 4-5 processes attached, this is an annoying waste of time.

It has been long known and pretty well documented on how to fix it in the IIS gui. It is a rather slow process and needs to be automated.

Here is my Powershell function. It will find all of the application pools that start with the specified string and disable the "Ping Enabled" field.

function Disable-Pinging($appPoolNameStartsWith = 'SharePoint - ') {
 Import-Module WebAdministration;
 sl iis:\AppPools;
 Get-ChildItem | ? { $_.Name.StartsWith($appPoolNameStartsWith); } | % { 
  $_.processModel.pingingEnabled = $false; 
 }
 Remove-Module WebAdministration;
}