visual-studio .sln 应该致力于源代码控制吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1033809/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Should a .sln be committed to source control?
提问by jlembke
Is it a best practice to commit a .sln file to source control? When is it appropriate or inappropriate to do so?
将 .sln 文件提交到源代码管理是最佳实践吗？什么时候这样做合适或不合适？
UpdateThere were several good points made in the answers. Thanks for the responses!
更新答案中有几个很好的观点。感谢您的回复！
采纳答案by Trevor Robinson
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.
我认为从其他答案中可以清楚地看出，解决方案文件很有用并且应该提交，即使它们不用于官方构建。对于使用 Go To Definition/Declaration 等 Visual Studio 功能的任何人来说，它们都很方便。
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.
默认情况下，它们不包含绝对路径或任何其他特定于机器的工件。（不幸的是，一些插件工具没有正确维护此属性，例如 AMD CodeAnalyst。）如果您在项目文件（C++ 和 C#）中小心使用相对路径，它们将独立于机器也。
Probably the more useful question is: what files should you exclude? Here's the content of my .gitignore file for my VS 2008 projects:
可能更有用的问题是：您应该排除哪些文件？这是我的 VS 2008 项目的 .gitignore 文件的内容：
*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/
(The last entry is just for the AMD CodeAnalyst profiler.)
（最后一个条目仅适用于 AMD CodeAnalyst 分析器。）
For VS 2010, you should also exclude the following:
对于 VS 2010，您还应该排除以下内容：
ipch/
*.sdf
*.opensdf
回答by Lou Franco
Yes -- I think it's always appropriate. User specific settings are in other files.
是的 - 我认为这总是合适的。用户特定的设置在其他文件中。
回答by JaredPar
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.
它不包含任何用户特定的设置。
回答by Mehrdad Afshari
You should definitely have it. Beside the reasons other people mentioned, it's needed to make one step build of the whole projects possible.
你绝对应该拥有它。除了其他人提到的原因之外，还需要使整个项目的一步构建成为可能。
回答by Groo
Yes, things you should commit are:
是的，您应该提交的内容是：
- solution (*.sln),
- project files,
- all source files,
- app config files
- build scripts
- 解决方案 (*.sln),
- 项目文件，
- 所有源文件，
- 应用配置文件
- 构建脚本
Things you should notcommit 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)
- 解决方案用户选项 (.suo) 文件，
- 构建生成的文件（例如使用构建脚本）[编辑：]- 仅当所有必要的构建脚本和工具在版本控制下可用（以确保构建在 cvs 历史记录中是真实的）
Regarding other automatically generated files, there is a separate thread.
关于其他自动生成的文件，有单独的线程。
回答by Brian Rasmussen
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.
此外，我们使用插件来支持各种签入策略，这通常可以防止用户向存储库提交错误/不合规的代码。
回答by Arnkrishn
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).
是的，它应该是源代码管理的一部分。每当您从应用程序中添加/删除项目时，.sln 都会更新，最好将其置于源代码控制之下。它将允许您将应用程序代码 2 版本拉回并直接进行构建（如果需要的话）。
回答by Ferruccio
Under most circumstances, it's a good idea to commit .sln files to source control.
在大多数情况下，将 .sln 文件提交给源代码管理是个好主意。
If your .sln files are generated by another tool (such as CMake) then it's probably inappropriate to put them into source control.
如果您的 .sln 文件是由其他工具（例如 CMake）生成的，那么将它们放入源代码管理中可能是不合适的。
回答by Josh Weatherly
Yes, you always want to include the .sln file, it includes the links to all the projects that are in the solution.
是的，您总是希望包含 .sln 文件，它包含指向解决方案中所有项目的链接。
回答by kemiller2002
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.
我们这样做是因为它使一切保持同步。所有必要的项目都集中在一起，谁也不用担心错过一个。我们的构建服务器（Ant Hill Pro）也使用 sln 来确定为发布构建哪些项目。
