将.sln文件提交给源代码管理是最佳做法吗？什么时候适当或不恰当？
更新 答案中有几个好点。感谢您的回复！
答案 0 :(得分：67)
我认为从其他答案中可以清楚地看出，解决方案文件很有用并且应该提交，即使它们不用于官方构建。对于任何使用“转到定义/声明”等Visual Studio功能的人来说，它们都很方便。
默认情况下，它们不包含绝对路径或任何其他特定于计算机的工件。 （遗憾的是，某些加载项工具无法正确维护此属性，例如AMD CodeAnalyst。）如果您在项目文件中使用相对路径（包括C ++和C＃），它们将与机器无关太
可能更有用的问题是：您应该排除哪些文件？这是我的VS 2008项目的.gitignore文件的内容：
*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/
（最后一个条目仅适用于AMD CodeAnalyst分析器。）
对于VS 2010，您还应排除以下内容：
ipch/
*.sdf
*.opensdf
答案 1 :(得分：58)
是的 - 我认为这总是合适的。用户特定设置在其他文件中。
答案 2 :(得分：20)
是的，你应该这样做。解决方案文件仅包含有关解决方案整体结构的信息。这些信息是解决方案的全球信息，对于项目中的所有开发人员来说都很常见。
它不包含任何用户特定设置。
答案 3 :(得分：13)
你一定要拥有它。除了其他人提到的原因之外，还需要对整个项目进行一步建设。
答案 4 :(得分：8)
是的，你应该承诺的事情是：
你不提交的事情是：
关于其他自动生成的文件，有一个separate thread。
答案 5 :(得分：8)
我普遍同意应该检查解决方案文件，但是，在我工作的公司，我们做了不同的事情。我们有一个相当大的存储库，开发人员不时在系统的不同部分工作。为了支持我们的工作方式，我们要么有一个大的解决方案文件，要么有几个小的。这两个都有一些缺点，需要在开发人员部分进行手动操作。为了避免这种情况，我们制作了一个处理所有这些的插件。
该插件允许每个开发人员只需从存储库中选择相关项目，就可以检查源树的子集。然后，该插件生成一个解决方案文件，并为给定的解决方案动态修改项目文件。它还处理引用。换句话说，开发人员所要做的就是选择适当的项目，然后生成/修改必要的文件。这也允许我们定制各种其他设置以确保公司标准。
此外，我们使用该插件来支持各种签入策略，这通常会阻止用户将错误/不合规的代码提交到存储库。
答案 6 :(得分：5)
是的，它应该是源代码控制的一部分。 当你从应用程序中添加/删除项目时，.sln会得到更新，最好将它置于源代码管理之下。它允许您取出应用程序代码2版本并直接进行构建（如果需要的话）。
答案 7 :(得分：4)
是的，您总是希望包含.sln文件，它包含指向解决方案中所有项目的链接。
答案 8 :(得分：4)
在大多数情况下，最好将.sln文件提交给源代码控制。
如果您的.sln文件是由其他工具（例如CMake）生成的，那么将它们放入源代码管理中可能是不合适的。
答案 9 :(得分：2)
我们这样做是因为它使一切保持同步。所有必要的项目都在一起，没有人担心错过一个。我们的构建服务器（Ant Hill Pro）也使用sln来确定要为发布版本构建的项目。
答案 10 :(得分：2)
我们通常将所有解决方案文件放在解决方案目录中。这样我们就可以将解决方案与代码分开一点，并且更容易选择我需要处理的项目。
答案 11 :(得分：1)
如果您有一个大型解决方案，其中有许多项目位于源代码管理中，那么您甚至可以考虑不将其存储在源代码控制中的唯一情况是，您希望创建一个小型解决方案，其中包含一些来自主要项目的项目一些私人瞬态要求的解决方案。
答案 12 :(得分：1)
是的 - 用于生成产品的所有内容都应该在源代码管理中。
答案 13 :(得分：1)
我们在TFS版本控制中保留或解决文件。但由于或主要解决方案非常庞大，大多数开发人员都拥有仅包含他们需要的个人解决方案。主解决方案文件主要由构建服务器使用。
答案 14 :(得分：0)
.slns是我们没有在tfs中遇到问题的唯一方法！
答案 15 :(得分：-5)
1）在VS中创建一个新项目 2）在Solution Explorer中右键单击解决方案，选择Add to Source Control
是否将sln添加到源代码管理中？那是你的答案。