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

Question

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

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

Answer 1

这些文件包含通常特定于您的机器的用户首选项配置，因此最好不要将其放在 SCM 中。 此外，VS 几乎每次执行时都会更改它，因此 SCM 将始终将其标记为“已更改”。 我也不包括，我在一个使用 VS 的项目中使用了 2 年，并且没有任何问题。 唯一的小烦恼是调试参数（执行路径、部署目标等）存储在这些文件之一（不知道是哪个）中，所以如果你有一个标准，你将无法'通过 SCM 为其他开发人员发布'它，让整个开发环境'准备好使用'。

Answer 2

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

Answer 3

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

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

1. 所以其他开发人员不会以一个开发人员的设置结束。
2. 因此，当您查看状态或提交文件时，这些文件不会使代码库变得混乱，也不会掩盖您需要添加的新文件。

Answer 4

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

希望这可以帮助。

Answer 5

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

为什么 Visual Studio 转换向导 2010 会创建海量 SDF 数据库文件？

Answer 6

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

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

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

Answer 7

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

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

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

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

阿林·康斯坦丁 (MSFT)

Answer 8

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

Answer 9

Visual Studio 将自动创建它们。 我不建议将它们置于源代码管理中。 有很多次本地开发人员的 SOU 文件导致 VS 在该开发人员框上表现不正常。 删除文件然后让 VS 重新创建它总是可以解决问题。

Answer 10

在MSDN 网站上，它明确指出

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

所以我会说在将内容签入源代码管理时忽略这些文件是非常安全的。

Answer 11

不。

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

Answer 12

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

Answer 13

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

Answer 14

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

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

Answer 15

您不能对 .user 文件进行源代码控制，因为这是特定于用户的。 它包含远程机器的名称和其他用户相关的东西。 这是一个与vcproj相关的文件。

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

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

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

Answer 16

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

Answer 17

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

Answer 18

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

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

Answer 19

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

GitHub 在https://github.com/github/gitignore/blob/master/VisualStudio.gitignore上维护了一个建议文件类型列表，供 Visual Studio 用户忽略

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

*.DotSettings.User
*.onetoc2
*.suo
.vs
预编译网页
大拇指数据库
对象
垃圾桶
调试
*。用户
*.vshost.*
*.tss
*.dbml.layout

Answer 20

其他人解释说不，您不希望在版本控制中使用它。 您应该配置您的版本控制系统以忽略该文件（例如，通过.gitignore文件）。

要真正理解原因，查看此文件中的实际内容会有所帮助。 我编写了一个命令行工具，可以让您查看.suo文件的内容。

通过以下方式将其安装在您的机器上：

dotnet tool install -g suo

它有两个子命令， keys和view 。

suo keys <path-to-suo-file>

这将转储文件中每个值的键。 例如（略）：

nuget
ProjInfoEx
BookmarkState
DebuggerWatches
HiddenSlnFolders
ObjMgrContentsV8
UnloadedProjects
ClassViewContents
OutliningStateDir
ProjExplorerState
TaskListShortcuts
XmlPackageOptions
BackgroundLoadData
DebuggerExceptions
DebuggerFindSource
DebuggerFindSymbol
ILSpy-234190A6EE66
MRU Solution Files
UnloadedProjectsEx
ApplicationInsights
DebuggerBreakpoints
OutliningStateV1674
...

如您所见，许多 IDE 功能使用此文件来存储它们的状态。

使用view命令查看给定键的值。 例如：

$ suo view nuget --format=utf8 .suo
nuget

?{"WindowSettings":{"project:MyProject":{"SourceRepository":"nuget.org","ShowPreviewWindow":false,"ShowDeprecatedFrameworkWindow":true,"RemoveDependencies":false,"ForceRemove":false,"IncludePrerelease":false,"SelectedFilter":"UpdatesAvailable","DependencyBehavior":"Lowest","FileConflictAction":"PromptUser","OptionsExpanded":false,"SortPropertyName":"ProjectName","SortDirection":"Ascending"}}}

有关该工具的更多信息，请访问： https : //github.com/drewnoakes/suo

Answer 21

如果您在ProjectProperties>Debugging>Environment 中设置可执行目录依赖项，路径将存储在“.user”文件中。

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

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

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

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

Answer 22

正如其他答案中所解释的， .suo和.user都不应该添加到源代码管理中，因为它们是特定于用户/机器的（顺便说一句，最新版本的 VS 的.suo已移入专用临时目录.vs ，这应该是完全脱离源代码控制）。

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

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