Should a .sln be committed to source control?

问题:

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!

回答1:

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

回答2:

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

回答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.

回答4:

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

回答5:

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.

回答6:

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.

回答7:

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

回答8:

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

回答9:

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.

回答10:

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.

回答11:

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.

回答12:

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.

回答13:

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

回答14:

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.

回答15:

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

回答16:

1) Create a new project in VS
2) Right click on the solution in Solution Explorer, select Add to Source Control

Is the sln added to source control? That's your answer.