Debugging TFS Web Access Extensions

Last week I was working on some TFS Web Access extensions. For those who don’t know what this extensions are all about, just try the ‘Task Board Enhancer‘ by Tiago Pascoal and be amazed by the power of it. In short:

In Team Foundation Server 2012 (and 2013) you can develop extensions for the web interface, the extensions are Javascripts that can easily be installed using the TFS Web Access Control Panel. You can create plugins using the Javascript Object Model of TFS. An example can be a custom Work Item Control that can be visualized on the Web Access. More info and some how-to’s here.

One thing that I want to show you in this blog post is how you can speed-up the debugging of your extensions. The normal ‘procedure‘ of debugging your script has the following sequence:

  • Make a change in your Javascript file (including a minified version of your Javascript )
  • Make a zip of your Javascript files and your manifest
  • Open the TFS Web Access adminstration, go to the Extensions page and upload your extension
  • Enable your extension


As you can see, that’s not really a fast way to debug your script. In order to speed up tis deployment/test process, we can use Fiddler. This is a free web debugging proxy which logs all HTTP(s) traffic between your computer and the Internet. Use it to debug traffic from virtually any application that supports a proxy like IE, Chrome, Safari, Firefox, Opera, and more.

A nice thing of Fiddler is the ‘AutoResponder‘ feature. This will actually allow you to route any traffic to another location by adding rules. You can even use Regular Expressions to match the URL that you are looking for. To create a rule, go to the ‘AutoResponder‘ tab in Fiddler, and enable ‘Enable automatic responses‘. You also have to enable ‘Umatched requests passtrough‘ (the other traffic will not pass by otherwise). Click on the ‘Add Rule‘, and enter the following:

  • Rule: “regex:http://tfsserver:8080/tfs/_static/tfs/12/_scripts/TFS/min//tfs/_plugins/.+/your.extension.js”
  • Value: “*header:CachControl=no-cache

This rule responds with a HTTP header modification so that it disables caching of your Javascript resource. Otherwise, code will be requested from the server (unless you clear the browser cache). Next, add a second rule and enter the following:

  • Rule: “regex:http://tfsserver:8080/tfs/_static/tfs/12/_scripts/TFS/min//tfs/_plugins/.+/your.extension.js”
  • Value: “C:\location\to \your\local\Javascriptfile.js

This rule will send the local version of your plugin (on your file system) to the browser. The reason why I’m using Regex is because if you re-install your plugin using the TFS Web Access, it will generate an ID. For example number 1970 like: “…tfs/_plugins/1970/your.extension.js”. Allright, so you will now have something like this:

02So, if you reload your webpage, you will see that the Javascript file of your  plugin will actually be the one from your local machine. So if you change something, just reload your page, set some breakpoints in your F12 debugger console, and you’re ready to go!


That’s it! Have fun developing awesome extensions!

Written by
Alexander Vanwynsberghe
Join the discussion



Alexander Vanwynsberghe

Belgium-based entrepreneur. Into technology, innovation and a bit of cycling and running too. Evangelist for everything related to smart-tech.