ASP.NET Doesn’t Detect IE11

The issue of .NET 4.0 Web pages not rendering properly for specific versions of Internet Explorer is a repeat of the recent inability of the ASP.NET engine to detect IE 10 .  Frankly, I’m surprised that this continues to be a problem and that Microsoft has not come out with a long-term solution other than urging developers to upgrade to ASP.NET 4.5 or face constantly having to deal with detection problems.

In particular ASP.NET 2.0 and ASP.NET 4.0 are in constant danger of serving non-functional Web pages to new versions of Internet Explorer. I do not have sites running ASP.NET 2.0, but have seen this issue happen with .NET 4.0 sites.

I faced this issue previously with the release of IE10. Sadly, while the patch worked nicely for the first release versions of IE10, the recent patch for IE11 does not work at all, and it is looking doubtful that Microsoft will be releasing a working patch for Windows Server 2003 since they plan on discontinuing support for it in 2015 (specifically in: 07/14/2015).

As you may have noticed, I mentioned above that the MS patch worked for the release versions of IE10. That’s because the patch that worked for IE10 did so only to a point. Midway through 2013 Microsoft released a patch for a zero-day exploit that somehow altered the signature of IE to an extent where the .NET 4 engine was no longer able to identify IE10 correctly, and I was back to trying to get the .NET engine to properly serve Web pages.

The Problem with IE11 and IIS6

Apparently Microsoft has fixed the new browser recognition issue for ASP.NET 4.5, but that doesn’t help those of us who for whatever reason cannot upgrade our applications from version 4.0.

For instance; if you are working with a Web server running IIS6 on Win 2003, you will quickly find out that Windows 2003 does NOT support ASP.NET 4.5, nor does it support the latest patches for ASP.NET 4.0.

Getting back to the issue, the process that happens and where the browser detection fails is:

1. IIS serves a Web page to a user running IE 11.
2. IIS asks the ASP.NET 4 engine to render the page
3. but when ASP.NET 4 looks into its ie.browser files, it cannot recognize IE 11
4. So instead of detecting IE11 and serving a modern Web page, ASP.NET 4 treats it as an unknown browser and serves up an extremely down-leveled Web page.

Specifically, when ASP.NET detects an unknown browser, the markup that it serves is significantly different from what it usually serves. From what I’ve seen so far, this includes no working PostBacks or JavaScript, and all inline styling for the .NET web controls is dropped.

This results in some ugly and completely non-functional pages.

Symptoms that a Web Page is Affected

So how can you tell that your Web page is affected by this problem? Well for starters, all of the alignment will be out of whack since the CSS styles and .NET Web control attributes won’t be properly applied. Also, postbacks will likely not work, and your JavaScript may or may not work.

The simplest way to tell is to create an ASP.NET Web page and in the page load method to output both:

Request.UserAgent
Request.Browser.Browser

You will quickly see that the .NET engine is confused when you try to browse to your new page. Specifically, Request.UserAgent will properly pick up the IE11 signature as something like:

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko

On the flip side, Request.Browser.Browser will simply result in a confused response such as:

Mozilla

And that’s the big catch here… IE11 is not in the IIS6 .browser files, so the .NET engine serves up a Web page with mostly disabled functionality.

Fixes that Don’t Work

There are a few options floating about to fix ASP.NET’s ability to detect IE11, but none of which have worked for me. In case you want to try them out, here are the suggested fixes:

1. You can download the patch at: http://support.microsoft.com/kb/2836939/en-us
2. You can try editing the ie.browser file to include IE 11 as explained at: http://stackoverflow.com/questions/18244223/webform-dopostbackwithoptions-is-undefined-in-ie11-preview

The Fix that Worked

Here is what worked for me. I understand that it may not be feasible for everyone since it involves updating the code for each affected Web page on a Web site. However the benefit of this fix is that it is future-proof, so that no matter how many new versions of IE are released, this fix will ensure that your pages still render properly.

1) The first, and most important step was to set the Page.ClientTarget property of each ASP.NET Web page to Uplevel in the page Load method. You may be able to leave out the following two steps, but definitely setting the Page.ClientTarget to uplevel is key.

Note that you will likely want to target IE11 specifically with this setting, since people are reporting that it can cause issues with FireFox running Telerik controls. Take a look at my article about detecting and setting the ClientTarget for IE11 for more details and example code for how to do this.

2) I then updated each page’s compatibility mode to run with several browser options using the following Meta tag (depending on the Markup/JavaScript it needed to support.

For a page with fully functioning HTML5/CSS3 and modern JavaScript:

<meta http-equiv="X-UA-Compatible" content="IE=edge">

For a page with fully functioning HTML5/CSS3 but that uses older JavaScript:

<meta http-equiv="X-UA-Compatible" content="IE=8,9,10" />

3) Finally, I updated the HTML of each page to conform with the HTML5/CSS3 standards, including updating the page headers from the older XHTML tags to:

<!DOCTYPE HTML>
<html>

Why the Fix Worked

Regardless of steps #2 and #3, setting the Page.ClientTarget property to uplevel was the key aspect that corrected how the page rendered.

Why does this work? Well, when the ASP.NET rendering engine detects an unknown browser, it automatically sends the Web page markup tailored to the lowest common denominator Web browser that it can think of. This means that it is intentionally downleveling the page to work for just about anything.

However, in our case this is not good, because users are browsing with the latest Microsoft browser, and the server responds by serving a barely functional Web page.

By setting the ClientTarget default behavior for unknown browsers to uplevel rather than downlevel, we are telling the .NET rendering engine to render a modern working version of a Web page instead of a scaled back version.

This is good, but just be aware that if a really scaled back browser (such as an old mobile browser) does come to your page, the page will possibly not render or function correctly. Also, as I mentioned earlier, some people are reporting that this setting may cause problems with non-IE browsers such as FireFox rendering Telerik controls. To properly handle this, you should put together a script to only set the ClientTarget for IE11 as I explain in a related article.

Once the ClientTarget was set to uplevel, I then updated the HTML and compatibility mode in order for the page to render the content to the highest level of IE possible.

On a side note, it’s interesting that I could force a working version of a Web page to be served if I manually set the compatibility view option in IE. This seems to have altered the browser detection process so that the page was properly served up in quirks mode.