少なくとも7つのアセンブリが必要であり、Appdomain分離機能が機能し始める前に、アドインのデータモデルをリモート処理で処理できるデータ型に制限します。とても複雑です！System.AddInチームのブログは、COMのメンタルモデルを再作成しようとしていたことを示唆しています。このモデルは、そもそもよく理解できておらず、メリットが売りに出されていません。（COMが非常に優れている場合、なぜそれは死んでいるのですか？-レトリックの質問です。）レガシーCOMとミラーリングまたは相互運用する必要がない場合（VSTOがSystem.AddInを使用するように）、ロードをロードするいくつかのクラスを作成することは可能ですか？新しいAppDomain？
私は自分でディスカバリーコードを書くことができます、私は以前にそれをしました、そして私はGACのアセンブリを反復するのが好きではないので、素朴な実装はかなり速いです！
だから私の特定の質問は、AddInsがいくつかのコードリモーティングスニペットで提供するAppDomain分離を取得できますか？それらは何でしょうか？
あなたの質問に対する答えがサイトの条件を満たしているかどうかは完全にはわかりません-解決策はありません。
はい、リモーティングはあなたのために行われるので簡単です。しかし、それは高度に制御されており、あなたが特定したように、それをすべて一緒に配管するために少しの作業が必要です。検出プロセスによって吐き出されたキャッシュファイルも、ほとんど歓迎されません。
System.AddInは分離に優れています。これは、実際には、堅牢で柔軟な方法で最初からまとめるのに少しお尻です。クロスプロセスホスティングと、あるドメインから別のドメインへのユーザーWPF要素の非常に単純な受け渡しをサポートします。
ただし、覚えておくべきことの1つは、MAFの対象読者は、2つのアプリケーションを相互に接続しようとしている対象者ではないということです。これは、プラグイン可能でありながら安全なシステムを必要とする開発者を対象としています（クロスプロセスホスティングは、ルートアプリケーションを未処理の例外から保護し、アプリドメインは、定義されたセキュリティで潜在的に外部のコードを実行できるようにします）。ほとんどのコミュニケーションから、System.Runtime.RemotingまたはWCFに直接向かいます。
System.AddInを続行する場合は、VisualStudio用のパイプラインビルダープラグインを検討してください。
結論として、Remotingを使用してSystem.AddInを分離することはできますが、適切なシステムを取得するには、数個以上のスニペットが必要になります。私はそれを自分で複製しようとしていて、リモートインターフェイスコンポーネント全体につまずきます-System.AddInが問題なく実行できることです。
System.Add をしばらくいじった結果、これは Microsoft が使用する 1 回限りの特別な目的のソリューションとして追加されたものであると確信しました。.NET フレームワークのコア部分に昇格したことに驚いています。一般的な .NET フレームワーク コンポーネントに必要な改良と洗練が欠けているようです。
.NET マネージ アドインをそれほど労力を必要とせずに作成する別の方法を見つけたいと思います。