Changing repository in VS2005 IDE
Moderator: SourceGear
Changing repository in VS2005 IDE
I'm using Vault v4.1.1, and I'm using the enhanced client.
I've always had two possible "names" for the repository - an internal name (just server name) and an external name with a specific port number. I've been using the external name, I now need to switch to using the internal name.
Switching in the Vault client seemed to be no problem; just change the name of the server to connect to and I'm done. However, the IDE client continues to remember connecting via the external name.
Obviously, I need to tell the VS2005 IDE enhanced client that I'm connecting via the internal name, but casually perusing the menus and looking at help doesn't tell me how to do it.
I'd like to make this change for all solutions. Looking at a .SLN file shows the repository path stored in the file - which tells me this probably needs to change but I'm not sure how to do this. I suppose I could check out the .SLN file and modify it with an editor...
I've always had two possible "names" for the repository - an internal name (just server name) and an external name with a specific port number. I've been using the external name, I now need to switch to using the internal name.
Switching in the Vault client seemed to be no problem; just change the name of the server to connect to and I'm done. However, the IDE client continues to remember connecting via the external name.
Obviously, I need to tell the VS2005 IDE enhanced client that I'm connecting via the internal name, but casually perusing the menus and looking at help doesn't tell me how to do it.
I'd like to make this change for all solutions. Looking at a .SLN file shows the repository path stored in the file - which tells me this probably needs to change but I'm not sure how to do this. I suppose I could check out the .SLN file and modify it with an editor...
The solution is currently bound to one repository path, so you need to unbind it and rebind to the other repository.
Open the solution and in Visual Studio select File->Vault Source Control->Change Vault Bindings. Unbind the project, and Save all.
Next, click Bind. You'll get a login prompt. Select the correct repository and bind the project to the new location.
Open the solution and in Visual Studio select File->Vault Source Control->Change Vault Bindings. Unbind the project, and Save all.
Next, click Bind. You'll get a login prompt. Select the correct repository and bind the project to the new location.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Linda,
I've not tried this yet, I want to confirm something about some of my solutions.
I've got projects A, B, C, D, E, F
Solution 1 refers to A,B,C
Solution 2 refers to B,C,D,E
Solution 3 refers to B,E,F
I don't think I have a solution that refers to every project.
If I call up solution 2 and rebind, what happens when I call up Solution1? Will it recognize that it's bound to two different servers? Would I then unbind and rebind only the projects bound to the old server (where old server is external name and new server is internal name)?
I've not tried this yet, I want to confirm something about some of my solutions.
I've got projects A, B, C, D, E, F
Solution 1 refers to A,B,C
Solution 2 refers to B,C,D,E
Solution 3 refers to B,E,F
I don't think I have a solution that refers to every project.
If I call up solution 2 and rebind, what happens when I call up Solution1? Will it recognize that it's bound to two different servers? Would I then unbind and rebind only the projects bound to the old server (where old server is external name and new server is internal name)?
I don't believe that mixing and matching server bindings is going to work. It's best to keep everything consistent. I would suggest pulling up each solution in Visual Studio and performing the unbind and rebind.
Is there any reason why you can't use the external address when you are internal as well? It would save you from bouncing back and forth in bindings.
Is there any reason why you can't use the external address when you are internal as well? It would save you from bouncing back and forth in bindings.
Beth,
I have no intention of leaving the server bindings mixed; but since my references are all external now I have to get to all internal and some of my C# projects are part of more than one solution in the project (common DLLs that are included in multiple solutions to make debugging easier).
I was using the external bindings internally, but our firewall is being replaced and I lost an argument with corporate IT about whether Vault should be accessible via a port on the firewall or by VPN only. They wanted VPN, and I won't have control of the firewall, so I've got to convert to internal references only.
Having looked at the XML files, it would clearly be possible to check them all out with the standalone client, modify the server name, and check them back in. Would that work, or is it too dangerous, or what? I don't know how much the enhanced client inside of VS2005 knows outside of the information thats in the SLN and CSPROJ files.
It was a trivial change for the standalone client.
I have no intention of leaving the server bindings mixed; but since my references are all external now I have to get to all internal and some of my C# projects are part of more than one solution in the project (common DLLs that are included in multiple solutions to make debugging easier).
I was using the external bindings internally, but our firewall is being replaced and I lost an argument with corporate IT about whether Vault should be accessible via a port on the firewall or by VPN only. They wanted VPN, and I won't have control of the firewall, so I've got to convert to internal references only.
Having looked at the XML files, it would clearly be possible to check them all out with the standalone client, modify the server name, and check them back in. Would that work, or is it too dangerous, or what? I don't know how much the enhanced client inside of VS2005 knows outside of the information thats in the SLN and CSPROJ files.
It was a trivial change for the standalone client.