CLR をインスタンス化し、カスタム appDomainManager を作成し、マネージ アセンブリをネイティブ プロセスにロードするための呼び出しを提供するネイティブ C++ アプリケーションにホスティング インターフェイスを追加しました。私のネイティブ C++ LoadDLL() 関数では、マネージ アセンブリに対して失敗 (NULL) を返すと想定していた LoadLibrary(dllPath) を呼び出すことで、.net と C++ の着信 dll をテストできると期待していましたが、代わりにハンドルを返しています (これは、現在アンマネージ プロセスで実行されている CLR がありません)。これは、マネージ アセンブリでのアンマネージ LoadLibrary() 呼び出しの正常な動作ですか?
LoadLibrary がマネージ アセンブリでテストするための適切なエントリ ポイントをどのように見つけることができるのか、私にはよくわかりません。問題を解決する (1 つの可能な) 方法と、実装を計画している方法は、CLR インスタンスを使用して .net リフレクション API にアクセスし、最初に DLL が管理されているかどうかを確認することです...しかし、私はLoadLibrary() が失敗を返さないという事実に戸惑っています。ここで何が欠けているのかを理解したいと思います。動作は未定義ですか、常にハンドルを返す必要がありますか、それともマネージ アセンブリの構成に依存しますか? 参照へのリンクは大歓迎です。
編集：
コメントで回答された質問、終了。