将 .sln 文件提交到源代码控制中是最佳实践吗？在何时适当或不适当这样做？
更新 回答中提出了几个很好的观点。感谢回应！
是否应该将.sln文件提交到源代码控制？
118
- jlembke
3
15个回答
77
从其他答案中可以清楚地看出，解决方案文件很有用，应该提交，即使它们没有用于正式构建。对于任何使用Visual Studio功能（如转到定义/声明）的人来说，它们都是很方便的。
默认情况下，它们不包含绝对路径或任何其他特定于机器的内容。(不幸的是，一些插件工具不能正确地保持这个属性，例如AMD CodeAnalyst。) 如果你在项目文件(包括C++和C#)中小心使用相对路径，它们也将独立于机器。
也许更有用的问题是: 你应该排除哪些文件? 这是我VS2008项目.gitignore文件的内容:
*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/
（最后一个条目仅针对AMD CodeAnalyst分析器。）
对于VS 2010，您还应该排除以下内容：
ipch/
*.sdf
*.opensdf
- Trevor Robinson
5
2我还有一个忽略单元测试结果的规则。有些人可能会将它们检入，但我不喜欢这种混乱。 - Matthew Whited
11+1 - 我个人也不会提交任何生成的文件，因此 bin/ 和 obj/ 文件夹。 - Steven Evers
我只提交包含多个项目的.sln文件。 - Justin
2这是我的Subversion全局忽略模式：
*.vsmdi *.suo */[Bb]in [Bb]in */obj obj TestResults *.[Uu]ser *Thumbs.db *Web.Publish.xml *WebApplication.Publish.xml *Web.log - Merritt
1这里是一个常见的共享.gitignore文件，其中包括临时文件、构建结果以及流行的Visual Studio插件生成的文件。 - Lauren Rutledge
61
是的--我认为它总是合适的。用户特定设置位于其他文件中。
- Lou Franco
1
3一定地，.sln文件引用了.prj文件（项目）。 - dplante
21
是的，你应该这样做。解决方案文件仅包含有关解决方案的总体结构的信息。该信息对解决方案全局有效，并且可能适用于项目中的所有开发人员。
它不包含任何特定于用户的设置。
- JaredPar
14
你绝对需要它。除了其他人提到的原因外，还需要它来实现整个项目的一步构建。
- Mehrdad Afshari
8
是的，你应该提交以下内容：
- 解决方案(*.sln)文件，
- 项目文件，
- 所有源文件，
- 应用程序配置文件，
- 构建脚本。
不应提交以下内容：
- 解决方案用户选项(.suo)文件，
- 生成的构建文件（例如使用构建脚本生成的）[编辑:] - 仅当所有必要的构建脚本和工具都在版本控制下可用时（以确保构建在cvs历史中是真实的）
关于其他自动生成的文件，请参阅这个线程。
- vgru
11
1我必须不同意“任何自动生成的文件”。 - Mehrdad Afshari
1@Edison：不是的。我指的是自动生成的源文件，比如LINQ到SQL数据上下文。 - Mehrdad Afshari
2Formname.Designer.cs文件不被认为是自动生成的吗？ - jasonh
1我指的是在构建过程中生成的文件。我经常遇到这种情况 - 有人提交了一个自动构建的文件，然后SVN报告了一个变更，只是因为某个注释被修改了。 - vgru
当我使用像SandCastle这样的工具时，我甚至会检查XML注释文件。但是我通常将它们定位到文档目录而不是bin目录。 - Matthew Whited
显示剩余6条评论
8
我通常认为解决方案文件应该被检入，但是在我工作的公司，我们做了一些不同的事情。我们有一个相当大的代码库，开发人员不时地从中不同的部分进行开发。为了支持我们的工作方式，我们要么有一个大的解决方案文件，要么有几个较小的解决方案文件。这两种方法都有一些缺点，并需要开发人员手动处理。为了避免这种情况，我们开发了一个插件来处理所有这些问题。
该插件允许每个开发人员通过从代码库中选择相关项目来检出源代码树的子集以进行开发。插件会生成解决方案文件并即时修改给定解决方案的项目文件。它还处理引用。换句话说，开发人员只需选择适当的项目，然后必要的文件就会被生成/修改。这也允许我们自定义各种设置以确保公司标准。
此外，我们使用插件来支持各种检入策略，通常可以防止用户向代码库提交有问题或不符合规范的代码。
该插件允许每个开发人员通过从代码库中选择相关项目来检出源代码树的子集以进行开发。插件会生成解决方案文件并即时修改给定解决方案的项目文件。它还处理引用。换句话说，开发人员只需选择适当的项目，然后必要的文件就会被生成/修改。这也允许我们自定义各种设置以确保公司标准。
此外，我们使用插件来支持各种检入策略，通常可以防止用户向代码库提交有问题或不符合规范的代码。
- Brian Rasmussen
3
听起来这可能是我长期未解答的问题之一的答案（http://stackoverflow.com/questions/1490728/what-are-the-advantages-of-having-projects-in-the-same-solution-if-you-use-file-r），有没有可能获取此插件的副本？ - Benjol
@Benjol：抱歉，这是一个内部工具。除了上述功能外，它还与许多其他内部系统集成，因此非常特定于我们运行事务的方式。如果您只需要解决方案/项目部分，那么实现起来并不难。 - Brian Rasmussen
好的，只有一件事，在您的“大型解决方案”中，您是否有项目引用或文件引用？如果开发人员添加了新的文件/项目引用，插件是否在检入之前进行适当的转换？还有，您如何处理开发人员没有选择检出的依赖项？ - Benjol
5
是的，它应该是源代码控制的一部分。 每当您添加/删除应用程序中的项目时，.sln文件都会得到更新，并且将其纳入源代码控制是一个不错的选择。这将使您能够直接构建应用程序代码的早期版本（如果需要的话）。
- Arnkrishn
4
在大多数情况下，将 .sln 文件提交到源代码控制是一个好主意。
如果你的 .sln 文件是由其他工具(如 CMake)生成的，则将它们放入源代码控制可能是不合适的。
- Ferruccio
4
是的，您总是希望包括.sln文件，它包含解决方案中所有项目的链接。
- Josh Weatherly
2
我们这么做是因为它可以让所有东西保持同步。所有必要的项目都在一起，没有人需要担心漏掉一个项目。我们的构建服务器（Ant Hill Pro）也使用sln文件来确定发布所需构建的项目。
- kemiller2002
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
.SUO文件。 - apandit