Bug: Multiple Source Control Clients

Sep 2, 2011 at 1:19 PM

On my workstation I have to work with different source control clients.  We are in a transition phase from Vault to Mercurial.  The problem I have noticed is if a solution is using VisualHg or Mercurial source control the VisualHg client is not selected as the current source control plug-in if I have previously used a Visual Studio with a different solution using a different source control plug-in.

When a solution is opened that is bound to Vault the source control client automatically switches to the Vault client.  When I open a solution bound to Mercurial the solution will not switch to the VisualHg plug-in.  I have to open the Tools/Source Control/ and manually set the plug-in to VisualHg every time.

What I would be expecting is when I open a solution that is under mercurial source control to have the source control client switched to VisualHg.  This is not the case.

Sep 22, 2011 at 9:31 PM

I second that. I run both SVN and Mercurial on my machine and VisualHG does not switch to itself after opening SVN project.

HgSccPackage is free of this bug.

Oct 6, 2011 at 7:46 AM



Will this be fixed for next release or should I create an issue pointing to this discussion?

Nov 18, 2011 at 7:52 AM

I am having the same problem switching between Team Foundation Server and VisualHg. I have observed the following pattern:

  • If VS starts with anything else than VisualHg as SCC, VisualHg is not automatically used on Mercurial projects.
  • If VisualHg has been activated at least once while VS is running it will work until VS is shut down, even when you switch between Mercurial and TFS solutions.

This suggests that VisualHg is not loaded or does not get informed about VS activities until it has been manually activated (or is active SCC at startup).

I have further downloaded the source code and run some debug sessions on it, watching the debug output. These confirm the above observations and specifically I find that the OnAfterOpenSolution event is not received until VisualHg has once been active.

I am not familiar with the intricacies of VSX but I wonder if there could be an issue that since VisualHg is a SCC it is not hooked up until it is requested? If that is the case then the self-activation inside VisualHg is never called until it has once been activated and hooked up. Maybe the self-activation of VisualHg needs to be in a separate extension that is not a SCC and hence is always hooked up? Something to think about...


Jan 4, 2012 at 12:05 PM

I have Team Explorer 2010 installed as well, and I receive only null reference exception pop ups when I select the Visual HG source control provider. None of the menu options on the toolbar or from the file\VisualHG menu work.