C# を使用して、Google chrome のように各タブが実際には独自のプロセスであるコンテナー アプリケーションを構築する方法はありますか?
7 に答える
SetParent Win32 呼び出しを使用してこれを行うことができますが、実際には問題がたくさんあります。さまざまな AppDomains のウィンドウを使用してすべてをうまく機能させるのに十分な問題がありました。余分なプロセス全体ではさらに困難になるでしょう。
基本的に、2 つのプロセス間で多くの通信が必要になる可能性があります。サイズ変更などは非常に苦痛になる可能性があり、子アプリが終了したい場合なども同様です。すべて実行可能ですが、実行する前に非常に慎重に検討したいと思います。ブラウザーの場合は非常に理にかなっていますが (免責事項: 私は Google で働いています)、他のほとんどのアプリでは、努力する価値はありません。
(「タブ」は実際の .NET アプリを作成したいですか? もしそうなら、私が言うように、これは非常に簡単になります。そして、各 UI が独自の AppDomain 内から独自の UI スレッドを実行する必要があるという大きなヒントを与えることができます。 . これをしないと、本当に奇妙な効果が得られます!)
マルチプロセスアプリの実際の実装に興味のある方のために、私は自分のWebサイトにそれに関する記事を書きました:Google ChromeのようなマルチプロセスC#アプリ。
動作するC#コードを含めました。.NET 2.0、.NET 3.0、および.NET3.5で動作することがテストされています。
名前付きパイプ:プロセスが互いにどのように通信するか
あなたの質問は特にGoogleChromeについて尋ねたので、 Chromeはプロセス間で通信するために名前付きパイプを使用することを知っておく必要があります。
上記のC#ソースコードには、PipeServer.csとPipeClient.csの2つのファイルがあります。これらの2つのファイルは、Named PipesWindowsAPIのシンラッパーです。何十万人もの人々が私たちの製品を使用しているので、それはよくテストされています。したがって、安定性と堅牢性が要件でした。
マルチプロセス設計の使用方法
パズルのピースがすべて揃ったので、アプリでマルチプロセスデザインをどのように使用するかを説明します。
当社の製品は完全なアップデータソリューションです。つまり、更新パッチをビルドするプログラム(説明には関係ありません)、スタンドアロンのアップデータープログラム(wyUpdate-これもオープンソース)、およびユーザーがC#またはVB.NETフォームに配置する自動アップデーターコントロールがあります。
名前付きパイプを使用して、スタンドアロンアップデーター(wyUpdate)とプログラムのフォームにある自動アップデーターコントロールの間で通信します。wyUpdateは進行状況を自動アップデーターに報告し、自動アップデーターはwyUpdateに進行状況のキャンセル、ダウンロードの開始、抽出の開始などを指示できます。
実際、私たちが使用する正確な名前付きパイプのコードは、前述の記事「Google ChromeのようなマルチプロセスC#アプリ」に含まれています。
マルチプロセス設計を使用すべきでない理由
Jon Skeetが前述したように、マルチプロセスモデルには特別なニーズが必要です。私たちの場合、アップデーターをプログラムから完全に分離したままにしておきたいと思いました。そうすれば、アップデーターが何らかの理由でクラッシュした場合でも、プログラムは無傷のままになります。また、コードを2か所に複製したくありませんでした。
そうは言っても、十分にテストされた名前付きパイプラッパーを使用しても、プロセス間通信は困難です。慎重に踏みます。
Chromium ブログのこの投稿を確認してください。画面への実際のレンダリングを担当するプロセスは 1 つだけです。
私の製品WindowTabs.comは、これを行います。Win32 を使用する必要があります。スレッド入力をアタッチすることになるため、SetParent の使用は避けることをお勧めします。代わりに、ウィンドウの上にタブを描画し、SetWindowPos を使用してウィンドウをグループとして移動します。また、Win32 レベルでフォームを親にすると、Infragistic などの一部のサード パーティ コントロールが正しく機能しません。
.NET 3.5 で導入された System.AddIn API を使用すると、個別のAppDomainsで UI コントロールを使用できます。いくつかのフープジャンプを使用すると、別のプロセスでも機能させることができます。
これは、WPF でネイティブにサポートされています。MSDN のサンプルアドインが UI を返す を参照してください。
Windows フォームを使用すると、System.AddIn API をネイティブに使用できるようには見えません。System.AddIn アーキテクトの Jack Gudenkauf によるこの投稿を参照してください。
ただし、WinForms には回避策があります。ちょっとしたハックでこれを機能させることができます。BCL チームのブログSystem.AddIn Hosts and Add-ins での Windows フォームのサポートを参照してください。
はい。System.Diagnostics.Processを使用して、新しいプロセスを生成できます。たとえば、何らかの形式のプロセス間通信(IPC) ( .NET Remoting ) を使用して、プロセス間で通信できます。次に、新しいプロセスのウィンドウ/フォームの親を最初のプロセスのウィンドウ (タブ) に設定して、そこに表示することができます。
拡張性スタックを深く調べなくても、System.Addin名前空間を使用して、視覚的な個別のタブとしてアドインを作成し、各タブ/アドインをアウトプロセスとして設定できるアプリケーションを構築できます。これは、すぐに使用できる動作です。
クロームタブと同じ機能になります。