Making Your .NET Application Less Quirky

Introduction

I'd like to believe that as developers, we are always looking for those silver-bullet type solutions. The ones where we just add a single line of code, adjust some global setting, and everything improves. Things run faster, more efficiently, and bugs just start resolving themselves - it's great.

This post details a setting that you might not have enabled, especially for older legacy applications, which could result in your not taking advantage of all the wonderful features, benefits, and bug fixes that the .NET framework provides.

Let's See If Your Application is Quirky

The first thing you'll want to do will be to open up the web.config within your application. If you take a look at the <system.web> section, you should see something that looks similar to the following (this particular case is an older ASP.NET MVC application):

<system.web>  
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login" timeout="2880" />
    </authentication>
    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
</system.web>  

The appearance of this section may vary, but it should have a relatively similar structure. The section that we really care about in this post is going to be the <httpRuntime> section:

<httpRuntime targetFramework="4.5" />  

If you have the targetFramework property set, then you can stop reading this post; you are good. If you don't, then you should be jumping for joy at all of the wonderful things that are about to happen to your application. It might seem a bit trivial that a few little characters could have such an effect on your application, so let's talk about exactly what this property means and what it does.

Oh God! My Application is Quirky - What Do I Do?

If you are in the quirky boat mentioned above, then stop what you are doing right now and go add it to your web.config. I can wait, in fact, you can close your browser and don't have to keep reading (although consider buying me a beer if we ever cross paths in the real-world) because everything in your application should now be better. But why?

This all comes down to the way that the .NET Framework actually resolves the version of .NET that your application wants to target, but the key here is this: If there is no <httpRuntime targetFramework> attribute present in web.config, it's assumed that the application wanted 4.0 quirks behavior, which you absolutely do not want.

Fire up Internet Explorer, visit the most modern website you can think of, and then enable Quirks mode. As you watch the hopes and dreams of the site fade away as it becomes a jumbled mess, know that not having the targetFramework set is doing this same thing to your web application.

Basically, if you don't have this attribute set, your web application will run as if it's targeting a ~2009 version of the .NET Framework. Most of the benefits made to the framework for performance, reliability, and security all go flying out the window without this. After adding it in, you'll wonder how you managed to get as far as you did while missing out on all of these incredible features and improvements.

Dequirking in Action

Let's take a look at what applying this to a real-world application might look like. First, we'll just open up the landing page of a large, enterprise-level application that I've worked on in the past:

And then. after applying the fix:

So what are the big differences here:

• Slight Compression Improvements - The overall size of the payload was reduced from 11.3MB to 11.2MB, which while not terribly significant is important (especially at scale).
• Significant Client Loading Time Reduction - The content loading time for the DOM itself was reduced by several orders of magnitude from roughly 3 seconds to 100 milliseconds; a huge improvement.
• Overall Faster Perceived Performance - These faster load times on the client, which nearly reduced overall loading times by a half, and rendered times significantly more, will absolutely be felt by the end user.

If you are more of a chart person, we can see what that would look like here below:

Your mileage may vary, but if improvements like these can be made to just about any application, you'd be downright crazy to not take advantage of them, especially knowing that it just takes a handful of characters to do so.

CodeProject