Hi. We've just postponed our upgrade from Vault 3.5.2 to Vault 4.0. I attempted a test upgrade on a backup copy of the repository and haven't been able to bind our build solution using the Vault 4.0 Visual Studio 2005 plug-in.
Here is a list of problems I ran into in the order that I ran into them:
1) When I tried to Open from Source Control, it wanted to open $/Branch-x/Branch-x. It should have let me open $/Branch-x, since $/Branch-x/Branch-x doesn't exist. [I believe I was still using the VS2003-compatible client, heretofore referred to as VS2003-CC.]
2) When I attempted to open the solution for the first time since upgrade, I needed to point the client to the test Vault server. This had to repeated for every one of the 30 or so projects in the solution. After I got through all that I tried to "Change Source Control" and I think I had to repeat the same 30 dialogs before I could unbind the project using VS2003-CC.
3) When I tried to "Open from Source Control", I got a message, "There are no solutions or project files in this location...". [Believe I was still using VS2003-CC.]
4) Did I mention that every time I've opened a solution, bound or unbound, the plug-in reverts from SourceGear Vault Visual Studio 2005 Client to VS2003-CC? See below.
5) Following the instructions in http://support.sourcegear.com/viewtopic.php?t=7937
VS 2005 or the Vault plug-in always insists on closing my solution when I change Plug-in Selection from VS2003-CC to SourceGear Vault Visual Studio 2005 Client. This combined with the behavior in 4) has made it impossible to get to a point where I could perform the step:
Right-click on the solution and select "Bind" from the context menu.
I went out on a limb here in advocating the upgrade to Vault 4.0, based primarily on feedback from you. I'm feeling like that limb was just sawed off.
Test upgrade from Vault 3.5.2 to 4.0.2 problems.
Moderator: SourceGear
Did you already have a copy of that project on disk that was bound to the previous Vault server? What makes me think that is on #2, you said you had to point each project to the other server.
Since you are just testing, I would suggest just performing an Open from Source Control and use an empty folder on disk to pull the files down to. First, make sure you are working properly with the VS2003 compatible client before trying to make the switch
If you would like to walk through this together, then send an email to support at sourcegear.com (attn: Beth), and we can schedule some time. Please include a link to this forum thread.
Since you are just testing, I would suggest just performing an Open from Source Control and use an empty folder on disk to pull the files down to. First, make sure you are working properly with the VS2003 compatible client before trying to make the switch
If you would like to walk through this together, then send an email to support at sourcegear.com (attn: Beth), and we can schedule some time. Please include a link to this forum thread.
I was using an existing working folder.
Yes, I was using an existing folder, because that is what I believe most of our users will have to do. It was bound using the previous version of Vault, which is why I attempted http://support.sourcegear.com/viewtopic.php?t=7937
I changed my top-level working folder to C:\Vault4.0 and got the latest version of the same branch I was using before. I'm assuming you wanted me to Open from Source Control using the VS2003-CC and then try to unbind/rebind using SourceGear Vault Visual Studio 2005 Client.
We have no .sln files in the top level of our branch. Our build solution lives in $/Branch-x/Build/<product>.sln. This makes it impossible to Open from Source Control on the branch. Also when I Open from Source Control $/Branch-x/Build/<product>.sln, I get a dialog, "The project you have chosen cannot be correctly opened from source control. You are attempting to open a solution or project that was not added to source control using Microsoft Visual Studio. Microsoft Visual Studio support opening solutions from source control only when they are added (or bound) using Microsoft Visual Studio. The user who initially added the solution must use the Change Source Control command to bind the solution to source control in its current location." I have spent many hours trying to do just that, and in the end we've had to modify the .sln files by hand to get the build solution bound. This is why we are interested in upgrading to Vault 4.0.
After dismissing this dialog, I am then able to unbind the project using Change Source Control. After that if I try to change the plug-in to SourceGear Vault Visual Studio 2005 Client, I get a dialog, "Microsoft Visual Studio
Source Control Plug-in
The active solution or project is controlled by a different source control plug-in than the one you have selected. If you change the source control plug-in, the active solution or project will be closed.
Do you want to continue?
Yes No"
If I click "Yes", then the VS offers to save a lot of files and the solution is closed. On re-opening it, I discover that the plug-in is still SourceGear Vault Visual Studio 2005 Client, and Bind is available from the context menu. So I think this is progress.
Now I bind the solution to its position in the repository using SourceGear Vault Visual Studio 2005 Client, and that succeeds. In the process a large Pending Change Set is created. There are some unexpected behaviors:
1) In the .sln file, all of the ProjectRelativeDiskPaths are absolute, e.g. = C:\Vault4.0\Branch-x\Build\... Hey, these paths aren't even correct. Somehow the working folder for $/Branch-x was changed from C:\Vault4.0\Branch-x to C:\Vault4.0\Branch-x\Build and everything got checked out there (including C:\Vault4.0\Branch-x\Build\Build). All of the revised .vcproj files under there. In a previous post, http://support.sourcegear.com/viewtopic ... highlight=
ian_sg said, "We've gone to great lengths to be smarter about what working folder assignments we make based on the relative disk paths for a solution." Not only isn't the path relative, but it isn't even correct in this case.
2) In the .vcproj files, SccProjectName, SccAuxPath, SccLocalPath, SccProvider were all "SAK", meaning "should already know". Now they all have values. SccAuxPath is the URL of the Vault server. SccLocalPath is some kind of GUID. What this means to me is that if we change the SCC provider, we'll have to revise all of our .vcproj files. That is undesirable.
3) After closing VS 2005 and opening the solution again, I got a Vault Login dialog. It appeared to have the correct URL. When I typed in my User name the first 10 times, it refused to log me in. I just tried it again and it worked this time. Go figure. Note I didn't close/reopen. I just clicked ok again.
I'm not sure what you mean by "working properly" with the VS2003-CC. We're interested in upgrading to Vault 4.0 precisely because VS 2005/VS2003-CC doesn't work properly. I won't enumerate all of the problems we've had, but some of them are mentioned in this post or the original post.
Any suggestions? It might be useful to check working folder assignment after unbinding but before rebinding to the new plug-in.
Our source tree is organized as follows (there is some problem with leading spaces in your forum software):
$/MainBranch/
----Build/
--------<build project>.sln (refers to Project1.vcproj, Project2.vcproj, Project3.vcproj, Project4.vcproj)
--------The only other things in this folder are some useful scripts and build-related files.
----SuperProject1/
--------Project1/
------------Project1.sln (generally refers only to Project1.vcproj + plus some dependencies, that might be relative ..\..\SuperProject2\..., e.g. a library)
------------Project1.vcproj
--------Project2/
------------Project2.sln
------------Project2.vcproj
----SuperProject2/
--------Project3/
------------Project3.sln
------------Project3.vcproj
--------Project4/
------------Project4.sln
------------Project4.vcproj
When we branch, we make a copy of MainBranch:
$/Branch-x/
----Build/
--------<build project>.sln
--------...
----SuperProject1/
--------Project1/
------------...
--------Project2/
------------...
----SuperProject2/
------------...
I changed my top-level working folder to C:\Vault4.0 and got the latest version of the same branch I was using before. I'm assuming you wanted me to Open from Source Control using the VS2003-CC and then try to unbind/rebind using SourceGear Vault Visual Studio 2005 Client.
We have no .sln files in the top level of our branch. Our build solution lives in $/Branch-x/Build/<product>.sln. This makes it impossible to Open from Source Control on the branch. Also when I Open from Source Control $/Branch-x/Build/<product>.sln, I get a dialog, "The project you have chosen cannot be correctly opened from source control. You are attempting to open a solution or project that was not added to source control using Microsoft Visual Studio. Microsoft Visual Studio support opening solutions from source control only when they are added (or bound) using Microsoft Visual Studio. The user who initially added the solution must use the Change Source Control command to bind the solution to source control in its current location." I have spent many hours trying to do just that, and in the end we've had to modify the .sln files by hand to get the build solution bound. This is why we are interested in upgrading to Vault 4.0.
After dismissing this dialog, I am then able to unbind the project using Change Source Control. After that if I try to change the plug-in to SourceGear Vault Visual Studio 2005 Client, I get a dialog, "Microsoft Visual Studio
Source Control Plug-in
The active solution or project is controlled by a different source control plug-in than the one you have selected. If you change the source control plug-in, the active solution or project will be closed.
Do you want to continue?
Yes No"
If I click "Yes", then the VS offers to save a lot of files and the solution is closed. On re-opening it, I discover that the plug-in is still SourceGear Vault Visual Studio 2005 Client, and Bind is available from the context menu. So I think this is progress.
Now I bind the solution to its position in the repository using SourceGear Vault Visual Studio 2005 Client, and that succeeds. In the process a large Pending Change Set is created. There are some unexpected behaviors:
1) In the .sln file, all of the ProjectRelativeDiskPaths are absolute, e.g. = C:\Vault4.0\Branch-x\Build\... Hey, these paths aren't even correct. Somehow the working folder for $/Branch-x was changed from C:\Vault4.0\Branch-x to C:\Vault4.0\Branch-x\Build and everything got checked out there (including C:\Vault4.0\Branch-x\Build\Build). All of the revised .vcproj files under there. In a previous post, http://support.sourcegear.com/viewtopic ... highlight=
ian_sg said, "We've gone to great lengths to be smarter about what working folder assignments we make based on the relative disk paths for a solution." Not only isn't the path relative, but it isn't even correct in this case.
2) In the .vcproj files, SccProjectName, SccAuxPath, SccLocalPath, SccProvider were all "SAK", meaning "should already know". Now they all have values. SccAuxPath is the URL of the Vault server. SccLocalPath is some kind of GUID. What this means to me is that if we change the SCC provider, we'll have to revise all of our .vcproj files. That is undesirable.
3) After closing VS 2005 and opening the solution again, I got a Vault Login dialog. It appeared to have the correct URL. When I typed in my User name the first 10 times, it refused to log me in. I just tried it again and it worked this time. Go figure. Note I didn't close/reopen. I just clicked ok again.
I'm not sure what you mean by "working properly" with the VS2003-CC. We're interested in upgrading to Vault 4.0 precisely because VS 2005/VS2003-CC doesn't work properly. I won't enumerate all of the problems we've had, but some of them are mentioned in this post or the original post.
Any suggestions? It might be useful to check working folder assignment after unbinding but before rebinding to the new plug-in.
Our source tree is organized as follows (there is some problem with leading spaces in your forum software):
$/MainBranch/
----Build/
--------<build project>.sln (refers to Project1.vcproj, Project2.vcproj, Project3.vcproj, Project4.vcproj)
--------The only other things in this folder are some useful scripts and build-related files.
----SuperProject1/
--------Project1/
------------Project1.sln (generally refers only to Project1.vcproj + plus some dependencies, that might be relative ..\..\SuperProject2\..., e.g. a library)
------------Project1.vcproj
--------Project2/
------------Project2.sln
------------Project2.vcproj
----SuperProject2/
--------Project3/
------------Project3.sln
------------Project3.vcproj
--------Project4/
------------Project4.sln
------------Project4.vcproj
When we branch, we make a copy of MainBranch:
$/Branch-x/
----Build/
--------<build project>.sln
--------...
----SuperProject1/
--------Project1/
------------...
--------Project2/
------------...
----SuperProject2/
------------...
devenv.exe running with no windows and project still open.
Hi. After I closed VS 2005 I couldn't delete my working folder. I finally discovered that devenv.exe was still running (without any windows), and still had my project open.
Why must the .sln file be at the top level?
Earlier today I deleted my C:\Vault4.0\Branch-x tree and started over, this time paying close attention to working folder assignment during the process. I got bunch of complaints about the out of hierarchy project references, but then when I did a Get Latest Version on the whole branch, VS 2005 seemed happy. This time around, I was able to unbind/bind the project using the SourceGear Vault Visual Studio 2005 client. The folders all look right, so I'm getting closer.