by Joakim

Using WinMerge as the default diff/merge tool in Visual Studio 2012/2013

Updated: The procedure described below also works for Visual Studio 2013!

I found the default diff/merge tool in Visual Studio 2012 to be a huge improvement over previous versions, as now you are actually able to see what has changed quite easily.


But that being said, I still prefer to use WinMerge as the default diff/merge tool since it has more features. Another nice feature of WinMerge is the possibility to integrate it into Windows Explorer which allows me to diff files (and folders) on my hard drive.

So how do you make WinMerge the default diff/merge tool in Visual Studio?

Go into “Tools –> Options –> Source Control –> Visual Studio Team Foundation Server”, click on “Configure User Tools …”, and add new commands for the “Compare” and “Merge” operations.



Values for the compare command;
Extension: .* (meaning all files)
Operation: Compare
Command: C:Program Files (x86)WinMergeWinMergeU.exe (the path to where WinMergeU.exe is located)
Arguments: /e /u /wl /dl %6 /dr %7 %1 %2 (the arguments for WinMerge, I’ll explain them in detail further down)

Values for the merge command;
Extension: .*
Operation: Merge
Command: C:Program Files (x86)WinMergeWinMergeU.exe
Arguments: /e /u /wl /dl %6 /dr %7 %1 %2 %4

After you add these two commands, right-clicking a file in Visual Studio and selecting “Compare…” should result in the two files being opened and compared in WinMerge. Should you want to go back to using Visual Studio’s own diff/merge tool, you just remove the two commands again.


So what do the values used in the arguments field in the two commands actually mean?

Values starting with a forward slash (/) are WinMerge command-line parameters. The full list of possible parameters can be found here. But I’ll list the ones I use (not all of them are necessary, you may remove some or add others as you prefer):

/e –> Enables you to close WinMerge with a single Esc key press
/u –> Prevents WinMerge from adding either path (left or right) to the Most Recently Used (MRU) list
/wl –> Opens the left side as read-only
/dl –> Specifies a description in the left side title bar
/dr –> Specifies a description in the right side title bar

Values starting with a percentage sign (%) are provided by Visual Studio as input for the WinMerge parameters. You can see what they stand for by clicking the “play” button behind the arguments field when you create the command, but I’ll list them here as well (I’ve greyed out those I don’t use):

%1 –> Original file
%2 –> Modified file
%3 –> Base file
%4 –> Merged file
%5 –> Diff command-line options
%6 –> Original file label
%7 –> Modified file label
%8 –> Base file label
%9 –> Merged file label

WinMerge can be downloaded the from here.

by Andreas

Define a #Region in javascript files (Visual Studio 2010 / 2012)

In these times of super responsive client side processing mega javascript extravaganza web applications  you’re more than likely to end up with fairly large .js files in your projects. The standard code file in Visual Studio allows you to define collapsible sections by wrapping them with the #region / #endregion blocks. In javascript files however, you are restricted to collapsible functions only (“#region” is not recognized as anything valid):


Well, I just found out that that’s not entirely true. By marking a section of code (regardless of any logical blocks) and hitting CTRL + M + H you’ll define the selection as a region which is collapsible and expandable


by Andreas

Visual Studio 2012 – always run as Administrator in Windows 8

In Windows 7 it was easy to turn on “Always run as administrator” for pinned Visual Studio solutions (right clicking the icon and re-open a previous solution in Administrator mode).

In Windows 8 this has changed, and even though you turn on Administrator mode for an application you’re still not able to completely turn off UAC. The result is that if you open a Visual Studio solution directly from a pinned element, you’ll be asked to restart under different credentials when you attempt to debug:



To force every instance of Visual Studio 2012 to run under Administrator credentials, locate the devenv.exe file under

C:Program Files (x86)Microsoft Visual Studio 11.0Common7IDE

Right click the file, choose “Troubleshoot compatibility” and select “Troubleshoot program” from the dialog box. In the next dialog ensure “The program requires additional permissions” is checked and click Next.


As soon as this is done (you’re forced to “Test program” once before you can complete the wizard) you’ll see that opening solutions by right-clicking the VS icon will now run in administrator mode.

by Joakim

External links in Visual Studio not working – Solution

In a previous post I described a problem I’ve been having with external links in Visual Studio not working under Windows 8. The problem only occurred when I started Visual Studio with administrator privileges and had Chrome set as my default browser.

It turned out that this problem was related to the way Chrome registers itself in Windows 8 during install. It also affects launching Chrome from any application run as an administrator (not only Visual Studio). The issue (and an more in-depth description of the problem) can be found here.

In short this problem is fixed if you perform a machine-wide install of Chrome (instead of installing for the current user only). This will be the default in future versions of Chrome on Windows 8, and is already implemented in the development version of Chrome. In order to fix this problem on your own machine today, uninstall Chrome, and re-install it from the dev channel (

by Joakim

External links in Visual Studio 2012 not working when running as administrator (Windows 8)

UPDATED 2: I did manage to find a solution for this problem, which is explained in this post.

UPDATED: I have found that this problem only occurs if you have set some other browser than IE to be the default program for the HTTP and HTTPS protocols (Chrome in my case, haven’t tested with Firefox, Opera, etc.). So, if IE is your default browser in Windows 8, or you’re running Visual Studio 2012 without elevated privileges, you won’t experience this problem.

If you have configured your web application project to use IIS, you have to run Visual Studio as administrator in order for Visual Studio to be able to access the IIS metabase (you won’t be able to load the project otherwise). The same is true if you just want to attach the Visual Studio debugger to website running in IIS without having configured the project to use IIS specifically (this way you will be able to load the project in Visual Studio without administrator privileges though).

I often do set up my web application project to use IIS, or at least I run the website in IIS and attach the debugger to the IIS process, and thus I usually run Visual Studio with administrator privileges. However while doing this, I have discovered a quirk (bug) in Visual Studio 2012 (I don’t think i was this way in 2010, but since I no longer have VS2010 installed I can’t verify it right now). When you run Visual Studio 2012 as  administrator, clicking on external links like the “More Information”-link on a Visual Studio extension, or the “Project Information”-link on a NuGet package doesn’t do anything (you don’t even get a warning or error message).



Clicking on the links depicted above should open your default browser and allow you to read about the extension/package.

The workaround is of course to run Visual Studio as a normal user, but it is quite annoying, especially with regards to NuGet package info if you have set up your web application project to use IIS.

This also affects extension updates, if the update button is supposed to download an external package (i.e. the update doesn’t happen inside Visual Studio).

I couldn’t find any info about this problem having been reported to Microsoft, so I also reported it as a bug.

by Njål

Visual Studio 2012 Fakes – ShimNotSupportedException when debugging tests



When testing VS2012 Ultimate I tried to use the new Microsoft Fakes framework to mock a simple static method. Running the test went fine, but I kept getting a ShimNotSupportedException when debugging the test. 

After goggling and trying all kinds of stuff I finally managed to debug the test by following these steps:

  1. Deleted the local.testsettings file (both in VS and on disk)

  2. Deleted the <solution>.vsmdi file (both in VS and on disk)
  3. Made sure IntelliTrace had these settings (not sure if this mattered):


  4. Restarted VS2012
  5. Made sure that no .testsettings file were selected here


Debugging of tests now works fine!
(Running/debugging the tests from Resharper still does not work – but I can live with this.)

I tried to add a new .testsettings file (with CodeAnalysis and everything else disabled) – but this makes the ShimNotSupportedException reappear again.

Similar Fakes/ShimNotSupportedException/Debug issues have been reported to MS, so I hope they get this resolved soon.


Another sad fact is that the Fakes framework is only available in the Ultimate edition of Visual Studio 2012 – which retails at over USD 13,000. This makes absolutely no sense at all. ALL developers should use unit testing as part of their tool belt – and isolating tests using a mocking framework plays a key role. Microsoft Moles could be used for free in the previous VS 2010 version – and it worked great. This is very disappointing.

Please vote for this issue here: