Unspecified error in 4.2 Client with VS 2008 under Vista

[Metaphore]

The project was checked in with VS 2005 under XP, then checked out with VS 2008, upgraded and checked back in with 2008 still under XP.

Installed Vista, VS 2008 and SOS 4.2 client.

When I go to change source control, the path binds OK, but the sln gives the following error message:

Error: Unspecified error
File: vsee\pkgs\vssprovider\cmsscciabstrationlayer.cpp
Line number: 5892

Any suggestions?

[Terence]

Have you applied the VSS 2005 patch from Microsoft?

http://support.microsoft.com/kb/943847

[Metaphore]

The problem is on the client, the server is working fine with VSS 6.0.

[Terence]

I'm sorry. I misread your first post. For some reason, I saw VSS 2005 when you actually wrote VS 2005.

Maybe something in this msdn forum thread can be of assistance.

[Metaphore]

That seems to be a different error. It is in a different cpp file and it occurs during get latest. It's solution is to rebind.

My error occurs during bind.

[Terence]

I'm noticing reports of similar occurrences, with slight variations.

http://community.macrovision.com/showth ... p?t=178452

I don't recall ever having seen this problem with SOS before. It's my opinion that one of the Microsoft Tools is the culprit.

Is it possible for you to try and bind with VSS? I'd like to know if this is SOS specific.

[markheth]

This problem happens to me a lot of the time as well on a bind operation with SOS as a client.

Unfortunatly, it makes reconnecting to projects painful, since the only work around I have found is to open it from source control after removing the project from the solution.

[Terence]

Have you tried my suggestion from above? It would be useful to us to know if this also happens with VSS.

[markheth]

No, sorry, I have not. Our database is too large, and VSS is quite slow in our remote location.

Our other office (whom uses VSS), has never seen this problem, so I assumed it was a SOS related issue.

[Terence]

We've been trying for quite a while now to reproduce this without any success.

I know this is a lot to ask, but would it be possible for you to list a step by step account of what you do to get this to happen? It would also be VERY helpful, if you could list the Visual Studio project types as well.

[markheth]

Currently, my projects are all working because I have re-connected them (not using the VS bind ability). All of them are .vcproj files.

Would it be helpfull if the next time it happens, I contact you, and we can try some things, or I can send you project/database files?

[Terence]

Yes that would be very helpful. Thank you very much.

[BrianDrab]

This is a bug in the Source Offsite client. We have resorted to using the Source Safe 2005 client to handle the issue and do the bind when they arrise. A real pain. Following is a specific example that should allow for support fixing the bug. It's reproducible.

We have a Visual Studio 2008 Professional Edition solution with two projects. The solution is under Source Control. We use a strong name key file for one of the projects however we don't like the idea of including the Strong Name Key File with the project. In the future we would have multiple projects containing the same Key File which is not efficient or desirable. So we looked around and found a good article on the .NET Security Blog (http://blogs.msdn.com/shawnfa/archive/2 ... 82278.aspx) that explains how to do this.

It works except for the fact that since the file exists outside the binding root of the project, the SCC bindings are messed up. If you go and unbind the solution and projects from Source Control and then try to Re-bind them you will be unsuccessful.

All of our developers have the following structure:

C:\dev\vss\develop\Visual Basic .NET 2008\Solution1
C:\dev\vss\develop\Visual Basic .NET 2008\Solution1\Project1
C:\dev\vss\develop\Visual Basic .NET 2008\Solution1\Project2


Our corporate Strong Name File is located:

C:\dev\vss\develop\_Documents\Corporate.snk

[jclausius]

Brian:

Can you show provide the VSS folder mappings for the following:

C:\
C:\dev\
C:\dev\vss\
C:\dev\vss\develop\
C:\dev\vss\develop\Visual Basic .NET 2008\
C:\dev\vss\develop\Visual Basic .NET 2008\Solution1
C:\dev\vss\develop\Visual Basic .NET 2008\Solution1\Project1\
C:\dev\vss\develop\Visual Basic .NET 2008\Solution1\Project2\
C:\dev\vss\develop\_Documents\

If C:\dev\vss is set to a common root $/dev/vss, then I *think* this will work. If not, we'll log a bug and fix this as the SOS client should be as close to a VSS client as possible.

Thanks.

[BrianDrab]

Sure.

c:\ (no VSS mapping equivalent)
c:\dev (no VSS mapping equivalent)
c:\dev\vss (no VSS mapping equivalent)
c:\dev\vss\develop (this is the /$ project or the top level within Source Safe)
c:\dev\vss\develop\Visual Basic .NET 2008\ (this is mapped to /$/Visual Basic .NET 2008/ )
c:\dev\vss\develop\Visual Basic .NET 2008\Solution1 (this is mapped to /$/Visual Basic .NET 2008/Solution1)
c:\dev\vss\develop\Visual Basic .NET 2008\Solution1\Project1 (this is mapped to /$/Visual Basic .NET 2008/Solution1/Project1)
c:\dev\vss\develop\Visual Basic .NET 2008\Solution1\Project2 (this is mapped to /$/Visual Basic .NET 2008/Solution1/Project2)
c:\dev\vss\develop\_Documents (this is mapped to /$/_Documents)

Unfortunately it looks like a bug. Let me know how you will proceed. Thank you.