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

【问题标题】：Should a .sln be committed to source control?.sln 是否应该致力于源代码控制？
【发布时间】：2010-11-05 06:00:34
【问题描述】：

将 .sln 文件提交到源代码管理是否是最佳做法？什么时候这样做合适或不合适？

更新答案中有几个很好的观点。感谢您的回复！

【问题讨论】：

我相信这是您不想提交的 .SUO 文件。
只是为了记录，我相信任务列表（如果你使用它们）存储在 .SUO 文件中......所以虽然你可能不想将它们提交到源代码控制，但你可能不会想将它们“删除”为无关紧要的东西。
我对这个gitignore很满意。

标签： visual-studio visual-studio-2008 version-control projects-and-solutions

【解决方案1】：

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

默认情况下，它们不包含绝对路径或任何其他特定于机器的工件。（不幸的是，一些插件工具没有正确维护这个属性，例如 AMD CodeAnalyst。）如果你小心地在项目文件（C++ 和 C#）中使用相对路径，它们将与机器无关也是。

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

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

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

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

ipch/
*.sdf
*.opensdf

【讨论】：

我还有一个忽略单元测试结果的规则。有些人可能会检查他们，但我不喜欢混乱
+1 - 我个人也不提交任何构建的东西，因此 bin/ 和 obj/
我只提交包含超过 1 个项目的 .sln 文件
这是我的颠覆全局忽略模式：*.vsmdi *.suo */[Bb]in [Bb]in */obj obj TestResults *.[Uu]ser *Thumbs.db *Web。 Publish.xml *WebApplication.Publish.xml *Web.log
Here 是一个常用共享的 .gitignore 文件，其中包括临时文件、构建结果以及由流行的 Visual Studio 插件生成的文件。

【解决方案2】：

是的——我认为它总是合适的。用户特定的设置在其他文件中。

【讨论】：

肯定是 .sln 引用了 .prj 文件（项目）

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

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

插件让每个开发人员只需从存储库中选择相关项目即可检查源代码树的子集以进行工作。然后插件生成一个解决方案文件并为给定的解决方案动态修改项目文件。它还处理引用。换句话说，开发人员所要做的就是选择合适的项目，然后生成/修改必要的文件。这也使我们能够自定义各种其他设置以确保公司标准。

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

【讨论】：

听起来这可能是我长期悬而未决的问题之一 (stackoverflow.com/questions/1490728/…) 的答案，是否有机会获得此插件的副本？
@Benjol：抱歉，不，它是一个内部工具。除了上述功能之外，它还与许多其他内部系统集成，因此它对我们如何运行事物非常具体。如果您只需要解决方案/项目的一部分，那么实施起来并不难。
好的，只有一件事，在您的“大解决方案”中，您有项目引用或文件引用吗？如果开发人员添加了对文件/项目的新引用，插件是否会在签入之前进行适当的转换？以及如何处理开发人员未选择签出的依赖项？

【解决方案6】：

是的，你应该提交的事情是：

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

你应该不提交的事情是：

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

关于其他自动生成的文件，有separate thread。

【讨论】：

我不同意“任何自动生成的文件”。
@Mehrdad 你认为 Intelisense 文件也应该提交吗？
@Edison：不。例如，我指的是自动生成的源文件，例如 LINQ to SQL 数据上下文。
Formname.Designer.cs 文件不是自动生成的吗？
我的意思是在构建期间生成的文件。我经常发现这种情况——有人提交了一个自动构建的文件，然后 SVN 仅仅因为某些评论被更改而报告了一个更改。

【解决方案7】：

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

【讨论】：

【解决方案8】：

是的，您总是希望包含 .sln 文件，它包含指向解决方案中所有项目的链接。

【讨论】：

【解决方案9】：

在大多数情况下，最好将 .sln 文件提交到源代码管理。

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

【讨论】：

【解决方案10】：

我们这样做是因为它使所有内容保持同步。所有必要的项目都集中在一起，没有人担心错过一个。我们的构建服务器（Ant Hill Pro）也使用 sln 来确定要为发布构建哪些项目。

【讨论】：

【解决方案11】：

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

【讨论】：

【解决方案12】：

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

【讨论】：

【解决方案13】：

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

【讨论】：

【解决方案14】：

我们在 TFS 版本控制中保留或解决文件。但由于 or main 解决方案非常大，大多数开发人员都有一个只包含他们需要的个人解决方案。主要解决方案文件主要由构建服务器使用。

【讨论】：

【解决方案15】：

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

【讨论】：

这很有趣...... SLN 是我必须修复的唯一文件......但问题是由于开发人员不小心合并造成的。