It seems like the following type of files need to be writable to be able to compile a solution.
.exe
.dll
.pdb (if debugging)
.resource (?)
.xml (at least the system generated ones. I'm not sure if they are just all XML documentationf iles)
If they were checked in and could only be overwritten by the compiler by the person who had them checked out, then checking them into sourcesafe and requiring a checkout to modify them, which is attemtped by the compiler each time you run, would interfer with other developer's ability to debug and run.
What is the best practice? It seems like VSS automatically adds everything.
Normally, you don't want to check in any files that are generated, unless you generate them a single time, then "cut-and-run" with the files from there (i.e. you never regenerate them). This is especially true for version control systems like VSS that use a single-checkout lock.
If you want to version generated files, I would suggest not versioning them in the solution/project locations, but have a separate process that copies them somewhere else, and checks them in there. If you version generated files within a sln/proj, you'll have nightmares fighting with people to check them out and back in.
I believe you can set VSS to not do an exclusive lock on checkouts, but in general, I'd stay away from checking in generated files. You should try to get your system to the point where if you need to go back to a previous version of a generated file, you checkout the appropriate version/tag of the "source" files and re-genenerate the other files from there.
In general files that are created as part of the build process are not checked into version control.
However, you very well might want to archive all or some of these files (maybe at specific milestones, and in particular if you release them outside of your dev organization) in case you need to deal with problem reports/bugs found in testing or by end users.
Whether you want that archiving to occur in the same depot (or even using the same version control software) as your source artifacts is a different decision. often an archive of this sort isn't really a version control system, but might be a network share that has directories that follow a particular naming convention so the those artifacts can be matched to a particular revision of the source. How the lifetime of those items are managed (and what the lifetime should be) is another issue that needs to be determined by the needs and policies of your particular organization.
Visual Studio does a good job of selecting the right items to be added to source safe. Use the commands from project context menu or from the file menu when setting up a new project.
A common mistake is to add the folder from VSS.
