2 months ago we released wyBuild & wyUpdate v2.5. This release adds a free automatic updater control for C# & VB.NET apps. And because we wanted to keep things simple we left the wyUpdate.exe to do all the hard work (checking, download, installing) in the background while the AutomaticUpdater control is visible on your app’s main form.
We wanted the AutomaticUpdater to be able to control the update steps, view progress, and cancel the updating. But we also wanted to keep all the updating logic in the wyUpdate.exe. For this to be successful we needed a way for the AutomaticUpdater control to talk to wyUpdate.exe while it’s running.
The Answer: Inter-process communication (IPC)
Inter-Process communication is a fancy computer science way of saying “processes that can talk to each other”. Google Chrome uses IPC to communicate between tabs of the browser & plugins. It’s a simple way to keep parts of your program isolated from crashes.
For instance, if a tab of Google Chrome crashes only that single tab is killed. The rest of your tabs will continue to function normally.
Lots of bad ways to do IPC
Now that you know what inter-process communication is, let me tell you the worst ways to do it.
- Shared memory: Difficult to set up & difficult to manage.
- Shared files / registry: Very slow due to the writing & reading to/from disk. Difficult to manage.
- SendMessage / PostMessage: Locks up the UI thread while the message is processed. Messages are limited to integer values. Can’t communicate from a non-admin process to an admin process. Assumes that your processes have a window.
Inter process communication using named pipes is what Google Chrome uses and what we use for wyUpdate and the AutomaticUpdater control. Let me teach you about named pipes.
“Like Mario’s pipes?”
Exactly like Mario’s pipes. Except, instead of jumping Mario through the pipe, you push data through the pipe:
What do you put in the pipe?
You can transfer any data between your processes. So what data should your transfer? The answer is “it depends”. The rule of thumb is to keep it short, and keep it simple. Here’s what we do with the named pipe between wyUpdate and the AutomaticUpdater control sitting on your application:
- Command codes: The AutomaticUpdater can command wyUpdate to check for updates, download the updates, extract the update, and install the update, or cancel any current progress.
- Responses: wyUpdate can tell the AutomaticUpdater if there’s an update available, what changes there are in the update, and the progress of the current step (e.g. downloading).
With this simple setup the AutomaticUpdater control that’s on your application is completely isolated from wyUpdate.
Get the C# source
Download the named pipes C# source. It works with .NET 2.0, 3.0, 3.5 on Windows 2000 – Windows 7.
There are two files that do all the work: PipeServer.cs and PipeClient.cs. We use the PipeServer.cs file inside wyUpdate, and we use the PipeClient.cs file inside the AutomaticUpdater control.
Also included in the zip file is a simple messaging program to demonstrate communication between two separate processes:
Tell me what you think in the comments. I want to hear from you.
Subscribe to Wyatt Says...
Subscribe to the 'Wyatt Says...' RSS Feed and keep up to date on on my articles on updaters, usability, open source C# components, and soon anti-piracy.
- 7 days of Windows 7: Tips, Tricks, and Controls to get your C# and .NET apps Windows 7 ready October 14th - October 22nd
- Quick C# Tip: Adding animation to your Windows Forms app
- Building a Great Updater Part 2: Adobe Updater, Inconsistency is Thy Name