在我正在处理的团队项目中,如果解决方案中存在另一个具有相同名称的文件,则在文件中设置断点(例如IdeasController.cs
)将导致调试器行为不稳定。我在几个开发人员的工作站上重现了这个问题。
我在Web API的IdeasController.cs
中设置了一个断点:
另一个名为IdeasController.cs
的文件存在于我们单独的MVC 4 Web项目中。在下面的屏幕截图中,调试器显示Api->IdeasController
源代码,但行突出显示与Web->IdeasController
的代码结构相匹配。断点是重复的,其中一个位于注释块的中间。
“断点”窗口同时显示两个文件中的断点:
在某些工作站上,调试器会逐步执行正确的行(无论行突出显示);在其他人身上,它愉快地介绍了不相关的行(包括评论和空白)。我猜这取决于它选择显示哪个源文件。
我在网上搜寻了一下。当调试文件(*.pdb
),源文件和编译代码之间不匹配时,似乎会出现这种问题。有很多可能的原因:重复的文件名(可能会混淆调试器 [5] ),过时的项目构建文件,无效的解决方案缓存或不正确的构建配置。
这些是我找到并尝试的解决方案:
Debug
> Windows
> Modules
。两个程序集都已列出,未进行优化,并且符号状态为“已加载符号”。)这些都没有任何影响。我可以重命名其中一个文件(不重命名类)来暂时解决问题,但这远非理想。
我最新的Google搜索的第14页。建议将不胜感激。 :)
答案 0 :(得分:6)
我很高兴我发现这篇文章,以为我是唯一一个疯了!我在VS2012中使用VB.Net遇到了同样的问题,并尝试了OP提到的所有内容。
文件的唯一命名似乎是我发现的唯一100%修复。在应用程序加载之前禁用所有断点,然后重新启用所需的断点,大部分时间都可以使用。 Lambda函数中的断点仍然可以为您提供问题。
答案 1 :(得分:4)
如果不存在更好的替代方案,可以将断点放在代码中:
System.Diagnostics.Debugger.Break();
不要忘记之后删除它......
答案 2 :(得分:4)
我刚才遇到了同样的问题。为我解决的是删除属于包含受影响的项目/源文件的解决方案的.suo文件。
我也删除了我的本地符号缓存,但我不认为这与它有任何关系。
(我的解决方案包含多个项目,一个项目中的一个文件(DataAdapter.cs)受此影响(VisualStudio将我的断点放在属于System.Data.DataAdapter的pdb中)。我直接打开了.csproj文件能够正确设置断点。)
答案 3 :(得分:3)
我今天遇到了同样的问题。我能够追溯到我忘记在调试时将平台目标设置为x86这一事实。不幸的是,其他(x64 /任何CPU)在调试时可能会出现问题。至少VS 2008不喜欢他们。我想这是离开的另一个原因。
一些推测......我认为调试器(在运行64位应用程序时)在某些情况下会以某种方式“窃取”远离文件的断点。对我来说,这是因为首先加载了另一个具有相同文件名的程序集。我能够避免这个问题,即使在64位模式下,如果我首先使用我的断点手动加载程序集:Assembly.Load(“MyAssemblyWithBreakpoints”);
希望这(我的第一个stackoverflow贡献)有所帮助。
答案 4 :(得分:2)
我在Visual Studio 2017(版本15.9.7)上遇到了这个问题,跳过了断点,调试器只是在返回语句上“跳过”了。
一段时间后,我注意到我最近在项目中添加了一个.runsettings文件-事实证明,以我为例,配置CodeCoverage数据收集器会导致此问题。 我删除此部分后:
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> ... </DataCollector>
.runsettings文件中的文件,再次像魅力一样工作。
答案 5 :(得分:1)
我刚刚备份并删除了文件,然后又添加回项目,解决了问题。我只是在完成前面提到的清单之前完成了它:)
答案 6 :(得分:1)
我在Visual Studio 2015中遇到了这个问题。
我有一个带有DLL的子文件夹我想保存为Version1。甚至在删除对该DLL的引用之后,然后在现有引用中添加对另一个项目工作室的引用并转到错误的源文件。我在子文件夹中删除了该DLL,然后Studio获得了正确的源代码。
我在[MSDN上找到了一个有用的链接,显示如何在此链接中清除工作室中先前关联的源文件] [1]。
<强>要点:强>
答案 7 :(得分:1)
虽然重命名其中一个文件可行,但我发现最简单的解决方案是暂时禁用“其他”程序集的符号自动加载。
通过执行此操作,您将阻止Visual Studio调试器将断点映射到错误的程序集。然后它将首先从其他[推测]正确的装配加载符号,因此将断点映射到正确的装配。
当两个不同的符号文件(PDB文件) - 两个不同的程序集 - 都引用具有相同名称的源文件时,似乎会发生这种情况。虽然源文件完全不同,但Visual Studio调试器似乎感到困惑。
例如,假设有两个名称为IdeasController.cs
的不同文件。第一个编译成汇编Api.dll
,第二个编译成汇编Web.dll
。
当调试器加载符号时,它将首先加载Api.pdb
或Web.pdb
。我们先说它首先加载Api.pdb
。然后,即使您在Web\IdeasController.cs
中设置了断点,也会在IdeasController.cs
中找到Api.pdb
的匹配项。然后,它会将代码从Web\IdeasController.cs
映射到Api.dll
。当然,这不会正确映射,因此您在调试时会看到各种奇怪的问题。
答案 8 :(得分:1)
我遇到了同样的问题。就我而言,这两个项目都具有相同的端口号。我可以通过更改未击中文件断点的项目的端口号来解决此问题。
我的猜测是,IIS Express正在缓存第二个项目中的pdb文件,因为这两个文件具有相同的名称,并且项目具有相同的端口号。
答案 9 :(得分:0)
您也可以尝试清理和重建(不构建)所有项目。
答案 10 :(得分:0)
对我(VS2017)有用的是禁用 Tools --> Options... --> Debugging --> General
中的此选项:“要求源文件与原始版本完全匹配”,这已启用默认情况下我打开了它。
但这还不够,我还必须为解决方案中的所有项目手动删除obj
和bin
个文件夹。
答案 11 :(得分:0)
删除断点错误发生的项目的所有.pdb文件。这将解决问题。
答案 12 :(得分:0)
我(在 VS 2008 中)发生了两个带有相同内存地址和相同关联文件的子断点。 这些断点是在流程运行期间的某个时间产生的。
我注意到我的项目文件夹中有.dll
个重复文件,并已解决删除重复的.dll
,同时每个名称只保留一个.dll
调试文件夹结构。 (例如,在我的情况下,我的/bin/Example.dll
和/bin/Plug-in/Example.dll
都出现在我的调试文件夹结构下。)
答案 13 :(得分:0)
我有一个非常相似的问题。在我的情况下,问题是其中一个项目中的目标.net框架不同,从而导致VS2017错误地加载了另一个项目的源文件(具有相同的名称),而不是被另一个项目激活了。
ObjectHandle handle = Activator.CreateInstance
在所有固定项目中更改项目的目标框架使其相同。
答案 14 :(得分:0)
我在另一个项目中具有相同文件名的另一个文件中设置断点时遇到类似的问题。
这是由于为其他项目启动了调试,而对于试图设置断点的项目却没有启动调试引起的。为所需项目执行“调试”>“启动新实例”后,可以正确创建断点。