Winforms app like google chrome with multiple processes

Question

Is there anyway to use C# to build a container app where each tab is actually its own process like with Google chrome.

Answer 1

Check this post on the Chromium Blog. Only one process is responsible for the actual rendering to the screen.

Answer 2

You can use the SetParent Win32 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.

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.

(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!)

Answer 3

Yes. You can spawn new processes using System.Diagnostics.Process. Using some form of Inter Process Communication, .Net Remoting for 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.

Answer 4

Without looking too deep into the extensibility stack, you can use the System.Addin namespace 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.

It will have the same functionality as the chrome tabs.

Answer 5

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.

This is supported navtively in WPF. See the MSDN sample Add-In Returns a UI.

Using Windows Forms, it doesn't look like it's natively possible using the System.AddIn APIs. See this post from a System.AddIn architect Jack Gudenkauf.

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

Answer 6

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.

Answer 7

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.

I've included working C# code. It's been tested to work with .NET 2.0, .NET 3.0, and .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 pipes to communicate between processes.

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.

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 control that our users put on their C# or VB.NET forms.

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.

In fact, the exact named pipes code we use is included in the article I mentioned above: 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.

That being said, even with our well-tested Named Pipes wrapper, inter-process communication is hard. So tread carefully.