3

我正在尝试重新调整一个非常大的解决方案的布局,该解决方案已经变得难以使用(而且速度很慢)。我的计划是创建一些包含相关项目的解决方案,然后在必要时使用二进制引用链接到其他解决方案生成的库。

我们依靠 Resharper 的 Navigate to External Sources 功能使其可用,因此我们可以轻松地浏览我们从其他解决方案引用的项目的源代码。VS 不能开箱即用的原因超出了我的理解。

对于具有实现的类,这一切都非常好。但是,对于仅包含自动实现属性的 C# 接口和类,Resharper 无法浏览到源代码,并回退到粗糙的元数据查看器。

我使用了 srctool.exe,它带有 MS Debugging Tools For Windows 中的 Symbol Server 工具,来浏览 .pdb 文件中列出的源代码,很明显这些接口和空(ish)类的源代码没有在pdb 文件。如果我将自动实现的属性切换为具有支持字段的属性,则源链接将出现在 pdb 中。

我猜测源被排除在外,因为没有地方可以在接口和自动实现的属性上设置断点。

不过,我想知道是否有一些特殊的编译器选项或解决方法可以用来强制 PDB 文件包含对 C# 接口源的引用。

谢谢,马克

4

1 回答 1

1

这个问题没有足够的细节。突然间,我猜您通过将项目引用转换为程序集引用来解决缓慢的大规模解决方案的问题。并使用这些项目的发布版本作为参考。

是的,这难倒了任何试图从 PDB 中查找源代码文件的工具。.NET 项目的发布版本使用 PDB 的剥离版本,所有源代码文件和行号信息已从中删除。对于真正的发布版本来说,这是一件很正常的事情。发布构建的代码通常是优化的。这会导致代码重新排序,不再匹配源文件中代码的逻辑位置。您从源+线 PDB 信息中获得的任何信息现在往往介于有害和无用之间,您开始在错误的地方寻找问题。

然而,这不是IDE 工具或调试应用程序时的问题。在这种情况下,优化器会自动禁用。实际上是VS中的一个配置项:Tools + Options,Debugging,General,“Suppress JIT optimization on module load”选项。默认开启。

显然,任何使用 PDB 的工具在没有机会找到源文件时都会变得紧张。修复方法是返回原始项目,再次选择发布配置并更改设置:项目+属性,构建选项卡,向下滚动,高级按钮。将“调试信息”组合从“pdb-only”更改为“full”。重建项目。

应该解决你的问题。还恢复调试器,你可以再次进入源代码。

顺便说一句,不要移动文件太多,你可能会再次难倒笨蛋。至少将 PDB 与 DLL 保持在同一目录中。如果源代码不再存在于同一目录中,但您在另一个目录中再次检出它,那么您必须告诉 IDE。右键单击解决方案、属性、调试源文件设置。

于 2014-07-16T14:50:32.780 回答