I’m convinced that the SourceSafe support in…

I’m convinced that the SourceSafe support in VS.NET is worse than it was in VS6. Notwithstanding the bug that means that if I’m using a code generation tool and I edit the source file without manually checking out first, then VS.NET ‘forgets’ to check out the underlying generated file and things get messed up, but I’m having problems with basic things.

I have a project that started with the first 32-bit version of Visual C++ (v 1.1?) and MFC2 in about 1993. We gradually ported through the v2 releases, v4 releases, v5 and v6. With VS6, we started using VSS for source control (yes, it was a long time coming). The project has include files drawn from a common folder that different tools share which is above the project folder in the file system. In VS6 this was no problem, presumably just looking at the .scc files to figure out where to look in the SourceSafe database. I moved this project to MFC7/VS.NET several months ago but because the include file folder isn’t below the project home folder it refuses to accept that they might be under source control. The few project specific includes are controled, but if I want to check out/check in the other include files then I have to go through the main SourceSafe .EXE and do it manually (i.e. without integration). This is a real pain.

Today, I’ve been working on putting together the sample projects for my Declarative SQL Server Transactions sample and it includes a deployment project to generate an MSI install. This is all fine - Microsoft obviously expected people to do this because one of the file sets I can choose is “Source Files from XXXX” so that I can install the source files. Now obviously I’ll want to include the solution .sln file so I added that to the deployment project but now SourceSafe gets itself in a mess. It seems to get confused because the .sln file is managed by SourceSafe already. Grrrr.