I was wondering whether it is possible to get the 2.0.6 and 3.x clients running side-by-side on the same machine. I haven't found a way to do it, but I am able to "hack" around the problem by re-running the installing and choosing "Repair" for the version I am trying to use at a particular time.
However, it would really be nice if we could just install them side-by-side.
Side-by-side installation for the Vault client?
Moderator: SourceGear
Yes, it is possible to run them side by side, but not to easily install them. We have this on our todo list.
See http://support.sourcegear.com/viewtopic.php?t=2450 for more discussion on the issue.
See http://support.sourcegear.com/viewtopic.php?t=2450 for more discussion on the issue.
-
Mark Smeltzer
I hadn't seen that thread, but I'm already using the method it recommends. I've got Vault 2.0.6 installed to a different location than 3.x, and I am able to use both IDEs side-by-side without any problems.
However, using Vault within VS.NET is another story. If I try to use the 3.x client by setting it as the default SCC provider, but the 2.0.6 was the last installer run, then the 3.x plugin interface will fail with a null reference exception. The same is true if I have 2.0.6 set as the default provider and the 3.x installer was last to run.
Currently when I want to switch to a different Vault client I have to use the "repair" option in the corresponding MSI to get the version I want to use to work with VS.NET.
Has anyone that has tried the recommended fix experienced this behavior?
However, using Vault within VS.NET is another story. If I try to use the 3.x client by setting it as the default SCC provider, but the 2.0.6 was the last installer run, then the 3.x plugin interface will fail with a null reference exception. The same is true if I have 2.0.6 set as the default provider and the 3.x installer was last to run.
Currently when I want to switch to a different Vault client I have to use the "repair" option in the corresponding MSI to get the version I want to use to work with VS.NET.
Has anyone that has tried the recommended fix experienced this behavior?
Since Visual Studio does not have an easy way to change which SCC provider to use, you'll need to manually modify the registry key that VS uses.
The registry key that VS uses is:
HKEY_LOCAL_MACHINE\SOFTWARE\SourceCodeControlProvider\ProviderRegKey
If Vault is the default SCC provider, it points to:
HKEY_LOCAL_MACHINE\SOFTWARE\SourceGear\Vault Client
This then uses the SCCServerPath key to find the right DLL to load into VS. You can create a duplicate key with the other version, and swap them in and out when you want to switch back and forth.
The registry key that VS uses is:
HKEY_LOCAL_MACHINE\SOFTWARE\SourceCodeControlProvider\ProviderRegKey
If Vault is the default SCC provider, it points to:
HKEY_LOCAL_MACHINE\SOFTWARE\SourceGear\Vault Client
This then uses the SCCServerPath key to find the right DLL to load into VS. You can create a duplicate key with the other version, and swap them in and out when you want to switch back and forth.
-
Mark Smeltzer
Very cool. Thanks for the explanation.
Perhaps it would be better if the Vault installers installed the client/admin tools to version labeled directories and registry keys so that products like VS.NET would see them as seperate and distinct.
Ex., the 2.0.6 client could be installed in "{program files}\SourceGear\Vault Client 2.0.6\" and 3.0.4 in "{program files}\SourceGear\Vault Client 3.0.4\".
This would probably make it easier to enable side-by-side installation as well -- in some companies this might be a necessity as well.
For example, I could imagine a development house that recommends Vault to its clients, and some of those clients have thus installed various versions of the server and the developers would need various verions of the client application to connect to the various server versions.
Then again... wouldn't it be easier if the Vault client could run in compatibility mode? It might be worth thinking about. Branching the core web service interaction API into external modules that the client and admin tools would load on the fly based on the server version. New features in the client/admin could be supported via FeatureIsSupported("XYZ") type methods exposed by these external modules.
It might require some significant coding, but I think it would be good for your product in the long run. However, in the mean time installing to seperate directories and registry keys would be a step in the right direction.
Perhaps it would be better if the Vault installers installed the client/admin tools to version labeled directories and registry keys so that products like VS.NET would see them as seperate and distinct.
Ex., the 2.0.6 client could be installed in "{program files}\SourceGear\Vault Client 2.0.6\" and 3.0.4 in "{program files}\SourceGear\Vault Client 3.0.4\".
This would probably make it easier to enable side-by-side installation as well -- in some companies this might be a necessity as well.
For example, I could imagine a development house that recommends Vault to its clients, and some of those clients have thus installed various versions of the server and the developers would need various verions of the client application to connect to the various server versions.
Then again... wouldn't it be easier if the Vault client could run in compatibility mode? It might be worth thinking about. Branching the core web service interaction API into external modules that the client and admin tools would load on the fly based on the server version. New features in the client/admin could be supported via FeatureIsSupported("XYZ") type methods exposed by these external modules.
It might require some significant coding, but I think it would be good for your product in the long run. However, in the mean time installing to seperate directories and registry keys would be a step in the right direction.
-
Mark Smeltzer
Just wanted to clarify something from my last post. Actually loading external modules is probably a bad idea, and was just meant to serve as an example of the way such problems have been addressed in times past.
However, being that we're in the glorious days of .NET and design patterns, it might be very cool to create a factory method to connect to a server that returns a connection object. The code could then build out the GUI by passing that connection object to GUI factory methods. Those methods would return different forms (or controls) based upon that type of connection was passed.
For example, passing the 2.0.6 conneciton object to the factory method that displays the "Get Latest" dialog would generate the 2.0.6 specific modal form. The same could be true for the rest of the app -- from the top level menus, down to the status bar.
This model is nice because it allows for clean versioning of functionality with the minimal amount of recoding (though it depends on how well the version specific code is encapsulated in the various dialogs and controls).
I realize this feature may take quite some time to see come to fruition, but I believe it would be a worthwhile investment. Good luck!
However, being that we're in the glorious days of .NET and design patterns, it might be very cool to create a factory method to connect to a server that returns a connection object. The code could then build out the GUI by passing that connection object to GUI factory methods. Those methods would return different forms (or controls) based upon that type of connection was passed.
For example, passing the 2.0.6 conneciton object to the factory method that displays the "Get Latest" dialog would generate the 2.0.6 specific modal form. The same could be true for the rest of the app -- from the top level menus, down to the status bar.
This model is nice because it allows for clean versioning of functionality with the minimal amount of recoding (though it depends on how well the version specific code is encapsulated in the various dialogs and controls).
I realize this feature may take quite some time to see come to fruition, but I believe it would be a worthwhile investment. Good luck!