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

Posted 2023-02-19

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

【英文标题】：Should I add the Visual Studio .suo and .user files to source control?

【发布时间】：2010-09-09 11:52:08

【问题描述】：

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

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

【问题讨论】：

.suo 文件会自动重新创建。如果出现问题，这是一种将设置“刷新”为默认设置的好方法。

Best practices for Subversion and Visual Studio projects 是关于这个确切主题的更通用的问题。 accepted answer of it 还包含官方 MSDN 文档的链接，其中详细描述了 VS 解决方案/项目的哪些文件/目录应该添加到源代码控制系统，以及应该忽略哪些部分。

对于*.suo，请看这里：msdn.microsoft.com/en-us/library/bb165909.aspx

Which Visual C++ file types should be committed to version control?

有一种非常简单的方法可以确定是否应在版本控制中包含特定文件。删除文件。您的应用程序是否仍按预期构建和执行？如果是这样，则不应包含该文件。

【参考方案1】：

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

【讨论】：

小心，suo 文件存储了项目是否在解决方案中加载/卸载的信息。

我相信它将调试信息存储在 .user 文件中（至少对于 SQL Server Data Tools）。此外，当您更改“调试”选项卡中的设置时，它并不总是立即保存到 .user（关闭解决方案似乎有效，有点烦人......或更改存储在 .sqlproj 文件中的另一个设置）。

您可以在任何文本编辑器中打开 .user 和 .csproj 文件。我刚刚测试了将 .user 中的相关调试设置复制粘贴到 .csproj 中，然后删除 .user 文件。调试继续工作，愉快地从 .csproj 文件中的新位置读取正确的设置。这应该提供一种在不提交 .user 文件的情况下提交调试设置的方法。确保将它们置于正确的配置中（调试、发布等）。在我的机器上工作！ =)

@ChrisNielsen 手动插入的属性是否出现在 Visual Studio 的 GUI 中？我似乎有调试工作，但它看起来很神秘，因为字段值没有显示在 Visual Studio 中

【参考方案2】：

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

【讨论】：

如果您自己在几台不同的机器上工作，是否值得添加它们？

我不会，因为它可能会因意外的系统差异而变得脆弱；例如，如果您在工作中使用 x64 而在家中使用 x86，那么它可能会阻塞“c:\program files (x86)”和“c:\program files”。我不知道，但我不会冒险。

虽然它们包含用户特定信息，但我认为通过（包含在项目中）选项新添加的文件的信息也在 .csproj 文件中，这需要其他用户手动添加所有新增项目资源。如果有人知道解决方法，请在此处提及。

【参考方案3】：

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

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

所以其他开发人员不会结束 使用一位开发者的设置。 因此，当您查看状态或提交时 文件，这些文件不会弄乱代码库并掩盖您需要添加的新文件。

【讨论】：

svn:ignore 属性设置在哪里以及如何设置？

@PeterMortensen，看到这个问题：***.com/questions/86049/…

但是有一种情况（见this answer）可以添加.user，所以可以选择不只忽略.suo——或者可以忽略.user，这样就需要有意识地决定添加它们？不要这么认为，svn:ignore 的意义在于标记不需要有意识决定的事情。

【参考方案4】：

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

希望这会有所帮助。

【讨论】：

我也开始认为应该是这种情况 - 提交用户文件，以便团队中的开发人员使用相同的调试设置。如果他们在自己的机器上更改它，仍然可以，只要标准方式是源代码管理中的版本。

其他人建议不要这样做，但我不确定可能会有什么危险。也许是因为设置不太精确的 repo 文件会吹走用户的（更好的）本地副本？ （我们的团队正在使用 Mercurial，顺便说一句。）

Microsoft advises against 将 .user 文件添加到源代码管理。

您可以将调试设置移动到.csproj，见this comment

您可以添加一个不同名称的标准用户设置副本。

【参考方案5】：

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

Why does the Visual Studio conversion wizard 2010 create a massive SDF database file?

【讨论】：

SDF 文件可能是SQL Server Compact Edition database。

【参考方案6】：

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

SUO（解决方案用户选项）：记录 您可能会选择的所有选项 与您的解决方案相关联，以便 每次打开它，它包括 你的定制 取得了。

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

【参考方案7】：

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

Adding (and editing) .suo files to source control

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

别想将 suo 文件添加到源代码管理中！ SUO （解决方案用户选项）文件旨在包含特定于用户的 设置，并且不应在相同的用户之间共享 解决方案。如果您要在 scc 数据库中添加 suo 文件，我不会 知道您会破坏 IDE 中的其他内容，但来自源代码控制 观点你会打破 web 项目 scc 集成，Lan vs 不同用户用于 VSS 访问的 Internet 插件，您可以 甚至导致 scc 完全中断（VSS 数据库路径存储在 suo 文件可能对您有效，但可能对其他用户无效）。

阿林康斯坦丁 (MSFT)

【讨论】：

另外，来自 MSDN：Solution User Options (.Suo) File。第一句话让微软的意图非常明确：“解决方案用户选项 (.suo) 文件包含每个用户的解决方案选项。此文件不应签入源代码控制。”

【参考方案8】：

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

【参考方案9】：

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

【讨论】：

我留下了 .sou 文件，但在重新加载软件包时出现问题。删除 .sou 文件解决了这个问题。谢谢。

【参考方案10】：

在MSDN website上，明确指出

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

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

【参考方案11】：

没有。

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

【参考方案12】：

我不会。每个“用户”可能改变的任何东西在源代码控制中通常都不好。 .suo、.user、obj/bin 目录

【参考方案13】：

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

【参考方案14】：

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

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

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

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

【参考方案15】：

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

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

【参考方案16】：

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

【参考方案17】：

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

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

【讨论】：

only the .sln & .*proj should be registered - 你不是忘记了很多文件吗？

@Wolf 除了显而易见的

【参考方案18】：

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

【参考方案19】：

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

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

对于 svn，我有以下 global-ignore 属性集：

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

【参考方案20】：

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

然而如果您的应用程序需要一些环境设置以在 VS 中进行调试（这些设置通常保存在 .user 文件中），准备一个示例文件可能会很方便（将其命名为 @ 987654326@) 并将其添加到源代码管理以供参考。

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

【参考方案21】：

其他人已经解释说不，您不希望在版本控制中使用它。您应该将版本控制系统配置为忽略该文件（例如，通过 .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

【参考方案22】：

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

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

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

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

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

【讨论】：

符号链接也可以很好地用于此目的。

依赖环境变量而不是硬编码绝对路径是有意义的（例如PATH=$(PGSQL_ROOT)\bin - 来自使用 PostgreSQL 的真实项目的示例）。