I followed the description in another post here on how to change the source control provider up to the 2005 version and was able to do so right up until the point where I select the Bind menu item on the context menu of the solution.
This just gives me the following error message:
---------------------------
Microsoft Visual Studio
---------------------------
Project node count mismatch
---------------------------
OK
---------------------------
The first time I do this after opening up visual studio it takes a few seconds before it gives me the error, which also comes in a tool-window-like window, but the second time it gives me the normal message box window.
For the time being I'll just do an undo checkout and reload from source control and keep the 2003 version but I'd very much like to know what to look for so that I can upgrade.
Project node count mismatch, error when rebinding
Moderator: SourceGear
Re: Project node count mismatch, error when rebinding
[quote="lassevk"]I'd very much like to know what to look for so that I can upgrade.[/quote]
To re-bind the solution, we now have a recomended set of steps at the following KB article:
http://support.sourcegear.com/viewtopic.php?t=7937
Please try re-binding using those steps and let us know if you still get the same error message.
To re-bind the solution, we now have a recomended set of steps at the following KB article:
http://support.sourcegear.com/viewtopic.php?t=7937
Please try re-binding using those steps and let us know if you still get the same error message.
Still same result
Yes, I still get the same problem, right after this step:
-- Right-click on the solution and select "Bind" from the context menu.
I'll try manipulating the solution to try to figure out if there's a specific problem that is causing the problems.
-- Right-click on the solution and select "Bind" from the context menu.
I'll try manipulating the solution to try to figure out if there's a specific problem that is causing the problems.
No-go
The only way to get the bind command to complete is to remove about half of the projects. I've tried narrowing it down to a specific project but it doesn't seem to care which one is the last I remove.
The solution contains about 6 application projects, 18 class libraries and a setup project, as well as some sundry solution files (some html files and similar that have been added to the solution).
The solution contains about 6 application projects, 18 class libraries and a setup project, as well as some sundry solution files (some html files and similar that have been added to the solution).
Solution folders is unsupported
The bind command does not handle solution folders.
Right-click the solution and make a "Solution folder" and then try to bind it, you'll get the error message.
I had to remove all non-project files from the solution, move all projects out of their folders (solution folders are virtual folders only existing in the solution file, not on disk), and then remove all the folders, then I was able to bind.
Right-click the solution and make a "Solution folder" and then try to bind it, you'll get the error message.
I had to remove all non-project files from the solution, move all projects out of their folders (solution folders are virtual folders only existing in the solution file, not on disk), and then remove all the folders, then I was able to bind.
-
evelasquez
- Posts: 6
- Joined: Mon Jun 04, 2007 12:33 pm
Why is the download secret? Public beta may be a valuable lesson learned out of this. State it's not production, but in this case it is better than production! Often vendors post "interim" builds under the understanding it's not a production release.
Neal Culiner
NC Software, Inc.
http://www.nc-software.com
Vault 5.1.2
VS 2010/C#
Windows 7 Ultimate x64
VB.NET Forums: http://www.vbdotnetforums.com
NC Software, Inc.
http://www.nc-software.com
Vault 5.1.2
VS 2010/C#
Windows 7 Ultimate x64
VB.NET Forums: http://www.vbdotnetforums.com
Well, I suppose it's private because people like me will assume that the .0.1 versionis out and will happily download and install it, only to have it break something (it's not done yet, right?)... Then I will come here and complain loudly even though my expectations were too high, as I have in the past 
gabriel magana-gonzalez
Neal, there was a public beta of Vault 4.0.
Not all pre-release versions are fit for public consumption, even when marked as beta.
Edit: oops, I thought there had been a public Vault beta along with the Fortress beta.
Not all pre-release versions are fit for public consumption, even when marked as beta.
Edit: oops, I thought there had been a public Vault beta along with the Fortress beta.
Last edited by GregM on Mon Jun 11, 2007 8:39 am, edited 1 time in total.
The download is not yet public, because we haven't yet released 4.0.1. There have been many issues that came up over the last week since we released 4.0.0. I didn't want to release several 4.0.x's in the space of a week. The release of 4.0.1 will happen early this week.
There was a public preview of Fortress for months, which had all of these bugs that have been reported only now after release. This points out that if there had been a preview of Vault 4.0, we would have gotten much more use, and therefore much more useful bug reports. Consider this a lesson that has been learned by me.
There was a public preview of Fortress for months, which had all of these bugs that have been reported only now after release. This points out that if there had been a preview of Vault 4.0, we would have gotten much more use, and therefore much more useful bug reports. Consider this a lesson that has been learned by me.
I can confirm this bug on solutions that have "Solution folders" which are folders within the solution (used to organize projects within a solution). Having any solution folders causes this error, regardless of whether or not there are any projects within the solution folder.
The work around for me was (as part of a migration from the 2003-style binding):
- At the point when you are about to right click on the solution file (within the VS2005 IDE) to click on "Bind", drag and drop all the projects in the solution folders to the root of the solution.
- Delete all the solution folders
- Right click on the solution and click on "Bind." All should bind OK.
- Check in the solution. Reload if so prompted. The physical path of the projects should not have changed, nor should the location of the projects within Fortress... Check for this with the Fortress client.
- Now, recreate your solution folders and re-add the projects to the appropriate solution folders.
- Check in, and re-verify that all the files are where they should be.
Hope this helps someone...
The work around for me was (as part of a migration from the 2003-style binding):
- At the point when you are about to right click on the solution file (within the VS2005 IDE) to click on "Bind", drag and drop all the projects in the solution folders to the root of the solution.
- Delete all the solution folders
- Right click on the solution and click on "Bind." All should bind OK.
- Check in the solution. Reload if so prompted. The physical path of the projects should not have changed, nor should the location of the projects within Fortress... Check for this with the Fortress client.
- Now, recreate your solution folders and re-add the projects to the appropriate solution folders.
- Check in, and re-verify that all the files are where they should be.
Hope this helps someone...
gabriel magana-gonzalez
I'm still experiencing the 'project node count mismatch' error when rebinding a solution using the 2005 provider using the instructions mentioned in the knowledgebase article with Vault 4.0.1 in case you're interested. The only way I could successfully rebind the solution was to remove all projects and solution files, rebind the solution and add the projects and solution files again. Bit of a pain!