Visual Studio Binding Problem
Moderator: SourceGear
Visual Studio Binding Problem
Using SourceGear 3.1.9 (3798) and Visual Studio 2005
I'm having trouble getting Visual Studio to bind to the correct Vault folder. As my project is loading up, the bindings seem to be correct since I can see the lock icons next to the files I don't have checked out and checks next to the ones I do. But towards the end of the project loading, things start going wrong again. The icons all turn to the new file (plus sign) icons.
Before loading the project I verified that the working folder was correct in Vault: C:\level1\level2\level3\level4\MyProject, but after Visual Studio finishes loading the project the working folder in Vault is now C:\level1\level2\level3\level4 (the MyProject folder has been dropped).
When I open the Change Source Control dialog in Visual Studio the Server Binding is set to what I want it to be set to, but it is shown as being invalid.
Can someone tell me how to fix this binding problem? ...and then the proper way to control bindings when working with Visual Studio so I don't get into this situation again.
For what it's worth, the project in question was started by copying from another solution and then renaming. No doubt that I did something wrong in that process.
Thanks.
Scott C.
I'm having trouble getting Visual Studio to bind to the correct Vault folder. As my project is loading up, the bindings seem to be correct since I can see the lock icons next to the files I don't have checked out and checks next to the ones I do. But towards the end of the project loading, things start going wrong again. The icons all turn to the new file (plus sign) icons.
Before loading the project I verified that the working folder was correct in Vault: C:\level1\level2\level3\level4\MyProject, but after Visual Studio finishes loading the project the working folder in Vault is now C:\level1\level2\level3\level4 (the MyProject folder has been dropped).
When I open the Change Source Control dialog in Visual Studio the Server Binding is set to what I want it to be set to, but it is shown as being invalid.
Can someone tell me how to fix this binding problem? ...and then the proper way to control bindings when working with Visual Studio so I don't get into this situation again.
For what it's worth, the project in question was started by copying from another solution and then renaming. No doubt that I did something wrong in that process.
Thanks.
Scott C.
I'm not sure I'm doing exactly what you have in mind, but it didn't work as I was hoping. I created a new solution and Added a Project From Source Control. The project was added, but all the files show up as new files in the IDE and the binding still shows as invalid.
...seems really strange that it can't find the files it just pulled down from Vault.
...seems really strange that it can't find the files it just pulled down from Vault.
I opened the project from $\level1\level2\level3\level4\MyProject into C:\level1\level2\level3\level4\MyProject4. All of the files in the project appear as new (with the plus icon and a caution icon). When I go to Change Source Control, the Server Binding is correct but shows as invalid.
At this point I try to set the server binding and notice that, in the Add to Vault Folder window that comes up, the working directory is now C:\level1\level2\level3\level4\MyProject\MyProject -- extra folder added on the end. If I go ahead and try to bind to the folder with the extra level, it still shows as invalid in the Visual Studio Change Source Control window.
At this point I try to set the server binding and notice that, in the Add to Vault Folder window that comes up, the working directory is now C:\level1\level2\level3\level4\MyProject\MyProject -- extra folder added on the end. If I go ahead and try to bind to the folder with the extra level, it still shows as invalid in the Visual Studio Change Source Control window.
I discussed this with our IDE specialist and we suggest upgrading to Vault 3.5.2 before further troubleshooting. There were many fixes in IDE integration after Vault 3.1.x. This may resolve the problem, and if not, at least we'll be troubleshooting a version with better functionality.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager