我应该将Visual Studio. suo和. user文件添加到源代码控制吗？

您不需要添加这些——它们包含每个用户的设置，其他开发人员不需要您的副本。

Visual Studio会自动创建它们。我不建议将它们放在源代码控制中。已经有很多次本地开发人员的SOU文件导致VS在该开发人员框上的行为不正常。删除文件然后让VS重新创建它总是可以解决问题。

默认情况下，Microsoft的Visual SourceSafe在源代码控制中不包含这些文件，因为它们是用户特定的设置文件。如果您使用SVN作为源代码控制，我会遵循该模型。

. user是用户设置，我认为. suo是解决方案用户选项。您不希望这些文件处于源代码控制之下；它们将为每个用户重新创建。

使用RationalClearCase，答案是否定的。只有. sln和.*proj应该在源代码控制中注册。

我不能回答其他供应商。如果我没记错的话，这些文件是“用户”特定的选项，您的环境。

这些文件是用户特定的选项，应该独立于解决方案本身。Visual Studio将根据需要创建新文件，因此不需要签入源代码控制。实际上，最好不要这样做，因为这允许个人开发人员自定义他们认为合适的环境。

它们包含有关项目的特定设置，这些设置通常分配给单个开发人员（例如，调试应用程序时要启动的起始项目和起始页面）。

所以最好不要将它们添加到版本控制中，让VS重新创建它们，以便每个开发人员都可以拥有他们想要的特定设置。

我们不提交二进制文件（*. suo），但我们提交. user文件。. user文件包含例如调试项目的开始选项。您可以在“调试”选项卡中的项目属性中找到开始选项。我们在某些项目中使用了NUnit，并将nunit-gui.exe配置为项目的开始选项。如果没有. user文件，每个团队成员都必须单独配置它。

希望这有帮助。

我不会。任何可以根据“用户”更改的内容在源代码控制中通常都不好。. suo、. user、obj/bin目录

这似乎是微软对此事的看法:

向源代码管理添加(并编辑) . suo 文件

我不知道为什么您的项目将 DebuggingWorkingDirectory 存储在 如果这是一个用户特定的设置，你应该考虑 存储在 * . proj.user 文件名中 在所有工作在项目中的用户之间，您应该考虑存储 它在项目文件本身。

想都别想把 SUO 文件添加到源代码管理中! The SUO (解决方案用户选项)文件意味着包含特定于用户的 设置，并且不应该在使用相同设置的用户之间共享 如果你要在 scc 数据库中添加 suo 文件，我不会 知道在 IDE 中除了源代码控制之外还有哪些东西是要破坏的 从观点上讲，你将打破网络项目的集成，蓝与蓝的对决 互联网插件使用不同的用户访问 VSS，你可以 甚至导致 scc 完全中断(VSS 数据库路径存储在 可能对您有效的 suo 文件可能对其他用户无效)。

Alin Constantin (MSFT)

您不能对。用户文件，因为那是特定于用户的。它包含远程计算机的名称和其他依赖于用户的东西。这是一个 Vcproj 相关的文件。

那个。Suo 文件是一个与 sln 相关的文件，它包含“解决方案用户选项”(启动项目、窗口位置(停靠的位置、浮动的位置) ，等等)

这是一个二进制文件，我不知道它是否包含“用户相关”的东西。

在我们的公司，我们不采取这些文件的源代码管理。

不，您不应该将它们添加到源代码管理中，因为——正如您所说的——它们是特定于用户的。

解决方案用户选项: 记录 你所有的选择 与你的解决方案联系起来，以便 每次你打开它，它包括 自定义 已经做了。

那个。User file 包含项目的用户选项(而 SUO 用于解决方案)并扩展项目文件名(例如 anything.csproj.user 包含 anything.csproj 项目的用户设置)。

这些文件包含通常特定于您的计算机的用户首选项配置，因此最好不要将其放在 SCM 中。而且，几乎每次执行 VS 都会对其进行更改，因此 SCM 总是将其标记为“更改”。 我不包括任何一个，我在一个项目中使用 VS 2年，并没有问题做到这一点。唯一的小麻烦是，调试参数(执行路径、部署目标等)存储在其中一个文件中(不知道是哪个) ，所以如果你有一个针对它们的标准，你就不能通过 SCM“发布”它，让其他开发人员有整个开发环境“准备使用”。

其他人解释了为什么将 *.suo和 *.user文件置于源代码控制之下不是一个好主意。

我建议您将这些模式添加到 svn:ignore属性中，原因有二:

1. 这样其他开发商就不会倒闭了 只有一个开发者的设置。
2. 因此，当您查看状态或提交 文件，这些文件不会混乱的代码基和模糊的新文件，你需要添加。

自从我在2011年通过谷歌找到了这个问题/答案，我想我应该花点时间来添加 * 的链接。将 VisualStudio2010创建的 SDF 文件添加到可能不应添加到版本控制的文件列表中(IDE 将重新创建这些文件)。因为我不确定。Sdf 文件可能在其他地方有合法的用途，我只是忽略了特定的[项目名]。来自 SVN 的 sdf 文件。

为什么 VisualStudio 转换向导2010创建大量 SDF 数据库文件？

在 MSDN 网站上，它清楚地表明

解决方案用户选项(. suo)文件包含每个用户的解决方案 选项 不应将此文件签入到源代码管理中。

所以我要说，在向源代码管理检入内容时忽略这些文件是相当安全的。

如果在 ProjectProperties > 调试 > 环境中设置可执行目录依赖项，则路径存储在“ . user”文件中。

假设我在上面提到的字段中设置了这个字符串: < strong > “ PATH = C: xyz bin” 这是它如何被存储在’. user’文件中的:

<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>

这对我们在 OpenCV 工作很有帮助。我们可以为不同的项目使用不同版本的 OpenCV。另一个优势是，在一台新机器上设置我们的项目非常容易。我们只需要复制相应的依赖项目录。因此，对于某些项目，我更喜欢添加’。用户对源代码的控制。

尽管如此，它完全依赖于项目，你可以根据自己的需要接听电话。

不要将这些文件中的任何一个添加到版本控制中。这些文件是自动生成的工作站特定信息，如果签入到版本控制，将导致麻烦在其他工作站。