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

SUO(解决方案用户选项):记录 所有可能的选择 把你的解决方案联系起来 每次你打开它，里面都有 自定义 取得了。

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

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

GitHub在https://github.com/github/gitignore/blob/master/VisualStudio.gitignore上为VisualStudio用户提供了一个建议的文件类型列表

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

* .DotSettings.User * .onetoc2 *。suo .vs预编译的web thumbs.db obj bin调试 *。user * * .vshost。 * .tss * .dbml.layout

Visual Studio会自动创建它们。我不建议把它们放在源代码控制中。曾经有很多次，本地开发人员的SOU文件导致VS在开发人员的盒子上表现不稳定。删除文件，然后让VS重新创建它总是修复问题。

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

添加(并编辑).suo文件到源代码控制

I don't know why your project stores the DebuggingWorkingDirectory in the suo file. If that is a user specific setting you should consider storing that in the *.proj.user filename. If that setting is shareable between all users working on the project you should consider storing it in the project file itself. Don't even think of adding the suo file to source control! The SUO (soluton user options) file is meant to contain user-specific settings, and should not be shared amongst users working on the same solution. If you'd be adding the suo file in the scc database I don't know what other things in the IDE you'd break, but from source control point of view you will break web projects scc integration, the Lan vs Internet plugin used by different users for VSS access, and you could even cause the scc to break completely (VSS database path stored in suo file that may be valid for you may not be valid for another user). Alin Constantin (MSFT)

在MSDN网站上，它清楚地说明了这一点

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

所以我想说，在把东西签入源代码控制时，忽略这些文件是非常安全的。

These files contain user preference configurations that are in general specific to your machine, so it's better not to put it in SCM. Also, VS will change it almost every time you execute it, so it will always be marked by the SCM as 'changed'. I don't include either, I'm in a project using VS for 2 years and had no problems doing that. The only minor annoyance is that the debug parameters (execution path, deployment target, etc.) are stored in one of those files (don't know which), so if you have a standard for them you won't be able to 'publish' it via SCM for other developers to have the entire development environment 'ready to use'.