当您将 C# 和 VB 项目组合到一个解决方案中时,MS 无法正确导航到方法的定义,这一事实让我感到非常震惊。如果您尝试从 VB 导航到 C#,它会打开“对象资源管理器”,如果从 C# 导航到 VB,它会生成一个元数据文件。

老实说,在不同语言之间跳转有何复杂之处,特别是如果它们使用相同的 CLR?

有谁知道这是为什么,或者是否有任何解决方法?他们在 VS 2008 中做对了吗?


@Keith,恐怕你的答案可能是对的。我真的很惊讶微软把这件事搞砸了这么严重。有人对解决方法有任何想法吗?


@Mladen Mihajlovic - 这正是我所描述的情况。自己尝试一下;项目参考不会产生任何影响。

有帮助吗?

解决方案

这对于两种语言都是通用的。

  • VB.Net 中的 F12 始终将您带到对象浏览器
  • C# 中的 F12 总是带您到元数据定义

这是一种有意尝试匹配升级用户的预期行为的机制。C# 方式为您提供正确的信息,但 VB 方式是 VBA 或 VB6 用户所期望的。

VS2008 中的行为相同。

这些是外部项目的规则,如果代码位于同一解决方案中,则两者都应该将您带到代码。


你说得很对 - VB 项目将 C# 项目视为外部项目,反之亦然 - 你无法从一个项目中的代码导航到另一个项目。我已经在最新的VS2008中测试过了,仍然是一个问题。

它也无法获得完整的元数据。将方法添加到 C# 代码中,直到编译 C# 程序集后,该方法才会出现在 VB 的智能感知中。

这与组件在工具条中的显示方式类似,因此我认为正常的代码导航功能是具有通用编译器的代码的一个功能,其他所有内容都使用某种反射。

只要您仍在构建 PDB,它就应该能够找到这些文件,我想它不会,因为他们也需要它来支持发布版本。如果没有 PDB 查找,它就无法找到该代码行。

其他提示

确保您的引用是 VB 项目 而不仅仅是一个 DLL 文件。

这是一个已知问题, ,解决方法有两个:使用 ctrl+, 或者使用一些添加此功能的插件,例如 resharper (它将在 F12).

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top