C# と VB のプロジェクトを 1 つのソリューションに結合しているときに、MS がメソッドの定義に正しく移動できなかったという事実に、私は完全に唖然としました。VB から C# に移動しようとしている場合は、"オブジェクト エクスプローラー" が表示され、C# から VB に移動している場合は、メタデータ ファイルが生成されます。
正直なところ、特に同じ CLR を使用していると思われる場合、異なる言語間でジャンプすることの何がそんなに複雑なのでしょうか?
これがなぜなのか、または回避策があるかどうか、誰かが知っていますか? 彼らはVS 2008でそれを正しく理解しましたか?
@キース、あなたの答えは正しいかもしれません。マイクロソフトがこれをひどく台無しにしたことに、私は本当に唖然としています。誰にも回避策のアイデアはありますか?
@Mladen Mihajlovic - それはまさに私が説明している状況です。自分で試してみてください。プロジェクトの参照は、わずかな違いもありません。
これは両方の言語に共通です。
これは、ユーザーをアップグレードするために予想される動作と一致させるための意図的なメカニズムです。C＃の方法は正しい情報を提供しますが、VBの方法はVBAまたはVB6のユーザーが期待するものです。
動作はVS2008でも同じです。
これらは外部プロジェクトのルールです。同じソリューションに含まれている場合は、どちらもコードに移動する必要があります。
その通りです。VBプロジェクトはC＃プロジェクトを外部として扱い、その逆も同様です。一方のコードからもう一方のコードに移動することはできません。これを最新のVS2008でテストしましたが、まだ問題です。
また、完全なメタデータを取得できません。C＃コードにメソッドを追加すると、C＃アセンブリをコンパイルするまでVBのインテリセンスに表示されません。
これは、コンポーネントがツールストリップに表示される方法と似ているため、コードへの通常のナビゲート機能は、一般的なコンパイラを使用したコードの機能であり、他のすべては何らかのリフレクションを使用していると思います。
PDBをビルドしている限り、ファイルを見つけることができるはずですが、リリースビルドをサポートするためにも必要なので、そうではないと思います。PDBルックアップなしではコード行を見つけることができませんでした。
参照先がDLL ファイルだけでなく、VBプロジェクトであることを確認してください。
これは既知の問題です。回避策は 2 つあります。使用ctrl+,するか、この機能を追加するプラグインを使用します。たとえば、resharper (この機能を に追加しますF12)。