I'm having trouble binding projects in VS .NET when using SOS as my solution provider. Every time I try I get an "Unspecified Error" dialog box.
We have 2 locations accessing a VSS DB through VS .NET 2003. One location is on the same local net as the DB and the other is remote over the internet. Originally we had the remote location using SOS and the local using VSS. We were experiencing some trouble and tracked it down to VSS being hardwired in some of our .vcproj files. I tried unbinding and rebinding the projects but got the same result. After some research I found out it was because of our directory structure where some of the source files are above the directory containing the corresponding .vcproj file in both the working directory and the repository. We had good reasons to keep our directory structure that way and decided to have both locations go to SOS as the source code provider in VS. To switch to SOS, I unbound the previous project bindings, made SOS the default source code provider, and then attempted to re-bind the projects. I was able to bind the solution, but I got the binding error whenever tried to bind a project by itself or along with the solution. I'm able to use the SOS client fine from the same computer where I'm having the VS binding issues. I also was able to go back to VSS as the solution, but I need to make SOS work so that the two locations are compatible. I'm out of ideas and hoping someone can help.
Thank you in advance.
Using SOS 4.1.2 in VS .NET 2003
Moderator: SourceGear
Using SOS 4.1.2 in VS .NET 2003
Mike O'Donnell
Turbocam Inc.
Turbocam Inc.
More info
Here's some more information on the problem. I found that I could bind all projects that had a standard directory layout, where the source files for a project are all at or below the folder containing the .vcproj file. (In both the repository and the working directory structures.) So it seems that the problem is isolated to projects where there are souce files in a project are not within the project file's folder or within folders below that folder. Most of our source files directories are used by multiple solutions and projects, so we don't want to put them under a particular project.
Mike O'Donnell
Turbocam Inc.
Turbocam Inc.
The binding problem that you are reporting related to VS.Net users using both SOS and VSS has been resolved. Following the directions listed in the KB article below should resolve the SOS/VSS issues.
http://support.sourcegear.com/viewtopic.php?t=1149
In regards to the binding problem that you are experiencing, this is probably due to the fact that you don't have your solutions set up as VS.Net expects.
For example, if your solution is located on c:\projects\Solution1, then all of the projects, folders, and files that are used within the solution should be located somewhere at or under c:\projects\Solution1.
Tonya Nunn
SourceGear Support
http://support.sourcegear.com/viewtopic.php?t=1149
In regards to the binding problem that you are experiencing, this is probably due to the fact that you don't have your solutions set up as VS.Net expects.
All files and folders that are contained within the solution or project being used need to be within your working folder hierarchy.So it seems that the problem is isolated to projects where there are souce files in a project are not within the project file's folder or within folders below that folder. Most of our source files directories are used by multiple solutions and projects, so we don't want to put them under a particular project.
For example, if your solution is located on c:\projects\Solution1, then all of the projects, folders, and files that are used within the solution should be located somewhere at or under c:\projects\Solution1.
Tonya Nunn
SourceGear Support
Thank you for your quick reply. I now understand that we'll need to rearrange our directory structure for SOS to work properly, and once we do that we'll also be able to use SOS and VSS 6.0d on the same VSS db.
I'm not sure I understand one comment in your response though:
"In regards to the binding problem that you are experiencing, this is probably due to the fact that you don't have your solutions set up as VS.Net expects. "
We've found that VS .NET and VSS 6.0d handle our directory structure as long as we point the bindings to the common directory root of all the files in a project. We seem to have trouble when requiring SOS to handle the same situation when integrated in VS .NET as the source code provider.
I'm not sure I understand one comment in your response though:
"In regards to the binding problem that you are experiencing, this is probably due to the fact that you don't have your solutions set up as VS.Net expects. "
We've found that VS .NET and VSS 6.0d handle our directory structure as long as we point the bindings to the common directory root of all the files in a project. We seem to have trouble when requiring SOS to handle the same situation when integrated in VS .NET as the source code provider.
Mike O'Donnell
Turbocam Inc.
Turbocam Inc.
Please let me know if rearranging your directory structure doesn't resolve the problem.
My statement in regards to VS.Net expecting your solutions to be organized differently was perceived from Microsoft's articles in regards to folder structure using VS.Net with source code control. They specifically specifiy what I noted below, that all files and folders that are contained within the solution or project being used need to be within your working folder hierarchy which doesn't appear to be the way your folders were organized.
Again, please let me know if the problem persists.
Thanks,
Tonya
My statement in regards to VS.Net expecting your solutions to be organized differently was perceived from Microsoft's articles in regards to folder structure using VS.Net with source code control. They specifically specifiy what I noted below, that all files and folders that are contained within the solution or project being used need to be within your working folder hierarchy which doesn't appear to be the way your folders were organized.
Again, please let me know if the problem persists.
Thanks,
Tonya