Share via


TFS 2012 Web Access Customizations, Part 5: Using Fiddler to Speed Up Development

The whole process of making a change, creating a package, deploying it to TFS, re-enabling and testing it is very tedious. In order to speed up the development effort, Fiddler can be used.

Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.

Fiddler is freeware and can debug traffic from virtually any application that supports a proxy, including Internet Explorer, Google Chrome, Apple Safari, Mozilla Firefox, Opera, and many others. You can download Fiddler from https://www.fiddler2.com.

  

For our purpose, we need to enable Automatic responses and setup 2 AutoResponder rules as seen on the screenshot above.

The URI should be specific to a target TFS that we are using for testing. We use regex here to support scenarios when we indeed do deploy new version of our plugin through the standard process. At that point, part of the URI for the extension changes (number right after the …/_plugins/ part of the URI) and we do not need to update our rule.

First rule responds with HTTP header modification that disables caching of our .js resource. Otherwise, the code would not be requested from the server unless the web browser cache was cleared.

Second rule bypasses the request and supplies our own development copy of the source file from hard drive.

This way, whenever we do any modification to the source our changes will be immediately propagated to the client browser for testing.

 

Next time, I will show you how to modify Build template to automate extension source file minification and package creation.