C# Windows 窗体应用程序，如具有多个进程的 Google Chrome
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/197182/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Windows Forms application like Google Chrome with multiple processes
提问by leora
Is there any way to use C# to build a container application where each tab is actually its own process like with Google chrome?
有什么方法可以使用 C# 构建一个容器应用程序，其中每个选项卡实际上都是自己的进程，就像谷歌浏览器一样？
采纳答案by Jon Skeet
You can use the SetParentWin32 call to do this, but it's really fraught with problems. I had enough troubles getting it all to work nicely using windows from different AppDomains - there'd be even more difficulties with whole extra processes.
您可以使用SetParentWin32 调用来执行此操作，但这确实充满了问题。我在使用来自不同 AppDomains 的 Windows 让它一切正常工作时遇到了足够多的麻烦 - 整个额外进程会遇到更多困难。
Basically there's potentially a lot of communication required between the two processes - things like resizing can become quite painful, as well as what happens if the child app wants to quit etc. It's all doable, but I'd think very carefully before doing it. For a browser it makes a lot of sense (disclaimer: I work for Google) but for most other apps it's really not worth the effort.
基本上，这两个进程之间可能需要进行大量通信 - 诸如调整大小之类的事情可能会变得非常痛苦，以及如果子应用程序想要退出等会发生什么。这一切都是可行的，但我会在做之前非常仔细地考虑。对于浏览器来说，这很有意义（免责声明：我为 Google 工作）但对于大多数其他应用程序来说，这真的不值得付出努力。
(Are the "tabs" you want to create actual .NET apps? If so, as I say this becomes significantly easier - and I can give you a big hint which is that each UI should run its own UI thread from within its own AppDomain. You get really weird effects if you don't do this!)
（是您想要创建实际 .NET 应用程序的“选项卡”吗？如果是这样，正如我所说，这会变得明显更容易 - 我可以给您一个重要提示，即每个 UI 都应该从自己的 AppDomain 中运行自己的 UI 线程。如果你不这样做，你会得到非常奇怪的效果！）
回答by Alexander Kojevnikov
回答by Lars Truijens
Yes. You can spawn new processes using System.Diagnostics.Process. Using some form of inter-process communication(IPC), .NET Remotingfor example, you can communicate between processes. And then you can set the parent of the window/form of your new process to a window (tab) of your first process so it appears there.
是的。您可以使用System.Diagnostics.Process生成新进程。使用某种形式的进程间通信(IPC)，例如.NET Remoting，您可以在进程之间进行通信。然后您可以将新进程的窗口/窗体的父级设置为第一个进程的窗口（选项卡），以便它出现在那里。
回答by Erick Sgarbi
Without looking too deep into the extensibility stack, you can use the System.Addinnamespace to build an application that inherently can create addins as visual individual tabs and set each tab/addin as an out process and this is a behavior out of the box.
无需深入了解可扩展性堆栈，您可以使用System.Addin命名空间构建一个应用程序，该应用程序本质上可以将加载项创建为可视的单个选项卡，并将每个选项卡/加载项设置为输出进程，这是一种开箱即用的行为。
It will have the same functionality as the chrome tabs.
它将具有与 chrome 标签相同的功能。
回答by Judah Gabriel Himango
The System.AddIn APIs introduced in .NET 3.5 lets you use UI controls in separate AppDomains. With some hoop jumping, you can make it work in separate processes, too.
.NET 3.5 中引入的 System.AddIn API 允许您在单独的AppDomains 中使用 UI 控件。通过一些跳圈，您也可以使其在不同的进程中工作。
This is supported navtively in WPF. See the MSDN sample Add-In Returns a UI.
这在 WPF 中得到了自然支持。请参阅 MSDN 示例加载项返回 UI。
Using Windows Forms, it doesn't look like it's natively possible using the System.AddIn APIs. See this postfrom a System.AddIn architect Hyman Gudenkauf.
使用 Windows 窗体，它看起来不像使用 System.AddIn API 本身是可能的。见这个帖子从System.AddIn建筑师HymanGudenkauf。
However, there is a workaround for WinForms. You can make this work with a little hack: See the BCL team's blog Support for Windows Forms in System.AddIn Hosts and Add-ins
但是，WinForms 有一个解决方法。您可以通过一些小技巧完成这项工作：请参阅 BCL 团队的博客Support for Windows Forms in System.AddIn Hosts and Add-ins
回答by Maurice Flanagan
My product, WindowTabs.com, kind of does this. You need to use Win32 - I suggest you avoid using SetParent because you end up attaching the thread input. Instead, draw the tabs above the windows and use SetWindowPos to move the windows as a group. Also, some third party controls like Infragistic don't function correctly if you parent the form at a Win32 level.
我的产品WindowTabs.com就是这样做的。您需要使用 Win32 - 我建议您避免使用 SetParent，因为您最终会附加线程输入。相反，在窗口上方绘制选项卡并使用 SetWindowPos 将窗口作为一个组移动。此外，如果您在 Win32 级别设置窗体的父级，某些第三方控件（如 Infragistic）将无法正常工作。
回答by Wyatt O'Day
For those of you interested in the actual implementation of multi-process apps, I wrote an article about it on my website: Multi-process C# app like Google Chrome.
对于那些对多进程应用程序的实际实现感兴趣的人，我在我的网站上写了一篇关于它的文章：Multi-process C# app like Google Chrome。
I've included working C# code. It's been tested to work with .NET 2.0, .NET 3.0, and .NET 3.5.
我已经包含了工作 C# 代码。它已经过测试，可与 .NET 2.0、.NET 3.0 和 .NET 3.5 一起使用。
Named pipes: How processes talk to eachother
命名管道：进程如何相互通信
Since your question specifically asked about Google Chrome you should know that Chrome uses named pipesto communicate between processes.
由于您的问题专门询问了 Google Chrome，因此您应该知道Chrome 使用命名管道在进程之间进行通信。
In the C# source code I mentioned above there are 2 files: PipeServer.cs & PipeClient.cs. These 2 files are thin wrappers of the Named Pipes Windows API. It's well tested because hundreds of thousands of people use our products. So stability & robustness were a requirement.
在我上面提到的 C# 源代码中有 2 个文件：PipeServer.cs 和 PipeClient.cs。这两个文件是命名管道 Windows API 的薄包装。它经过了很好的测试，因为成千上万的人使用我们的产品。所以稳定性和鲁棒性是一个要求。
How we use the multi-process design
我们如何使用多进程设计
Now that you have all the pieces to the puzzle, let me tell you how we use Multi-process design in our app.
现在您已经掌握了所有拼图，让我告诉您我们如何在我们的应用程序中使用多进程设计。
Our product is a complete updater solution. That is, there's a program that builds update patches(not relevant to the discussion), a standalone updater program (wyUpdate - also open source), and an Automatic Updater controlthat our users put on their C# or VB.NET forms.
我们的产品是完整的更新程序解决方案。也就是说，有一个构建更新补丁的程序（与讨论无关），一个独立的更新程序（wyUpdate - 也是开源的），以及我们的用户放在他们的 C# 或 VB.NET 表单上的自动更新程序控件。
We use named pipes to communicate between the standalone updater (wyUpdate) and the Automatic Updater control sitting on your program's form. wyUpdate reports progress to the Automatic Updater, and the Automatic Updater can tell wyUpdate to cancel progress, to start downloading, start extracting, etc.
我们使用命名管道在独立更新程序 (wyUpdate) 和位于程序窗体上的自动更新程序控件之间进行通信。wyUpdate 向自动更新器报告进度，自动更新器可以告诉 wyUpdate 取消进度、开始下载、开始解压等。
In fact, the exact named pipes code we use is included in the article I mentioned above: Multi-process C# app like Google Chrome.
事实上，我们使用的确切命名管道代码包含在我上面提到的文章中：Multi-process C# app like Google Chrome。
Why you shouldn't use the multi-process design
为什么不应该使用多进程设计
As Jon Skeet mentioned above, you should have a specific need for the multi-process model. In our case we wanted to keep the updater completely separate from your program. That way if the updater somehow crashed, your program would remain unscathed. We also didn't want to duplicate our code in 2 places.
正如上面提到的 Jon Skeet，您应该对多进程模型有特定的需求。在我们的例子中，我们想让更新程序与您的程序完全分开。这样，如果更新程序以某种方式崩溃，您的程序将毫发无损。我们也不想在 2 个地方复制我们的代码。
That being said, even with our well-tested Named Pipes wrapper, inter-process communication is hard. So tread carefully.
话虽如此，即使使用我们经过良好测试的命名管道包装器，进程间通信也很困难。所以谨慎行事。
