8
WPF / C＃でIE WebBrowserコントロールの代わりにChromiumを埋め込むためのオプション
Internet ExplorerベースのWPF WebBrowserコントロールには、キーボードとフォーカスの問題、およびメモリリークの問題があります。これらの問題の代替ソリューションとして、HTML編集に基づくWPF / C＃プロジェクトでWebBrowserコントロールの代わりにChromiumをホストするための利用可能なオプションを検討しています。同様の質問がされてい尋ね以前にここに。私は答えを読んで自分の調査を行いましたが、実際に生産品質のプロジェクトで次のオプションのいずれかを使用した人々からさらにフィードバックを得たいと思います。 AwesomiumおよびAwesomium.NET それは非常に適切に見えますが、プロジェクトがオープンソースではなく、完全なソースが簡単に入手できないという事実は好きではありません。また、オフスクリーンレンダリングは私たちが実際に依存しているものではないため、プロジェクトにとってはやり過ぎかもしれません。 CEF用のChromium Embedded Framework（CEF）および.NETバインディング これはおそらく現在利用可能な最良のオプションです。プロジェクトは生きていてアクティブで、現在Chrome v27と同期しているようです。CEF3はChromeマルチプロセスアーキテクチャを使用しています。また、アドビがそれを支持しているようにも見えます。 GoogleのChromeフレーム その本来の目的はIEとFirefoxのHTML5プラグインでしたが、実際にはスタンドアロンのActiveXコントロールとしても機能するため、WPFで使用するためにラップすることができました。内部Webページとの対話に十分なAPIを公開します（onmessage, addEventListener/removeEventListener, postMessage）。GoogleがChrome Frame を廃止する予定であることは承知していますが、ソースはChromiumリポジトリに残ると思います。最新のChromiumコードで更新することは難しくありませんし、これを完全に制御できます。 WebKit .NETラッパー 正確にはChromiumベースではなく、V8エンジンを使用しないため、実際にはオプションではありません。 私が見落としたかもしれない他のオプションはありますか？ 誰かが実際の生産品質のWPFプロジェクトの上記のオプションのいずれかで彼女/彼の経験を共有してくれれば幸いです。統合、ライセンス、または導入の影響はありましたか？ありがとうございました。 [ 編集済み] また、寛大な報奨金を提供することでこの質問を後押ししてくれたartlungにも感謝します。