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.