After upgrading to 4.0.4, we have begun updating the bindings in the solutions we're working on to use the new VS 2005 plug-in.
If someone gets latest from Vault and opens a solution that someone else may or may not have updated, is there a way to know that easily?
Does it work okay if one user has updated the bindings on a solution and another user continues to work on that same solution using the VS 2003-compatible plug-in?
Once a solution has been updated to use the VS 2005 plug-in, can it be reverted back to use the VS 2003 version?
Thanks!
Questions about updating source control bindings in VS 2005
Moderator: SourceGear
If you go to the Tools - Options - Source Control, you'll see if a project has been set for the 2003 client (MCSCCI interface) or the 2005 client (VSIP interface). Also, you will not see a source control area under the File Menu when you have a project open that uses VSIP.
To get a better idea of the differences, look at these as two completely different interfaces created by Microsoft. One is not an upgrade of another. Most of Microsoft's products use MCSCCI. These two interfaces are not compatible with each other. As far as I know, VSIP is a new interface created by Microsoft only for Visual Studio.
Once a project has been switched by one user over to VSIP (VS 2005), other users must perform a Get and switch to using VSIP. If everyone decides that they wish to move back to MCSCCI, then everyone can return to using MCSCCI. To return, unbind the project, change the options to the VS2003 client, then go to the Change Source Control diaglog and bind it back to Vault. Save all and make sure the locks return on all files. If you see + signs, that means it needs to be checked in to complete. All users would have to go through those steps, or they can perform a fresh Open from Source Control once the first user has done it.
To get a better idea of the differences, look at these as two completely different interfaces created by Microsoft. One is not an upgrade of another. Most of Microsoft's products use MCSCCI. These two interfaces are not compatible with each other. As far as I know, VSIP is a new interface created by Microsoft only for Visual Studio.
Once a project has been switched by one user over to VSIP (VS 2005), other users must perform a Get and switch to using VSIP. If everyone decides that they wish to move back to MCSCCI, then everyone can return to using MCSCCI. To return, unbind the project, change the options to the VS2003 client, then go to the Change Source Control diaglog and bind it back to Vault. Save all and make sure the locks return on all files. If you see + signs, that means it needs to be checked in to complete. All users would have to go through those steps, or they can perform a fresh Open from Source Control once the first user has done it.
Sorry, I was thinking once something was open, but if you have it open, then you probably know already.
You can tell by the contents of a project file whether it's bound to the MSSCCI or VSIP client.
csproj and vbproj files all have a section at the top like this:
MSSCCI:
<PropertyGroup>
...some stuff we don't care about...
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
</PropertyGroup>
VSIP:
<PropertyGroup>
...some stuff we don't care about...
<SccProjectName>GetTestSolution1</SccProjectName>
<SccLocalPath>2~7EB56C34-4FC7-4FAE-BDBE-D732B77A54F1</SccLocalPath>
<SccAuxPath>http://localhost/VaultService</SccAuxPath>
<SccProvider>SourceGear Vault Visual Studio 2005 Client:{7BE9CE03-56BF-4682-9C06-78C68B134B30}</SccProvider>
</PropertyGroup>
Project files for other project types will have a slightly different format but follow the same general pattern:
You can tell by the contents of a project file whether it's bound to the MSSCCI or VSIP client.
csproj and vbproj files all have a section at the top like this:
MSSCCI:
<PropertyGroup>
...some stuff we don't care about...
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
</PropertyGroup>
VSIP:
<PropertyGroup>
...some stuff we don't care about...
<SccProjectName>GetTestSolution1</SccProjectName>
<SccLocalPath>2~7EB56C34-4FC7-4FAE-BDBE-D732B77A54F1</SccLocalPath>
<SccAuxPath>http://localhost/VaultService</SccAuxPath>
<SccProvider>SourceGear Vault Visual Studio 2005 Client:{7BE9CE03-56BF-4682-9C06-78C68B134B30}</SccProvider>
</PropertyGroup>
Project files for other project types will have a slightly different format but follow the same general pattern:
- SAK = MSSCCI
SourceGear Vault Visual Studio 2005 Client = VSIP
Thanks.
You say "Once a project has been switched by one user over to VSIP (VS 2005), other users must perform a Get and switch to using VSIP."
What will happen if the other users don't do that? Will it break the solution file and csproj file? Revert them back to where it uses MCSCCI? Fail to open at all?
The problem for us is we have a lot of projects (well over 100) in Vault, and we have lots of different people working on them. What we need is a way to see immediately if we've opened a solution in VS with the wrong plug-in. Is that possible?
You say "Once a project has been switched by one user over to VSIP (VS 2005), other users must perform a Get and switch to using VSIP."
What will happen if the other users don't do that? Will it break the solution file and csproj file? Revert them back to where it uses MCSCCI? Fail to open at all?
The problem for us is we have a lot of projects (well over 100) in Vault, and we have lots of different people working on them. What we need is a way to see immediately if we've opened a solution in VS with the wrong plug-in. Is that possible?
Visual Studio 2005 will automatically switch providers when you open a solution. So it should go like this:
0. Everybody installs 4.0.4.
1. One user performs the steps to change the bindings and checks in the changed solution and project files.
2. Other users do a get latest (Note that "Open From Vault" doesn't do a full get if projects already exist on disk, so a get via the stand-alone client is necessary.)
3. Other users open from disk as normal. Visual Studio will switch providers. If some solutions haven't yet been converted, Visual Studio will switch for them when they're opened in the same way. (It's not possible to have some projects in a single solution bound to one client, and some to another. For each solution, all projects have to be bound to the same provider.)
If the other users don't do step 2, the solution will still open, bound to MSSCCI, and they'll see out of date solution/project files. If they do a get latest, Visual Studio should still switch providers, but I don't know that we've tested that. If it behaves strangely, worst case scenario would just involve restarting Visual Studio.
0. Everybody installs 4.0.4.
1. One user performs the steps to change the bindings and checks in the changed solution and project files.
2. Other users do a get latest (Note that "Open From Vault" doesn't do a full get if projects already exist on disk, so a get via the stand-alone client is necessary.)
3. Other users open from disk as normal. Visual Studio will switch providers. If some solutions haven't yet been converted, Visual Studio will switch for them when they're opened in the same way. (It's not possible to have some projects in a single solution bound to one client, and some to another. For each solution, all projects have to be bound to the same provider.)
If the other users don't do step 2, the solution will still open, bound to MSSCCI, and they'll see out of date solution/project files. If they do a get latest, Visual Studio should still switch providers, but I don't know that we've tested that. If it behaves strangely, worst case scenario would just involve restarting Visual Studio.
Ian Olsen
SourceGear
SourceGear