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

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

---

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

---

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

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

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

---

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

希望这可以帮助。

---

由于我在 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?

---

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

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

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

---

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

Adding (and editing) .suo files to source control

我不知道你的项目为什么将 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 website 上，它明确指出

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

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

---

不。

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

---

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

---

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

---

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

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

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

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

---

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

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

---

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

---

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

---

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

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

---

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

---

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

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 debug *.user *.vshost.* *.tss *.dbml.layout

---

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

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

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

---

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

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

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

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

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

---