URL rewrites ing web.configI recently upgraded MiniBlog from using WebPages/Razor 2 to version 3. The upgrade was completely painless. I just upgraded the NuGet package and it didn't even touch my web.config. Thumbs up to the Razor team for that!

Everything seemed to work fine, but then I noticed that my root-relative links such as <a href="~/category/web-essentials"> didn't work correctly anymore. The ~/ no longer pointed to the root of my web application, but instead to the first path segment of my URL. So, when the browser was at /post/my-post, then the ~/ in my link would resolve to <a href="/post/category/web-essentials">. This was wrong.

The reason is that I use URL rewrites in my web.config to map /post/whatever to /index.cshtml?slug=whatever and that was the reason for this strange behavior. Here's my rewrite rule:

<rule name="slug" stopProcessing="true">
  <match url="^post/(.*)" ignoreCase="true"/>
  <action type="Rewrite" url="/index.cshtml?slug={R:1}"/>
< /rule>

So in order to use WebPages/Razor 3 with URL rewrites like mine, I had to tell Razor to ignore the <rewrite> segment in my web.config. That's easily done in global.asax like so:

public void Application_BeginRequest(object sender, EventArgs e)
     Context.Items["IIS_WasUrlRewritten"] = "false";

Now Razor correctly maps to the root of the website when using ~/.  

Not all cases

This little workaround is only needed if your URL rewrites happen in the path of the URL, but not if you use sub-domain rewrites. For instance, if you use URL rewrites to map sub.domain.com into domain.com/sub then it all works fine and you don't need this workaround.


Today the ASP.NET and Web Tools 2012.2 update was released. Go download it right now!

It contains a lot of new and updated Visual Studio tooling features including:

  • First class LESS editor
  • Knockout.js Intellisense
  • Paste JSON as classes
  • CoffeeScript editor
  • Mustache/Handlebars/JsRender syntax highlighting
  • Page Inspector
    • Live CSS auto-sync as you type
    • JavaScript selection mapping and callstack

Some of them are features that started their lives in Web Essentials 2012 and are now ported into an official release. Every time we move features from the experimental Web Essentials extension into the official product, we try to make the transition as smooth as possible.

However, this time we moved some substantial features that are mutually exclusive – they register the same MEF components and that leads to this rather ugly exception:

An exception has been encountered. This may be caused by an extension

This exception occurs when Web Tools 2012.2 is installed and you haven’t updated Web Essentials to version 2.5. The solution is simply to update Web Essentials. Go do that now. If you don’t have Web Essentials installed at all, you won’t get this error because then there is no conflict.


Nerd alert: This post is only for crazy website performance freaks. Proceed at your own risk.

The holy grail for us crazy website performance freaks is to reach a perfect score of 100/100 in Google Page Speed without sacrificing important features of the website we’re building. One of those important features is Google Analytics. Gotta have Google Analytics, right?!

Let’s say that you’ve optimized your website to the perfect score of 100/100 and now decide to add Google Analytics. Too bad, your score is now 98/100. That’s because the ga.js JavaScript file loaded from Google’s servers doesn’t have a far-future expires HTTP header. To get the perfect score back, we need to fix this problem.

Getting back to 100/100

Here’s a solution that I use on one of my websites. It involves the addition of a single .ashx file to your web project. It’s isolated, safe to use and works.

The role of the .ashx file is to act as a proxy to the Google Analytics ga.js script file by downloading its content and serving it with a sufficient expires header. It caches the script file on the server, so it doesn’t have to download the ga.js file every time a visitor hits your website.

Step 1: Add an empty .ashx file (Generic Handler) to the root of you project and call it ga.ashx.

Step 2: Copy this code into the .ashx file you created in step 1.

Step 3: Modify the Google Analytics tracking script on your page to look like this:

    var _gaq = _gaq || [];
    _gaq.push(['_setAccount', 'UA-12345678-9']);

<script src="/ga.ashx" async="async" defer="defer"></script>

Voila! That’s it. You now have the perfect score back.

Optional step 4: Don’t like the .ashx extension? Then change it to .js by adding this to the web.config:

    <rule name="analytics">
      <match url="^ga.js" />
      <action type="Rewrite" url="ga.ashx" />

You need to add it to the <system.webServer> section of web.config. Remember to run the AppPool in Integrated Pipeline Mode for the <system.webServer> section to kick in.

Then just change the script tag to this:

<script src="/ga.js" async="async" defer="defer"></script>

Wait, is this a good idea?

I’ll let you be the judge of that. What I can tell you is that this exact code is running on one of my websites and it reports data to Google Analytics just fine.

Does it work? Yes
Is it cool? Totally
Should I do it? N/A


imageIn the beginning of January, we released the Web Developer Checklist with great interest from the general web community. The checklist helps raising awareness of common best practices for building websites.

It was always the plan to branch the checklist out into technology specific checklists to make it even easier to apply all the best practices.

Today we’re excited to announce the first technology specific checklist – the ASP.NET Developer Checklist. It contains links to many ASP.NET specific tools and solutions to common problems.

Not only is it a great tool for all ASP.NET developers to learn from, but also to track the progress of implementing the various best practices.

We hope it will be received well and add value to the millions of ASP.NET developers worldwide. In the meantime we will be working on finishing another ASP.NET specific checklist that focuses on website performance.

ASP.NET is just the first of many web technologies to receive its own checklist, so remember to check the Web Developer Checklist often for updates.


Rule #1 in website optimization is to enable GZip compression on the web server. This is very easy using web.config as explained here. However, some web servers have disabled automatic compression of JavaScript files, because they are served with the content type: application/x-javascript.

For these web servers we can use a web.config trick to change the content type of JavaScript files to text/javascript. This is a completely valid content type supported by all browsers.

Just paste the following XML snippet in to your web.config’s <system.webServer> section.

  <remove fileExtension=".js"/>
  <mimeMap fileExtension=".js" mimeType="text/javascript" />

Chances are that you don’t have this issue, since it seems to only apply to some hosters, but now you know how to get around it should you ever end up in the situation with uncompressed JavaScript files.