visual studio 2022　「定義へ移動」後の画面が不正常

huahi11115 640 評価のポイント
2025-10-13T05:42:50.6033333+00:00

visual studio 2022で、VB.netとC++/CLIで開発をしています。 VB.netからC++/CLIでビルドしたDLLを参照しています。 構造は簡単ですので、画像を御覧いただければ理解できると思います。

ここで、VB.netのソースを編集してC++/CLIのクラスやメソッドなどを選択して右クリックすると、「定義へ移動」というメニューが出ますが、これを実行した後の画面が「逆コンパイル済み」という形式になり、変数が内部形式だったり、書き換えができないなど、編集操作に意味の無い画面です。 これを、（１）の画面で表示させるための設定方法が知りたいです。 よろしくお願い致します。 下の画像の順番 （１）C++/CLIのソース

（２）VB.netのソース（クラス名の定義に移動）

（３）異常な画面

enter image description here02

03

<モデレーター注>
質問は、第三者を含めて混乱しない様に、一問一答形式にしてください。
1つのスレッド内に複数の質問を投稿しない
回答内容が発散してしまうことを回避する為に、サイトの不具合については字削除させて頂きました。
これらの質問については、必要に応じて新規に質問する様にしてください。

開発者テクノロジ | VB
開発者テクノロジ | VB

Microsoft が開発した、.NET で使用できるオブジェクト指向のプログラミング言語。

モデレーターによって推奨された回答
Anonymous
2025-12-03T08:57:59.9033333+00:00

Hi @huahi11115 ,

Thank you for reporting this behavior. I can confirm that I was able to reproduce the scenario you described

I believe this behavior occurs because of the fundamental differences in how Visual Studio manages metadata and symbol information between managed languages (VB.NET/C#) and C++/CLI. In this case, since the VB.NET project references the DLL file directly, Visual Studio only has access to the compiled binary and its metadata, not the original .cpp/.h files. If the VB.NET project referenced the C++/CLI project directly, Visual Studio might be able to navigate to the real source because it knows exactly where the files are.

Currently, this is expected behavior and is considered by design rather than a bug. There is no guaranteed configuration or setting to force Visual Studio to always open the real C++/CLI source from VB.NET.

If this feature is important for your workflow, we recommend submitting a feature request through the Visual Studio Developer Community. Providing detailed feedback there helps the product team understand demand and consider improvements in cross-language navigation.

We understand that this behavior can be frustrating. Your feedback and feature requests are valuable in helping improve the developer experience in Visual Studio. If you find my answer useful, please kindly mark it as accepted answer.

Thank you!

こんにちは @huahi11115 さん

この動作をご報告いただきありがとうございます。ご指摘のシナリオをこちらでも再現できることを確認しました。

この動作は、Visual Studio がメタデータやシンボル情報を管理する仕組みが、VB.NET/C# などのマネージ言語と C++/CLI で根本的に異なることに起因しています。今回のケースでは、VB.NET プロジェクトが DLL ファイルを直接参照しているため、Visual Studio はコンパイル済みのバイナリとそのメタデータのみを認識し、元の .cpp/.h ファイルにはアクセスできません。もし VB.NET プロジェクトが C++/CLI プロジェクトを直接参照していれば、Visual Studio はファイルの場所を把握しているため、実際のソースコードへナビゲートできる可能性があります。

現時点では、この挙動は仕様通りであり、バグではなく「設計上の動作」とされています。VB.NET から常に C++/CLI の実ソースを開くように強制する設定や構成は保証されていません。

この機能がワークフロー上重要な場合は、Visual Studio Developer Community で機能要望を送信することをお勧めします。詳細なフィードバックを提供することで、製品チームがニーズを把握し、言語間ナビゲーションの改善を検討する助けになります。

この挙動がご不便に感じられることは理解しています。皆さまからのフィードバックや機能要望は、Visual Studio の開発者体験を向上させるために非常に重要です。もしこの回答がお役に立ちましたら、「回答として承認」していただけると幸いです。

ありがとうございます！

この回答は役に立ちましたか?

1 人がこの回答が役に立ったと思いました。
0 件のコメント

1 件の追加の回答

並べ替え方法: 新しい順
最も役に立つ 新しい順 古い順
  1. とっちゃん 715 評価のポイント MVP
    2025-12-03T03:01:40.9833333+00:00

    C#(exe&dllなど複数) + C++/CLI(dll) のプロジェクトでも発生していますし、VS2022以前から発生していた気がします(記憶の限り、VS.NET と呼ばれていたころからあったような＜環境ないので調査できませんが)。

    おそらく .NET/.NET Framework と C++ や C++/CLI では定義位置などの情報の管理方法が異なるため、定義位置を把握できないのだと思います。

    この現象は不具合ではなく動作仕様と思われます。改善してほしいのであれば、要望として挙げていく必要があると思います。

    この回答は役に立ちましたか?

お客様の回答

質問作成者は回答に "承認済み"、モデレーターは "推奨" とマークできます。これにより、ユーザーは作成者の問題が回答によって解決したことを把握できます。