Question

I am cleaning up a bunch of visual studio projects / solutions from different sources, and there are an incredible amount of temporary files and temporary folders stored in each solution.

I am wondering what file types are safe to delete so that I can write a script to take care of the heavy lifting so there is less junk to push around when I am trying to get the whole folder structure organized and linked up to the proper shared file locations.

As far as I can see the following files and folders are temporary and can be safely deleted:

Files

• *.sdf
• *.sln.docstates
• *.suo
• *.upgradelogxml
• *.user
• *.vcxproj.filters
• *.sln.old
• *.suo.old
• UpgradeLog.XML
• *.wixproj.vspscc
• *.csproj.vspscc
• *.SCC
• *.ncb
• *.opt
• *.plg
• *.aps
• *.clw

Folders

• _UpgradeReport_Files (folder)
• ipch (folder)
• bin, obj, debug, release and other build output folders though there could be files copied into here during build…
• Backup, Backup1, etc…

I am not even sure what some of these file types really are, I just know they are re-generated when you open the solution – and I know there are many more file types that I have missed from older and newer versions of Visual Studio.

Are there any file types that should be preserved in the list above? If so, for what reason, and are there further file types that can be cleaned out without any serious side effects?

The overall idea is to minimize the size and complexity of the solution when it is to be migrated, moved or reorganized or otherwise shuffled around enough for this “solution fat” to be a serious performance and management problem.

Typically I see this problem if I need to check something into a new source control system, zip and send sample code by email or put third party or peer code into an existing hierarchy of shared folders and files.

Answer 1

I disagree with your list of "temporary" files – certainly very few of them are temporary in nature (otherwise they’d be in the %TEMP% directory). Granted, most of them are not necessary for your project to build successfully, but they are still important.

• *.sdf – SQL Server Compact database. Used by VS2012 to store VC intellisense data. Without this file you will not get intellisense and code-completion until it rebuilds.
• sln.docstates – Stores temporary state information about files in your solution.
• suo – Contains information about your per-solution IDE customization settings, such as window layout and toolbox loadout. It’s generally safe to delete this but your solution might take longer to load in future and you’ll lose any UI customizations.
• upgradelog.xml – Yeah, the upgrade-log files are a bit of a mess. This can be deleted.
• user – I’m sure this is an old file from VC6 days…
• vcxproj.filters – Keep this, it’s a per-computer/per-project filesystem organisation list thingie
• sln.old and suo.old – No official tooling in VS that I’m aware-of renames any files’ filename extensions to .old, this is likely a manual backup copy made by-hand.
• *.wixproj.vspscc, *.csproj.vspscc, or any .vspscc files and *.scc files – these files are associated with older, (non-git), source-control systems used by VS, namely TFS (and I think SourceSafe too at one point?). These files should not be deleted as they’re used to store (non-git) source-control configuration info and it’s painful trying to re-integrate unchecked changes back into source-control after deleting binding files. Only delete this if you’re not using source control – or have fully switched to git.
• *.ncb – Intellisense cache used in VC6 through 2010. If you delete this you’ll lose VC intellisense until the IDE has rebuilt it, which can take aaaggess on large projects.

The other file-extensions are not used by Visual Studio by-default, such as the ones listed .opt, .plg, .aps, .clw – though .opt seems to be a Linker input file for TI’s Code Composer Studio, so as the OP seems to have project/workspace/config files for other IDEs in their project’s folder then it’s likely those files are specific to those other IDEs, in which case I can’t say if they’re temporary or not.

---

Of course, the trick is to properly arrange your files in your solution in the first place. Project source files should be kept separate from project metadata (i.e. the files I just listed above), ideally in separate folders in their own heirarchy (that way you can have multiple VC project files for the same source code, allowing contributors to use VC2005, 2008, and 2010 at the same time).