我应该添加Visual Studio .suo和.user文件到源代码pipe理？
Visual Studio解决scheme包含两种types的隐藏用户文件。 一个是解决scheme.suo文件，它是一个二进制文件。 另一个是项目.user文件，它是一个文本文件。 这些文件究竟包含哪些数据？
我也想知道是否应该将这些文件添加到源代码pipe理（Subversion在我的情况）。 如果我不添加这些文件，另一个开发人员检查解决scheme，Visual Studio会自动创build新的用户文件？
这些文件包含一般特定于您的机器的用户首选项configuration，所以最好不要放在SCM中。 而且，VS几乎每次执行都会改变它，所以它总会被SCM标记为“改变”。 我也不包括，我在一个项目使用VS 2年，并没有这样做的问题。 唯一的小麻烦是debugging参数（执行path，部署目标等）被存储在其中一个文件中（不知道是哪一个），所以如果你有一个标准的话，你将无法'通过SCM发布“，让其他开发者拥有整个开发环境”准备使用“。
您不需要添加这些 – 它们包含每个用户的设置，其他开发人员不会需要您的副本。
其他人解释了为什么在源代码控制下使用*.suo和*.user文件不是一个好主意。
我想build议你将这些模式添加到svn:ignore属性有两个原因：
- 所以其他开发人员不会结束一个开发人员的设置。
- 所以，当你查看状态或提交文件时，这些文件不会混淆代码库并遮盖需要添加的新文件。
我们不提交二进制文件（* .suo），但我们提交.user文件。 .user文件包含例如debugging项目的启动选项。 您可以在选项卡“debugging”中find项目属性中的开始选项。 我们在一些项目中使用了NUnit，并将nunit-gui.execonfiguration为项目的启动选项。 没有.user文件，每个团队成员将不得不单独configuration它。
希望这可以帮助。
因为我在2011年通过Google发现了这个问题/答案，所以我想我会花一秒钟时间，并将由Visual Studio 2010创build的* .SDF文件的链接添加到可能不应该添加到版本控制的文件列表中IDE将重新创build它们）。 由于我不确定* .sdf文件在其他地方是否可以合法使用，所以我只忽略了SVN中特定的[projectname] .sdf文件。
为什么Visual Studio转换向导2010创build一个海量的SDF数据库文件？
不，你不应该把它们添加到源代码控制，因为 – 正如你所说 – 他们是用户特定的。
SUO（解决scheme用户选项）：logging您可能与解决scheme关联的所有选项，以便每次打开时都包含您所做的自定义设置。
.user文件包含项目的用户选项（而SUO用于解决scheme）并扩展项目文件名（例如anything.csproj.user包含用于anything.csproj项目的用户设置）。
默认情况下，Microsoft的Visual SourceSafe不包括源代码pipe理中的这些文件，因为它们是用户特定的设置文件。 如果你使用SVN作为源代码控制，我会遵循这个模型。
这似乎是微软对此事的看法： http : //social.msdn.microsoft.com/forums/en-US/vssourcecontrol/thread/dee90d75-d825-4c76-a30f-016eab15ef7f
我不知道为什么你的项目将DebuggingWorkingDirectory存储在suo文件中。 如果这是用户特定的设置，则应考虑将其存储在* .proj.user文件名中。 如果这个设置是可以共享的，所有在这个项目上工作的用户都应该考虑把它存储在项目文件中。
甚至不想将suo文件添加到源代码pipe理中！ SUO（soluton用户选项）文件旨在包含用户特定的设置，不应该在使用相同解决scheme的用户之间共享。 如果你要在SCC数据库中添加suo文件，我不知道IDE中还有什么其他的东西会破坏，但是从源代码控制的angular度来看，你将会破坏web项目的scc集成，使用Lan vs Internet插件由不同的用户进行VSS访问，甚至可能导致scc完全中断（存储在suo文件中的VSS数据库path可能对您有效，可能对另一个用户无效）。
阿林·康斯坦丁（MSFT）
Visual Studio将自动创build它们。 我不build议把它们放在源代码pipe理中。 曾经有过很多次当地开发者的SOU文件导致VS在开发者框中performance不正常。 删除文件，然后让VS重新创build它总是解决问题。
我不会。 任何可以改变每个“用户”通常是不好的源代码pipe理。 .suo，.user，obj / bin目录
这些文件是用户特定的选项，应独立于解决scheme本身。 Visual Studio会根据需要创build新的，所以他们不需要检入源代码控制。 事实上，最好不要这样做，因为这允许个人开发人员按照他们认为合适的方式来定制他们的环境。
在MSDN网站上 ，它明确指出
解决scheme用户选项（.suo）文件包含每个用户的解决scheme选项。 这个文件不应该签入到源代码控制 。
所以我会说，在你的源代码pipe理中检查这些文件的时候忽略这些文件是非常安全的。
您不能源代码控制.user文件，因为这是用户特定的。 它包含远程机器的名称和其他依赖用户的东西。 这是一个vcproj相关的文件。
.suo文件是一个sln相关的文件，它包含“解决scheme用户选项”（启动项目，窗口位置（什么停靠和在哪里，什么是浮动）等）
这是一个二进制文件，我不知道它是否包含“用户相关”的东西。
在我们公司，我们不会把这些文件放在源代码pipe理下。
它们包含通常分配给单个开发人员的有关项目的特定设置（例如，在debugging应用程序时启动的项目和启动页面）。
所以最好不要将它们添加到版本控制中，让VS重新创build它们，这样每个开发人员都可以拥有他们想要的特定设置。
.user是用户设置，我认为.suo是解决scheme的用户选项。 你不希望这些文件在源代码控制下; 他们将为每个用户重新创build。
使用Rational ClearCase的答案是否定的，只有.sln＆。* proj应该在源代码控制中注册，我无法回答其他供应商。 如果我正确记得这些文件是“用户”特定的选项，您的环境。
