多数の子コントロールを含む WPF アプリがあります。
これらのコントロールの 1 つがサード パーティのライブラリをホストしており、その内部でネイティブ コードを実行し、アクセス違反をスローしてアプリケーションをクラッシュさせます。残念ながら、ライブラリを削除することはできません。
私がやりたいことは、新しい Windows プロセスを起動し、その中でサードパーティのライブラリをホストし、何らかの方法でそれと通信することです。Google Chrome と IE8 がブラウザ プラグインを処理するのとほぼ同じ方法です。
問題は、サードパーティのライブラリが画面に描画する必要があるため、WPF アプリのメイン ウィンドウ内に HTML iframe に相当するものを何らかの方法で配置する必要があることです。
どうやってこれを始めたらいいのかわからない。どんなアドバイスでも大歓迎です。
これは難しい問題ですが、幸いなことに、最近このスペースで少し作業が行われています。
.NET 3.5のSystem.Addin名前空間について聞いたことがありますか？この場合、おそらく役立つ可能性があります。コントロールを別のAppDomainにロードできますが、同じUIに表示できます。すべてを適切に通信させるには、少し作業を行う必要があると思いますが（これまでにこれを行ったことはありません）、それは可能です。
アドインチームからのこの初期の投稿をご覧ください：http：//blogs.msdn.com/clraddins/archive/2007/08/06/appdomain-isolated-wpf-add-ins-jesse-kaplan.aspx
サンプルとヘルパーコードをcodeplexに保持しているようです：http：//clraddins.codeplex.com/
私はこれに非常に興味があります。これが機能するようになったら、これがどのように機能したかをお知らせください。
遅れて来る。それでもこれが必要な場合は、このプロジェクトを見たことがありますか：https ://docs.microsoft.com/en-us/archive/blogs/changov/hosting-wpf-ui-cross-thread-and-cross-process
LOBアプリの複数の外部プロセスで複数のプラグインを実行しています。私のフレームワークは、上記のプロジェクトから生まれました。
おそらく最も簡単なタスクではありません。別の App-Domain でサードパーティのものをホストすることを検討しましたか? そうすれば、別のプロジェクトの手間を省きながら、適切なレベルの分離も得られます。常に更新する必要がありますか、それともアプリケーションの事前定義されたポイントで更新できますか? おそらく、基本的にサードパーティの出力のスクリーンショットを作成し、元のアプリで画像として表示するスキームが可能になるでしょう...