同じボックスで 2 つの CLR を実行できるようになりましたが、どうすれば相互に「対話」できるでしょうか?
GUI が .NET 2.0 CLR で実行されており、スクリプトが .NET 4.0 CLR で実行されているとします。たとえば、4.0 環境から 2.0 ベースの GUI を変更する方法はありますか?
この手法を使用して .NET C# REPL 環境を別の .net プロセスに挿入すると、まさにこの問題が発生します:ビデオ: Injecting C# DLLs into Managed (C#) and Unmanaged (C++) processes
注: Reddit で同様の質問をしましたが、そのバージョンには多数の参照が含まれており、Side-by-Side 実行と CLR ホスティングのトピックに興味がある場合に役立ちます。
通常、2 つの個別の CLR のインプロセス ホスティングは、COM ワールドでのみ行われます。拡張性などのために COM を使用している場合、適切なランタイムが読み込まれます。このシナリオでは、CLR オブジェクトは COM を介して相互に "通信" できます。これは、COM が相互運用性に関するすべてであるためです。
ピュア マネージ アプリケーションは常に 4.0 CLR で実行されます。したがって、2.0 アセンブリをロードする 4.0 アプリケーションは、CLR 4 で 2.0 アセンブリを実行することになります。
詳細については、CLR Inside Out: In-Process Side by Side の記事を参照してください。これについて詳しく説明しています。
あなたの具体的な例については：
GUI が .NET 2.0 CLR で実行されており、スクリプトが .NET 4.0 CLR で実行されているとします。たとえば、4.0 環境から 2.0 ベースの GUI を変更する方法はありますか?
4.0 アセンブリを直接ロードしようとすると、失敗します。これをロードするには、COM 相互運用機能を使用する必要があります。この場合、すべての通信は COM 経由で行われます。4.0 GUI アプリケーションは 2.0 の「スクリプト」をロードできますが、4.0 ランタイムでロードされます。
主に 2 つの方法があり、1 つは疎結合または密結合です。
疎結合システムでは、何らかの形式のバインディング (JSON、XML、SOAP) を使用してデータをやり取りします。このシステムの利点は、アプリと対話することを考えていなかったかもしれない将来、他のプログラムを使用できることです。
密結合された他の方法では、プラグインを使用したり、Windows メッセージ ポンプをいじってメッセージをやり取りしたりできます。また、Windows Communication Frameworkもご覧ください。