我正在尝试重新设计一个非常大的解决方案的布局，这个解决方案已经变得难以理解（并且很难）。我的计划是创建一些包含相关项目的解决方案，然后在必要时使用二进制引用链接到其他解决方案生成的库。
我们依赖于使其可用的是Resharper的Navigate to External Sources功能，因此我们可以轻松浏览我们从其他解决方案引用的项目的来源。究竟为什么VS无法开箱即用，这超出了我的范围。
对于具有实现的类，这一切都非常好用。但是，对于仅包含自动实现属性的C＃接口和类，Resharper无法浏览到源，并且回退到粗糙的元数据查看器。
我使用srctool.exe（用于Windows的MS调试工具中的Symbol Server工具）来浏览.pdb文件中列出的源代码，很明显这些接口和空（ish）类的源代码是没有在pdb文件中引用。如果我将自动实现的属性切换到具有支持字段的属性，则源链接将显示在pdb中。
我猜测源被排除在外，因为没有地方可以在接口和自动实现的属性上设置断点。
我想知道，如果有一些奇特的编译器选项或解决方法，我们可以使用强制PDB文件包含对C＃接口源的引用。
谢谢， 标记
答案 0 :(得分：1)
这个问题没有足够的细节。拍摄时，我猜你通过将项目引用转换为程序集引用来解决缓慢的大规模解决方案的问题。并使用这些项目的Release版本作为参考。
是的，这会阻止任何试图从PDB中查找源代码文件的工具。 .NET项目的发布版本使用PDB的剥离版本，所有源代码文件和行号信息都已从中删除。对于真正的版本构建来说，这是非常正常的事情。通常优化发布内置代码。这会导致代码重新排序，不再匹配源文件中代码的逻辑位置。您从源+行PDB信息获得的任何信息现在往往介于有害和无用之间，您开始在错误的地方寻找问题。
然而不是IDE工具或调试应用时的问题。在这种情况下，优化器会自动禁用。实际上VS中的配置项：工具+选项，调试，常规，“抑制模块加载时的JIT优化”选项。默认情况下已开启。
显然，任何使用PDB的工具在没有机会找到源文件时都会发出紧张性精神病。修复方法是返回原始项目，再次选择Release配置并更改设置：Project + Properties，Build选项卡，向下滚动，Advanced按钮。将“调试信息”组合从“pdb-only”更改为“full”。重建项目。
应该解决你的问题。同样恢复调试器，您可以再次进入源代码。
不要过多地移动文件，你可能会再次残留笨蛋。至少将PDB与DLL保持在同一目录中。如果源代码不再存在于同一目录中，但您在另一个目录中再次检出，那么您必须告诉IDE它。右键单击解决方案，属性，调试源文件设置。