是否应该将Visual Studio .suo和.user文件添加到源代码管理中？

Visual Studio解决方案包含两种类型的隐藏用户文件。一个是解决方案.suo文件，它是一个二进制文件。另一个是项目.user文件，它是文本文件。这些文件究竟包含哪些数据？

我也一直在想是否应该将这些文件添加到源代码管理（在我的情况下为Subversion）。如果我不添加这些文件，而另一位开发人员签出了解决方案，Visual Studio会自动创建新的用户文件吗？

这些文件包含通常针对您的计算机的用户首选项配置，因此最好不要将其放在SCM中。另外，VS几乎每次执行时都会对其进行更改，因此SCM始终会将其标记为“已更改”。我也不参与其中，我在使用VS的项目中工作了2年，这样做没有任何问题。唯一的烦恼是调试参数（执行路径，部署目标等）存储在其中一个文件中（不知道是哪个文件），因此，如果您有针对它们的标准，则将无法通过SCM将其“发布”给其他开发人员，以使其“随时可以使用”整个开发环境。

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

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

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

1. 因此，其他开发人员将无法完成一个开发人员的设置。
2. 因此，当您查看状态或提交文件时，这些文件不会使代码库混乱，也不会混淆您需要添加的新文件。

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

希望这可以帮助。

自从我在2011年通过Google找到此问题/答案以来，我想我应该花点时间，然后将Visual Studio 2010创建的* .SDF文件的链接添加到可能不应该添加到版本控制中的文件列表中（ IDE将重新创建它们）。由于我不确定* .sdf文件在其他地方是否可以合法使用，因此我只忽略了SVN中的特定[projectname] .sdf文件。

为什么Visual Studio转换向导2010创建了一个庞大的SDF数据库文件？

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

SUO（解决方案用户选项）：记录您可能与解决方案相关联的所有选项，以便每次打开它时，它都包含您进行的自定义。

.user文件包含项目的用户选项（SUO用于解决方案），并扩展了项目文件名（例如，anything.csproj.user包含any.csproj项目的用户设置）。

这似乎是微软对此的看法：

添加（和编辑）.suo文件到源代码管理

我不知道为什么您的项目将DebuggingWorkingDirectory存储在suo文件中。如果这是用户特定的设置，则应考虑将其存储在* .proj.user文件名中。如果该设置可在所有从事该项目的用户之间共享，则应考虑将其存储在项目文件本身中。

甚至不要考虑将suo文件添加到源代码管理中！SUO（解决方案用户选项）文件旨在包含用户特定的设置，并且不应在使用同一解决方案的用户之间共享。如果您要在scc数据库中添加suo文件，我不知道您会在IDE中遇到什么其他问题，但是从源代码控制的角度来看，您将破坏Web项目scc集成，使用了Lan vs Internet插件由不同的用户访问VSS，甚至可能导致scc完全中断（存储在suo文件中的VSS数据库路径可能对您有效）可能对其他用户无效。

阿林·康斯坦丁（MSFT）

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

Visual Studio将自动创建它们。我不建议将它们放在源代码管理中。很多时候，本地开发人员的SOU文件导致VS在该开发人员框中的行为异常。删除文件然后让VS重新创建它总是可以解决问题。

在MSDN网站上，它明确指出：

解决方案用户选项（.suo）文件包含每个用户的解决方案选项。此文件不应签入源代码控制。

因此，我说在将内容检入源代码管理时忽略这些文件是非常安全的。

我不会 每个“用户”可能更改的任何内容通常在源代码管理中都是不好的。.suo，.user，obj / bin目录

这些文件是用户特定的选项，应独立于解决方案本身。Visual Studio将根据需要创建新代码，因此无需将其检入源代码管理。确实，最好不要这样做，因为这样可以使各个开发人员根据自己的喜好自定义其环境。

您无法对.user文件进行源代码控制，因为这是用户特定的。它包含远程机器的名称以及其他与用户有关的事物。这是一个与vcproj相关的文件。

.suo文件是与sln相关的文件，并且包含“解决方案用户选项”（启动项目，Windows位置（停靠的对象和位置，浮动的对象等）等）。

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

在我们公司中，我们不将这些文件置于源代码控制之下。

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

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

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

没有。

我只想要一个真正的简短答案，没有任何答案。

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

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

不要将任何这些文件添加到版本控制中。如果签入了版本控制，这将在其他工作站中引起问题，这些文件将使用工作站特定的信息自动生成。

不，因为它们是特定于开发人员/计算机的本地设置，所以它们不应致力于源代码控制。

GitHub维护了一份供Visual Studio用户忽略的建议文件类型列表，网址为https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

对于svn，我设置了以下global-ignore属性：

* .DotSettings.User
* .onetoc2
* .suo
.vs
PrecompiledWeb
thumbs.db
obj
bin
debug
* .user
* .vshost。*
* .tss
* .dbml.layout

如果在ProjectProperties> Debugging> Environment中设置可执行文件的dir依赖关系，则路径存储在'.user'文件中。

假设我在上述字段中设置了此字符串：“ PATH = C：\ xyz \ bin” 这是将其存储在'.user'文件中的方式：

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

这在OpenCV中为我们提供了很多帮助。我们可以为不同的项目使用不同版本的OpenCV。另一个优点是，在新机器上设置我们的项目非常容易。我们只需要复制相应的依赖目录。因此，对于某些项目，我更喜欢将'.user'添加到源代码管理中。

即使，它完全取决于项目。您可以根据需要拨打电话。

在其他的答案解释的那样，这两个.suo和.user不应该被添加到源控制，因为它们是用户/机器专用（顺便说一句.suo用于VS的最新版本被移动到专用临时目录.vs，这应源控制的完全保持了）。

但是，如果您的应用程序需要某种环境设置来在VS中进行调试（此类设置通常保存在.user文件中），则准备样本文件（将其命名为.user.SAMPLE）并将其添加到源代码管理中以供参考可能会很方便。

代替使用此类文件中的硬编码绝对路径，使用相对的或依赖于环境变量是有意义的，因此该示例可能足够通用，可以被其他人轻松重用。