Should a .sln be committed to source control?

Question

Is it a best practice to commit a .sln file to source control? When is it appropriate or inappropriate to do so?

Update There were several good poin

Answer 1

Yes, you always want to include the .sln file, it includes the links to all the projects that are in the solution.

Answer 2

The only case where you would even considder not storing it in source control would be if you had a large solution with many projects which was in source control, and you wanted to create a small solution with some of the projects from the main solution for some private transient requirement.

Answer 3

Yes you should do this. A solution file contains only information about the overall structure of your solution. The information is global to the solution and is likely common to all developers in your project.

It doesn't contain any user specific settings.

Answer 4

I think it's clear from the other answers that solution files are useful and should be committed, even if they're not used for official builds. They're handy to have for anyone using Visual Studio features like Go To Definition/Declaration.

By default, they don't contain absolute paths or any other machine-specific artifacts. (Unfortunately, some add-in tools don't properly maintain this property, for instance, AMD CodeAnalyst.) If you're careful to use relative paths in your project files (both C++ and C#), they'll be machine-independent too.

Probably the more useful question is: what files should you exclude? Here's the content of my .gitignore file for my VS 2008 projects:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(The last entry is just for the AMD CodeAnalyst profiler.)

For VS 2010, you should also exclude the following:

ipch/
*.sdf
*.opensdf

Answer 5

Yes, it should be part of the source control. When ever you add/remove projects from your application, .sln would get updated and it would be good to have it under source control. It would allow you to pull out your application code 2 versions back and directly do a build (if at all required).

Answer 6

Yes -- I think it's always appropriate. User specific settings are in other files.