複数の MFC 拡張 DLL を使用する MFC アプリケーションがあります。このアプリ (および他のいくつかの同様のアプリ) が .net フレームワークの一部にアクセスできるようにしたいと考えています。私は、必要な .net 作業を実行する C# ライブラリを作成しました。MFC dll を作成して、アプリからすべての C++/CLI コードを非表示にできるようにしたいと考えていました。アプリは純粋な MFC アプリのままで、C++/CLI コードのみが新しい MFX 拡張 DLL に含まれます。ただし、これを行ったときに、新しい MFC C++/CLI dll にアクセスするとアプリがクラッシュしました。アプリに C++/CLI コードを配置すると、問題なく動作し、C# までずっとデバッグできます。
dllのアイデアが機能しない理由を誰かが理解していますか?
ありがとう
同様の問題に遭遇したと思います。私のセットアップは似ていました-純粋なMFC DLLを備えた純粋なMFCアプリは、C ++ / CLI DLLとやり取りしました。すべてが正常に実行されますが、終了時にクラッシュします。この問題は、CppUnit を使用して純粋な MFC DLL をテストしているときに悪化しました。
デバッグ中に、バグが原因で、C++ コードが終了時にアクセス違反 (ダングリング ポインターを介して参照されるオブジェクト) の初回例外をスローしていることがわかりました。現在、C++ ランタイムは終了時にこれらの違反を無視しますが、CLR は無視しません。CLR ランタイムが未処理の例外をスローし、プログラムまたは単体テストがクラッシュしたように見せかけます。
あなたの問題は異なるかもしれませんが、私が抱えていた問題と非常によく似ています。
純粋なネイティブ コードからマネージド アセンブリを参照することはできません。コンシューマ (プロジェクト全体または特定のファイル) で /clr スイッチを切り替えるか、何らかの相互運用を行う必要があります。
コンシューマがピュア ネイティブであると言うことができる相互運用オプションの 1 つは、COM Callable Wrapperを介してマネージ アセンブリを呼び出すことです。
MFC dll プロジェクトは C# ライブラリを参照し、C# ライブラリへのインターフェイスを処理する /clr でコンパイルされたファイルが 1 つあります。私は実際に実行時にこの動作を見たことがありますが、MFC dll または C# コードにデバッグすることはできませんでした。ただし、ほとんどの場合、安定しておらず、クラッシュするようには見えません。