如果多个文件具有相同的名称，则Visual Studio断点会在错误的源文件（或多个文件同时）中断裂

在我正在开发的团队项目中，如果在解决scheme中存在另一个具有相同名称的文件，则在文件中设置断点（例如IdeasController.cs ）将导致错误的debugging器行为。 我已经在几个开发人员的工作站上重现了这个问题。

例

我在Web API中的IdeasController.cs中设置了一个断点：

另一个名为IdeasController.cs文件存在于我们单独的MVC 4 web项目中。 在下面的屏幕截图中，debugging器显示了Api->IdeasController源代码，但是行突出显示与Web->IdeasController的代码结构相匹配。 断点是重复的，其中一个位于注释块的中间。

断点窗口同时在两个文件中显示断点：

在某些工作站上，debugging器通过正确的行（不pipe行高亮）。 在别人身上，它通过不相关的行（包括评论和空白）高兴地走了过来。 我猜这取决于它select显示哪个源文件。

我试过了

我已经浏览了互联网。 当debugging文件（ *.pdb ），源文件和编译后的代码不匹配时，就会出现这种问题。 有很多可能的原因：重复的文件名（可能会混淆debugging器^[5] ），过时的项目构build文件，无效的解决schemecaching或不正确的构buildconfiguration。

这些是我find和尝试的解决scheme：

• 检查了我的构buildconfiguration。
  1. 确保项目不是以发布模式构build的。
  2. 确保我们没有启用代码优化 。
  3. 确保项目的debugging模块已正确加载。 （开始debugging项目，并勾选Debug > Windows > Modules 。这两个程序集都列出，没有优化，并且符号状态为“Symbols loaded”。）
• 重置debugging元数据和Visual Studiocaching。
  1. closuresVisual Studio并删除解决schemecaching文件（ *.suo ）。 ^[1]
  2. 删除每个项目的构build输出（ bin和obj文件夹）。 （供将来参考：在Windows资源pipe理器中打开解决scheme文件夹，并在search框中input：“ type:folder AND (name:=bin OR name:=obj) ”。
  3. 删除程序集caching文件夹（ C:\Documents and Settings\<user>\Local Settings\Application Data\dl3 ）。 ^{[2] [3]}

这些都没有任何影响。 我可以重命名其中一个文件（不需要重命名该类）来临时解决问题，但这并不理想。

我现在在哪里

我最近的Googlesearch的第14页。 build议将不胜感激。 🙂

Answer 1

我很高兴我发现这个post，以为我是唯一一个疯了！ 我遇到了与VB.Net VS2012相同的问题，并尝试所有的OP提到。

独特的文件命名似乎是我find的唯一的100％修复。 禁用所有断点，直到应用程序加载完毕，然后重新启用所需的断点。 Lambda函数中的断点仍然可以给您提供问题。

Answer 2

我今天也有同样的问题。 我能够追溯到我忘记在debugging时将平台目标设置为x86的事实。 不幸的是其他的（x64 /任何CPU）在debugging时可能会有问题。 至lessVS 2008不喜欢他们。 我想这是另一个离开的理由。

一些猜测…我认为debugging器（当运行一个64位的应用程序）在某些情况下以某种方式“断开”文件中的断点。 对我来说是因为另外一个程序集先被加载了，而且文件名相同。 我可以避免这个问题，即使在64位模式下，如果我第一次用我的断点手动加载程序集：Assembly.Load（“MyAssemblyWithBreakpoints”）;

希望这（我的第一个stackoverflow贡献）帮助。

Answer 3

如果没有更好的select，你可以把代码中的断点：

 System.Diagnostics.Debugger.Break(); 

只是不要忘记随后删除它…

Answer 4

我刚刚有完全相同的问题。 为我解决的是删除属于包含受影响的项目/源文件的解决scheme.suo文件。

我也删除了我的本地符号caching，但我认为这跟它没有任何关系。

（我的解决scheme包含多个项目，一个项目中的一个文件（DataAdapter.cs）受此影响（VisualStudio把我的断点放在属于System.Data.DataAdapter的pdb中）。我直接打开了.csproj文件，并且能够正确设置断点。）

Answer 5

我只是备份和删除文件，然后回到项目，解决了这个问题。 我只是希望我通过之前提到的名单之前做了:)

Answer 6

我在Visual Studio 2015中遇到了这个问题。

我有一个DLL的子文件夹，我想保存为Version1。 它甚至在删除对该DLL的引用之后，然后添加对另一个项目工作室的引用拉到现有的引用，并去到错误的源文件。 我删除该子文件夹中的DLL然后Studio得到正确的来源。

我find了一个有用的链接[MSDN，显示如何清除在此链接的工作室在先关联的源文件] [1]。

概要：

1. 在解决scheme资源pipe理器中，右键点击解决scheme名称（例如：Solution'TestApplication'），然后select属性。这将打开解决scheme属性页面对话框
2. 在通用属性下，selectdebugging源文件
3. 在search包含源代码（Visual Studio 2005）的源代码文件（Visual Studio .NET 2003）/目录的这些path框中，根据需要添加，删除和/或重新sorting目录
4. 点击确定button

Answer 7

您也可以尝试清理和重build（而不是构build）所有项目。

Answer 8

虽然重命名其中一个文件将工作，但我发现最简单的解决scheme是暂时禁用自动加载“其他”程序集的符号。

1. 启动debugging器并继续，直到您遇到错误的断点。
2. finddebugging器使用“ 调用堆栈”窗口实际设置断点的位置：
   1. 用黄色箭头右键单击该行并启用显示模块名称 。 （行上也应该有红色的断点符号。）
   2. 程序集名称现在在该行上可见。
3. 在“模块”窗口中find该程序集（“ debugging”>“Windows”>“模块” ）。
4. 用鼠标右键单击程序集并禁用始终自动加载 。
5. 停止debugging器。
6. 再次开始debugging。

通过这样做，可以防止Visual Studiodebugging器将断点映射到错误的程序集。 然后，它将首先从其他[推测]正确的程序集中加载符号，因此将断点映射到正确的程序集。

为什么会这样呢？

这似乎发生在两个不同的符号文件（PDB文件） – 对于两个不同的程序集 – 都引用具有相同名称的源文件。 虽然源文件是完全不同的，Visual Studiodebugging器似乎感到困惑。

例如，假设有两个名称为IdeasController.cs不同文件。 第一个编译成Assembly Api.dll ，第二个编译成Assembly Web.dll 。

当debugging器加载符号时，它将首先加载Api.pdb或Web.pdb 。 假设它首先加载Api.pdb 。 然后，即使您在Web\IdeasController.cs设置了断点，也会在Api.pdbfindIdeasController.cs的匹配Api.pdb 。 然后将Web\IdeasController.cs代码映射到Api.dll 。 这当然不会正确映射，所以在debugging的时候你会看到各种奇怪的问题。

Answer 9

什么工作对我来说（VS2017） 禁用 Tools --> Options... --> Debugging --> General ：“ 要求源文件完全匹配原始版本 ”，这是默认启用，但我有这个选项打开。

这是不够的，我也不得不手动删除解决scheme中的所有项目的obj和bin文件夹。

Answer 10

编写.NET代码时，我会遵循这些指导原则。

1. 每个文件只能包含一个类。
2. 不应该有不同的程序集中重复的类。 因此，不要重复代码，只需改变类的可见性（如果需要），以便外部程序集可以使用它。
3. 每个文件应该按照它定义的类来命名。

如果保留这些规则，那么应该遵循所有的代码文件应该以不同的方式命名。 我认为这是你的问题的根源。