106

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 points made in the answers. Thanks for the responses!

jlembke
  • 12,044
  • 10
  • 40
  • 56
  • 21
    I believe it's the .SUO file you DON'T want to commit. – apandit Jun 23 '09 at 17:27
  • Just for the record, I believe that Task lists (if you use them) are stored in the .SUO file... So though you may not want to commit them to source control, you might not want to 'just delete' them as extraneous cruft. – Benjol Apr 26 '10 at 08:51

15 Answers15

71

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
Trevor Robinson
  • 13,611
  • 5
  • 64
  • 66
  • 2
    I also have an ignore rule for Unit test results. Some people might check them in but I don't like the clutter – Matthew Whited Jun 23 '09 at 19:47
  • 9
    +1 - I personally also don't commit anything that gets built, thus bin/ and obj/ – Steven Evers Jun 23 '09 at 19:56
  • I only commit .sln files that contain more than 1 project – Justin Jul 07 '09 at 14:45
  • 2
    here is my subversion Global ignore patter: *.vsmdi *.suo */[Bb]in [Bb]in */obj obj TestResults *.[Uu]ser *Thumbs.db *Web.Publish.xml *WebApplication.Publish.xml *Web.log – Merritt Aug 28 '09 at 16:33
  • [Here](https://github.com/github/gitignore/blob/master/VisualStudio.gitignore) is a commonly shared .gitignore file that includes temporary files, build results, and files generated by popular Visual Studio add-ons. – Lauren Van Sloun Oct 09 '18 at 17:36
58

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

Lou Franco
  • 83,503
  • 14
  • 127
  • 183
20

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.

JaredPar
  • 673,544
  • 139
  • 1,186
  • 1,421
13

You should definitely have it. Beside the reasons other people mentioned, it's needed to make one step build of the whole projects possible.

mmx
  • 390,062
  • 84
  • 829
  • 778
8

Yes, things you should commit are:

  • solution (*.sln),
  • project files,
  • all source files,
  • app config files
  • build scripts

Things you should not commit are:

  • solution user options (.suo) files,
  • build generated files (e.g. using a build script) [Edit:] - only if all necessary build scripts and tools are available under version control (to ensure builds are authentic in cvs history)

Regarding other automatically generated files, there is a separate thread.

Community
  • 1
  • 1
Groo
  • 45,930
  • 15
  • 109
  • 179
  • 1
    I have to disagree with "any automatically generated file." – mmx Jun 23 '09 at 17:01
  • @Mehrdad do you think the Intelisense files should be commited too? – Edison Gustavo Muenz Jun 23 '09 at 17:04
  • 1
    @Edison: Nope. I'm referring to auto generated source files like LINQ to SQL data context, for instance. – mmx Jun 23 '09 at 17:06
  • http://stackoverflow.com/questions/893913/should-i-store-generated-code-in-source-control – mmx Jun 23 '09 at 17:08
  • 2
    Aren't Formname.Designer.cs files considered automatically generated? – jasonh Jun 23 '09 at 17:12
  • Perhaps he means "build generated files". For example, with Qt, you should not commit the moc generated source files. – sean e Jun 23 '09 at 17:20
  • Likewise there are some source files generated by the midl compiler that generally should not be committed. The input files should be committed, but the output files, not. – sean e Jun 23 '09 at 17:22
  • 1
    What I meant were files generated during build time. I find this often - someone commits a file which is built automatically, and then SVN reports a change just because some comment was changed. – Groo Jun 23 '09 at 17:27
  • When I work with tools such as SandCastle I even check in the XML comment files. But I normally target these to a document directory instead of the bin. – Matthew Whited Jun 23 '09 at 19:42
  • Sometimes it makes sense to commit generated files, for instance when they take a long time to generate. – Makach Jun 28 '09 at 10:49
  • @Makach - good point, we did find this annoying, but then we changed tools to act differently depending of the build configuration. To speed up Debug builds, tool only rebuilds files if necessary (e.g. only if they don't exist, on depending on the specific rule for that file). This also speeds up overall build because VS doesn't have to rebuild assemblies where no files have been changed. In Release build config, we always rebuild them. The simplest case (in debug mode, rebuild only if file doesn't exist) is pretty simple to implement. – Groo Jun 28 '09 at 11:47
8

I generally agree that solution files should be checked in, however, at the company I work for we have done something different. We have a fairly large repository and developers work on different parts of the system from time to time. To support the way we work we would either have one big solution file or several smaller. Both of these have a few shortcomings and require manual work on the developers part. To avoid this, we have made a plug-in that handles all that.

The plug-in let each developer check out a subset of the source tree to work on simply by selecting the relevant projects from the repository. The plugin then generates a solution file and modifies project files on the fly for the given solution. It also handles references. In other words, all the developer has to do is to select the appropriate projects and then the necessary files are generated/modified. This also allows us to customize various other settings to ensure company standards.

Additionally we use the plug-in to support various check-in policies, which generally prevents users from submitting faulty/non-compliant code to the repository.

Brian Rasmussen
  • 109,816
  • 33
  • 208
  • 305
  • Sounds like this might be the answer to one of my long-unanswered questions (http://stackoverflow.com/questions/1490728/what-are-the-advantages-of-having-projects-in-the-same-solution-if-you-use-file-r), any chance of getting hold of a copy of this plugin? – Benjol Apr 26 '10 at 08:46
  • @Benjol: Sorry, no it is an internal tool. In addition to the features above it also integrates with a number of other internal systems, so it is very specific to how we run things. If you only need the solution/project part of things it is not that hard to implement. – Brian Rasmussen Apr 26 '10 at 10:15
  • OK, just one thing, in your 'big solution' do you have project references or file references? And if a developer adds a new reference to a file/project, does the plugin do the appropriate conversion back before checking in? And how do you handle the dependencies which the developer hasn't chosen to checkout? – Benjol Apr 27 '10 at 05:12
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).

Arnkrishn
  • 27,376
  • 39
  • 108
  • 127
4

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

Josh Weatherly
  • 1,628
  • 1
  • 13
  • 27
4

Under most circumstances, it's a good idea to commit .sln files to source control.

If your .sln files are generated by another tool (such as CMake) then it's probably inappropriate to put them into source control.

Ferruccio
  • 93,779
  • 37
  • 217
  • 294
2

We do because it keeps everything in sync. All the necessary projects are located together, and no one has to worry about missing one. Our build server (Ant Hill Pro) also uses the sln to figure which projects to build for a release.

kemiller2002
  • 107,653
  • 27
  • 187
  • 244
2

We usually put all of our solutions files in a solutions directory. This way we separate the solution from the code a little bit, and it's easier to pick out the project I need to work on.

MayorAwesome
  • 221
  • 4
  • 15
1

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.

Joe
  • 114,633
  • 27
  • 187
  • 321
1

Yes - Everything used to generate your product should be in source control.

Michael
  • 51,314
  • 5
  • 111
  • 139
1

We keep or solution files in TFS Version Control. But since or main solution is really large, most developers have a personal solution containing only what they need. The main solution file is mostly used by the build server.

Sylvain Rodrigue
  • 4,408
  • 4
  • 46
  • 58
0

.slns are the only thing we haven't had problems with in tfs!

Code Silverback
  • 3,134
  • 5
  • 29
  • 39
  • 1
    That's funny... SLNs were the only files I have ever had to fix... but the problems were caused by devs not being careful with merges. – Matthew Whited Jun 23 '09 at 19:44