私は興味深い状況にあり、可能かどうかさえわからないことをしようとしています。
リフレクションを介してアセンブリをロードし、そのアセンブリで特定のメソッドを呼び出す .NET 2.0 プロジェクトがあります。環境で .NET 3.5 の使用を開始することを検討していますが、この「ホスト」アプリケーションに関するリスクを最小限に抑えたいと考えています。したがって、.NET 2.0 プロジェクトから .NET 3.5 アセンブリをロードしようとしていました。3.5 は 2.0 フレームワークの拡張であるためです。
さて、これを行うと、次のエラーが発生します。
ファイル 'MyDllNameHere.DLL' の形式が無効です
だから、見た目からしてありえない。誰でもこれを確認できますか？回避策はありますか?
次に、2 番目の質問です。それが不可能な場合、ホストを .NET 3.5 で再コンパイルしてから、リフレクション経由で .NET 2.0 アセンブリをロードできますか?
それは不可能です。アセンブリ形式は2.0と3.5の間で変更されていません。.NET 3.5は、まったく同じCLRバージョンとアセンブリメタデータ形式を使用します。バージョン間の唯一の違いは、新しいアセンブリのセット、特にWPF、WCF、およびLinqをサポートするアセンブリのセットです。これらの新しいアセンブリからタイプを参照する3.5アセンブリを読み込もうとすると、非常に異なるエラーメッセージが生成されます。3.5アセンブリが見つからないと文句を言います。
.NET 1.xバージョンのCLRを実際に実行している場合、このような例外が発生しますが、2.0アセンブリ形式は変更されました。また、例外メッセージとの一致はよくありませんが、コードが64ビットバージョンのフレームワークで実行されていて、アセンブリをロードしようとすると、アセンブリ形式について不平を言う例外が発生します。 32ビットのネイティブコードが含まれています。またはその逆。
さて、私はこれに対するより詳細な回答をここに投稿したかったので、その後いくつかの詳細を見つけました. まず第一に、問題の適切な出発点を指摘してくれた nobugs に感謝します。
まず第一に、nobugs は正しかったです。私が遭遇したエラー メッセージは適切なエラー メッセージではありませんでした。私のコードは、2.0 ホスト アプリケーションではなく、1.1 ホスト アプリケーションによって誤って呼び出されていました。
2.0 ホスト アプリケーションに切り替えるとすぐに、真の魔法が始まりました。リフレクションを介してクラスをロードし、特定のメソッドを実行する 2.0 アプリケーションから、LINQ を使用する .NET 3.5 アセンブリ内に含まれるメソッドを正常にインスタンス化して実行することができました。
完璧に動作します！
2.0 フレームワークには存在しなかったものを参照する可能性があるため、3.5 アセンブリを 2.0 に読み込むことはできません。
あなたが言ったように逆にすることもできます.3.5は2.0アセンブリを問題なくロードするはずです.