Part of Microsoft’s Enterprise Library is an Updater block. It’s not really clear from the MSDN introduction page what this is and how it works.
Essentially, it’s code that works like Windows Update. How does it work? At a high level:
- Your computer (client) connects to the Windows Update machine with the updates (server)
- The client asks: What new updates are there for me?
- The server sends: Here’s a list of updates.
- The client downloads each update (when bandwidth is available)
- The client activates each update
As you can see, it’s a server-client architecture. One of the immediate benefits is that it uses pull, not push — meaning if your client is behind corporate firewalls, you can still deliver updates. But like all pull technology, you can’t guarantee when (or even if) updates will happen.
Let’s drill into some details.
Under the Hood: How Updates Work
How exactly do we encapsulate this notion of an update? What exactly is an update?
In the Updater block, an update is essentially a file you want to deliver to the client, with a possible execution action.
- A file can be any file — a ZIP file, an EXE file, a batch file, text file, doc file, or anything else.
- An execution action is any action you can run. For example, you can invoke Internet Explorer, or 7-Zip; you can run your downloaded EXE or batch file; or open your downloaded text file in Notepad.
All of this information is collected into a “manifest” XML file on the server. Here’s a sample of an update that downloads
C:\Temp\Updater and then executes it:
You can see a couple of things from this file:
- A description of what this update contains
- An application that we’re providing as an update (SimpleApplication.exe)
- The script to execute when the update completes (
- The location to download the update to (
- The location on the server where we can grab the file from (
- The exact path of the remote file to download (
That’s really (surprisingly) all there is to it. When you run the updater, it will download this file; if it hasn’t run this update before (successfully), it will download and execute
That’s really it. The update is queued and executed later. The next time you run the updater, it’ll check again for any new files in the manifest, and download any new updates.
Server-Side Stuff: IIS
On the server side, you need to actually host the manifest file somewhere where clients can access it. If you’re doing everything locally (and even if you’re not), the easiest way to do this is add a virtual directory to IIS to host the manifest file and the update files.
In our example, we’ll have the virtual directory
MyAwesomeUpdateServer somewhere; it will have inside a manifest.xml file, along with the
SimpleApplication.exe file under
I’m sure this can work with Apache or any other web-server, but I leave that as an exercise to you.
How Transferring Works: BITS
BITS, which evolved out of Windows Updater, is a smart downloader. If your maximum download speed is 100kb/s, and you’re currently downloading at 90kb/s, it will utilize only the remaining 10kb/s to download the updates. BITS also handles resuming downloads (even across client reboots), and some other stuff; you can read more about it here, at MSDN.
How do you add updates for multiple applications, and multiple updates per application? That’s beyond the scope of this article, so until next time! (Actually, that’s beyond the scope of my knowledge at this time, so when I figure it out, I’ll post another post about it.)