.sln是否应该致力于源代码控制？

将.sln文件提交到源代码管理是最佳实践吗？什么时候合适或不合适？

更新 答案中有几点要点。感谢您的回复！

我认为从其他答案中可以明显看出，即使未将解决方案文件用于官方构建，它们也应该提交。对于使用诸如转到定义/声明之类的Visual Studio功能的任何人来说，它们都很方便。

默认情况下，它们不包含绝对路径或任何其他特定于机器的工件。（不幸的是，某些加载项工具无法正确维护此属性，例如AMD CodeAnalyst。）如果您谨慎使用项目文件中的相对路径（C ++和C＃），它们将与计算机无关太。

可能更有用的问题是：您应该排除哪些文件？这是我的VS 2008项目的.gitignore文件的内容：

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

（最后一个条目仅用于AMD CodeAnalyst分析器。）

对于VS 2010，还应该排除以下内容：

ipch/
*.sdf
*.opensdf

是的-我认为这总是合适的。用户特定的设置位于其他文件中。

是的，您应该这样做。解决方案文件仅包含有关解决方案总体结构的信息。该信息是解决方案的全局信息，可能对您项目中的所有开发人员都是通用的。

它不包含任何用户特定的设置。

你绝对应该拥有它。除了其他人提到的原因之外，还需要使整个项目的一步构建成为可能。

我通常同意应签入解决方案文件，但是在我工作的公司，我们做了一些不同的事情。我们有一个相当大的存储库，开发人员会不时在系统的不同部分上工作。为了支持我们的工作方式，我们将拥有一个大解决方案文件或多个小解决方案文件。两者都有一些缺点，需要开发人员进行手动操作。为了避免这种情况，我们制作了一个插件来处理所有这些问题。

通过该插件，每个开发人员只需从存储库中选择相关项目，即可签出要处理的源树子集。然后，插件会生成解决方案文件，并针对给定的解决方案即时修改项目文件。它还处理引用。换句话说，开发人员要做的就是选择适当的项目，然后生成/修改必要的文件。这也使我们能够自定义各种其他设置以确保公司标准。

另外，我们使用该插件来支持各种签入策略，这通常可以防止用户向存储库提交错误/不合规的代码。

是的，您应该提交的内容是：

• 解决方案（* .sln），
• 项目文件，
• 所有源文件
• 应用程序配置文件
• 构建脚本

你应该事不承诺是：

• 解决方案用户选项（.suo）文件，
• 构建生成的文件（例如，使用构建脚本）[编辑：] -仅在版本控制下所有必需的构建脚本和工具均可用时（以确保构建在cvs历史记录中是真实的）

关于其他自动生成的文件，有一个单独的线程。

是的，它应该是源代码管理的一部分。每当您从应用程序中添加/删除项目时，.sln都会得到更新，最好在源代码控制下进行。它将允许您拉回应用程序代码2版本并直接进行构建（如果需要的话）。

在大多数情况下，将.sln文件提交到源代码管理是一个好主意。

如果您的.sln文件是由其他工具（例如CMake）生成的，那么将它们放入源代码管理中可能是不合适的。

是的，您始终希望包含.sln文件，该文件包含解决方案中所有项目的链接。

我们这样做是因为它使所有内容保持同步。所有必要的项目都放在一起，并且没有人会担心丢失一个项目。我们的构建服务器（Ant Hill Pro）也使用sln来确定要为发行版本构建的项目。

通常，我们将所有解决方案文件都放在一个解决方案目录中。这样，我们就将解决方案与代码分离了一点，并且更容易挑选出我需要处理的项目。

甚至不考虑将其存储在源代码管理中的唯一情况是，如果您有一个大型解决方案，其中包含处于源代码管理中的许多项目，并且您想从主解决方案中的一些项目中创建一些小型解决方案私人暂态要求。

是的-用于生成产品的所有内容都应在源代码管理中。

我们将文件或解决方案文件保留在TFS版本控制中。但是由于主解决方案确实很大，所以大多数开发人员都有一个仅包含他们所需内容的个人解决方案。主要解决方案文件主要由构建服务器使用。

.slns是我们在tfs中没有遇到的唯一问题！