Windows Forms application like Google Chrome with multiple processes

Question

Is there any way to use C# to build a container application where each tab is actually its own process like with Google chrome?

Answer 1

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 2

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.