如果多个文件具有相同的名称,则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输出( binobj文件夹)。 (供将来参考:在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议将不胜感激。 🙂

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

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

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

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

希望这(我的第一个stackoverflow贡献)帮助。

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

 System.Diagnostics.Debugger.Break(); 

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

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

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

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

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

我在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

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

虽然重命名其中一个文件将工作,但我发现最简单的解决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.pdbWeb.pdb 。 假设它首先加载Api.pdb 。 然后,即使您在Web\IdeasController.cs设置了断点,也会在Api.pdbfindIdeasController.cs的匹配Api.pdb 。 然后将Web\IdeasController.cs代码映射到Api.dll 。 这当然不会正确映射,所以在debugging的时候你会看到各种奇怪的问题。

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

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

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

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

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