10

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.

Rick Liddle
  • 2,684
  • 19
  • 31
Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • 3
    I would keep the Bin Folder. sometimes that holds Referenced .dll files – Malachi Sep 14 '12 at 16:09
  • 1
    How about a workspace cleaner like this: http://www.codeproject.com/Articles/10855/Clean-Visual-Studio-Workspaces – drescherjm Sep 14 '12 at 16:13
  • 1
    Although when I look at that the application in the previous link appears to be too old to handle a lot of the .NET temporary files. – drescherjm Sep 14 '12 at 16:19
  • 1
    I have tried a few of these "workspace cleaners" and they seem to be very buggy and dangerous. I was thinking that some sort of "preview feature" might be needed. Perhaps it is a new feature for CCleaner? – Stein Åsmul Sep 14 '12 at 16:19
  • I avoid this issue for my Qt builds on windows/ Visual Studio by using out of source building with CMake however I realize that is not going to work well with .NET – drescherjm Sep 14 '12 at 16:22
  • 2
    @Malione When you "Clean" a project the bin folder gets emptied so you should not depend on references being cached there. I prefer to make hard-copies of referenced DLLs in a folder called "_References". I recommend this to other people too. – Dai Sep 14 '12 at 16:30

2 Answers2

16

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).

Dai
  • 141,631
  • 28
  • 261
  • 374
  • 2
    Great info. I am aware that these files actually are value-added, but when they are generated automatically they are not "source files" in my opinion. That's why I want them all gone before going into source control or starting a large shuffle to get things organized into a new struture. The same way I don't check output binaries into source control, but keep them in a build area on disk. – Stein Åsmul Sep 14 '12 at 16:40
  • 1
    That's not necessary. VS automatically excludes output files from source control. In fact VS automatically excludes things like intellisense caches from source-control anyway. – Dai Sep 14 '12 at 16:52
  • 1
    My project has been slow and showing incorrect intellisense data (errors where there aren't any, etc). I wanted to find a way to wipe out temporary data. While the information Day provided was nice to know, at the end of the day I disagree with his assessment that they shouldn't be deleted in general and appreciate the information he provided as a good way to delete these files. I don't care if building takes a little bit longer, if I can help ensure things come out clean on the far side. – omJohn8372 Mar 14 '18 at 18:05
10

Have a look at the folders and extensions listed in the answers to this Visual Studio .gitignore question for an idea of the files that are commonly considered non-essential.

However, it is generally speaking not a good idea to delete stuff if you don't know what it is. For example, .sdf files may be SQL Server CE databases, which might be important in some projects. So make sure you make a backup somewhere before running any solution cleaner scripts.

Community
  • 1
  • 1
Mark Heath
  • 48,273
  • 29
  • 137
  • 194