VS.NET binding fails - VS.NET unresponsive

[Adrian Pell]

I'm currently evaluating SOS - and it seems great in most cases. The server installation went really easily, and the SOS Explorer works wonderfully even over my patchy VPN connection. However ...

I'm having real problems getting my VS.NET projects hooked up. I originally tried rebinding the projects manually - I could select the database ok as an SOS one, but I couldn't get a valid binding for the project. So, after reading some other posts here, I decided to go for the full "Open from Source Control" treatment.

I checked everything in with a VSS binding, then blew away all the local projects (BTW - there are VB.NET, C# and ASP.NET web sites and web services in this solution - 36 projects in total in the solution). Absolutely nothing left in either my projects directory or in /inetpub/wwwroot for the web projects.

I switched to SOS as my default SCC provider, and started VS.NET and did an "Open from Source Control", pointing it at the project that contained my solution file. It seemed to start off well - fetching all the files and creating the correct project structure. But at some point, I think when fetching one of the web projects, it just stops doing anything - the operation never completes and VS.NET stops responding completely.

I've tried this 3 times already (which is a little frustrating to say the least) with pretty much the same results. Switching back to a VSS binding puts everything back into a working state (except that I still can't use source control over my VPN link).

I know that I could use the SOS explorer to do check out/in, but it's a bit of a klunky way to do it, and shouldn't IMHO be necessary.

So ... any ideas? Any logging I should turn on to see what's happening here?


Many thanks

Adrian

[Adrian Pell]

I just went back and looked at the server logs for the times when I was attempting to bind VS.NET to SOS. No errors at all, but I do see a large number of separate sessions - like 40 or so - during the period where I was attempting to open the solution from SCC. Is that a clue?

Adrian

[Adrian Pell]

I just found a reference to one of your KB articles which talked about change in the way that VS.NET holds its binding information - previously it used to be in .sln and .vbproj files - now it's in separate SCC files. Well ...

That started me looking at my solution files, even though I'm running the latest SOS and VSS clients. Take a look at this section:

SccProjectUniqueName31 = C#\u0020Process\u0020Handler\u0020Sample\\MsdnProcessHandler.csproj
SccLocalPath31 = .
CanCheckoutShared = false
SccProjectFilePathRelativizedFromConnection31 = C#\u0020Process\u0020Handler\u0020Sample\\
SccProjectUniqueName32 = http://localhost/RoomWebService/RoomWebService.vbproj
SccProjectName32 = \u0022$/Portal40/RoomWebService\u0022,\u0020ZIVBAAAA
SccLocalPath32 = ..\\..\\inetpub\\wwwroot\\RoomWebService
CanCheckoutShared = false
SccProjectEnlistmentChoice32 = 2
SccProjectUniqueName33 = SiteAccess\\SiteAccess.vbproj
SccLocalPath33 = .
CanCheckoutShared = false
SccProjectFilePathRelativizedFromConnection33 = SiteAccess\\


The 3rd project (33) in this set is really relative - the scc project names are relative to something at the top level, but the other two (one a C# project, and the other an ASP.NET project) have a weird server name piece \u0022 and what looks like a VSS pathname. All the ASP.NET projects are of this form, but not all the C# projects.

Is that any more useful?

Adrian

[corey]

Hi Adrian,

I think you're on the right trail... there's probably a problem in the solution file with one or more projects and its probably related to SourceSafe specific bindings. Even though Microsoft fixed those issues with other types of solutions in the latest versions of Visual Studio, the problem still exists for most web apps.

Does the failure always occur on the same project when you're attempting to open the solution from source control? If so, then you may be able to manually modify the solution file to fix the problem by changing the strings listing the problematic project to match those of the other ones that are okay. For instance, if its the 3rd project (33) that's causing the failure, then you may be able to manually fix those strings to match the format for the other projects.