63

I began to use Visual Studio 2010. After I'm done with the C# program, I see that there are .sln, and .suo files in the project root directory, and a .csproj file in the subdirectory. What are those files for?

I need to identify the files to put into a Git repository. Together with the source code/documents that I create, I guess those three files are the only one that I have to take care of. However, I'm not sure if I'm tracking the correct files.

ADDED

How about the personal macro files? I have the Emacs key switch macro, does the .sln file or .csproj file have this macro?

Community
  • 1
  • 1
prosseek
  • 182,215
  • 215
  • 566
  • 871
  • Also see [.gitignore for Visual Studio Projects and Solutions](http://stackoverflow.com/questions/2143956/gitignore-for-visual-studio-projects-and-solutions) – alldayremix Aug 21 '13 at 14:33
  • possible duplicate of [Should I add the Visual Studio .suo and .user files to source control](http://stackoverflow.com/questions/72298/should-i-add-the-visual-studio-suo-and-user-files-to-source-control) – childno͡.de Mar 20 '14 at 06:53

5 Answers5

75

You should commit the .sln and the .csproj, but not the .suo or the .user files.

You can add the following to .gitignore:

#ignore thumbnails created by windows
Thumbs.db
#Ignore files build by Visual Studio
*.obj
*.exe
*.pdb
*.user
*.aps
*.pch
*.vspscc
*_i.c
*_p.c
*.ncb
*.suo
*.tlb
*.tlh
*.bak
*.cache
*.ilk
*.log
[Bb]in
[Dd]ebug*/
*.lib
*.sbr
obj/
[Rr]elease*/
_ReSharper*/
[Tt]est[Rr]esult*
SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • 5
    If you want to share the debugging/command line args then the .user file is useful to put in version control – Tim Oct 06 '10 at 15:00
  • 6
    @Tim: I would disagree - by default, the .user file will register fully qualified paths, which will often not be valid across developers. However, you can register shared debug settings in the .csproj file by copying the relevant lines from the .user file to the .csproj file. – Jean Hominal Jul 25 '13 at 07:50
  • 2
    I didn't realize those were full paths. That is unfortunate. MS screwed up there for sure. Your solution is better. upvoted your comment. – Tim Jul 25 '13 at 19:37
  • Important note: This will not work unless you add `syntax: glob` to the first line! – DJMcMayhem Jul 25 '16 at 17:41
  • 2
    This answer just provides a "what", without providing any understanding or "why". – Orangutech Jan 10 '20 at 23:49
44

SLN (Solution) are the solution files. It stores info about the collection of projects that make up whatever you are developing. They contain projects, source control settings, or any other global level thing.

CSProj(Project file) are the actual code projects (C# Libraries, WCF Services, etc). It stores information at the project level. It wraps all relevant References, Classess, etc..

SUO (solution user options) are user settings files. Completely disposable, you can delete it and the most common thing you will lose are breakpoints.

Push everything except the SUO settings files.

Do not include any bin, debug, obj directory. The only DLLs (or compiled/generated object) you should include are those that are external to your application.

Nix
  • 57,072
  • 29
  • 149
  • 198
  • 1
    The `.sln` files contain developer-specific information such as the Visual Studio version that they are running. Is it possible to avoid committing this? Otherwise we get noise diffs whenever devs on different versions commit something. – Jean Jordaan Feb 26 '16 at 07:55
15

From MSDN:

A solution (.sln) is a structure for organizing projects in Visual Studio. It performs a function similar to Windows Program Group (.vbg) files in Visual Basic 6.0 and project workspace (.dsw) files in Visual C++ 6.0. The solution maintains the state information for projects in .sln (text-based, shared) and .suo (binary, user-specific solution options) files … [Source]

Furthermore, also from MSDN:

The solution user options (.suo) file is a structured storage, or compound, file stored in a binary format. You save user information into streams with the name of the stream being the key that will be used to identify the information in the .suo file … [Source]

You do not need to put .suo file in VCS. That is a user-specific file.

Dr1Ku
  • 2,875
  • 3
  • 47
  • 56
3

The SUO files do have a purpose and I disagree with the statement that they should always be ignored. I do not ignore them, and as a general practice I add them to our SVN repository. My projects are not always using the solution defaults for Startup Project or platform. I find it annoying that if I grab a new project it does not default to 64 bit and the proper platform. The SUO contains the settings to set these defaults properly.

The down side of this is that it's a binary file, so pretty much each time you open the solution and do anything the file will have changed. Typically the file is less than 100k, and unless you know you changed something, I don't commit the change.

Brian S
  • 3,096
  • 37
  • 55
  • 3
    To add to the comment. If you are working with more than 1 person, you do want to be careful. When working with a team, there needs to be some care that an initial version is checked in to get the desired defaults to start with, but as a developer I don't ever check my version in. – Brian S Aug 28 '13 at 20:13
0

In my case, I deleted all the "bin" and "obj" folder inside of my solution and projects

Vítor Oliveira
  • 1,851
  • 18
  • 23