File Handling by Source Control

What are the files that needs to be check in VSS for better handling of files when we do development. There are many file types and are stored and updated internally for each developer based on their own settings. So in other words these files doesn’t need to be part of Source control system. Here are the list of file types that we might need to look in as developer

You can add the following files to Visual Studio source control:

• Solution files (*.sln).

• Project files, for example, *.csproj, *.vbproj files.

• Application configuration files, based on XML, used to control run-time behavior of a Visual Studio project.

But the Files that you cannot add to source control include the following:

• Solution user option files (*.suo).

• Project user option files, for example, *.csproj.user, *.vbproj.user files.

• Web information files, for example, *.csproj.webinfo, *.vbproj.webinfo, that control the virtual root location of a Web project.

• Build output files, for example, *.dll and *.exe files.

For more information

How to: Remove working folders -Visual SourceSafe

Setting a working folder for a VSS project is pretty standard practice. You set it, and you expect it to cascade down to the project's files and sub-projects.
If a sub-project has a working folder defined that differs from the cascaded one, then this takes priority for that sub-project and anything further down that branch of the tree.
Suppose you want to remove a sub-project's working folder, so it falls in line with the working folder cascaded down from the top level project. You would probably delete the path in the VSS dialog, and the working folders would then be consistent with the SourceSafe database tree.

Working folders are stored on a per user, per project, per machine basis. They are stored in the <VSSDB>\users\<user>\ folder, in a file called ss.ini.
Open this file in a text editor. In VSS, set a project's working folder and over-ride the cascading by setting a sub-project's working folder as well. Close VSS so that the changes to the ss.ini file are saved.
In the ss.ini file you'll notice some new lines at the end, looking something like this:

[$/IssueTracker/IssueTrackerUI]

Dir (PRINCE) = c:\inetpub\wwwroot\IssueTrackerUI

[$/IssueTracker/IssueTracker]

Dir (PRINCE) = D:\IssueTracker

[$/IssueTracker/IssueTracker/IssueTrackerBase]

Dir (PRINCE) = D:\IssueTracker\IssueTrackerBase

[$/IssueTracker/IssueTracker/IssueTrackerData]

Dir (PRINCE) = D:\IssueTracker\IssueTrackerData

[$/IssueTracker/IssueTracker/IssueTrackerService]

Dir (PRINCE) = D:\IssueTracker\IssueTrackerService

According to the documentation on VSS, it is possible to programatically change the working folder for a project in VSS using the LocalSpec property of the IVSSItem interface.

Rather than writing an app using the VSS API, I ended up removing the lines for the working folders I wanted to remove.

It worked for me…Good luck.