The wyDay blog is where you find all the latest news and tips about our existing products and new products to come.
In today’s article I’m going to talk about an interesting problem: detecting .NET assemblies. More than that, I’ll be talking about detecting some features of .NET assemblies and how you can expand and mold our code for your own uses. The code’s at the bottom of the article, it’s written in C# and licensed under the BSD license. Go get it.
I’ve seen this question pop up in a few different forms:
And the list goes on and on. But this raises the question…
We detect .NET assemblies because we respect humans’ time. Let me explain.
When wyUpdate (our open source updater) installs updates it can do a few things beyond simple patching, registry changing, and file copying. Namely it can:
Which means wyUpdate needs to know whether the executable (or dll) is a .NET assembly, whether it’s strong signed, and what platform target it is (i.e. x86, x64, or Any CPU).
We could ask the user for every file, but that’s such a hassle. Who wants to waste time checking boxes for every exe and dll in their project? Rather than wasting the users’ time we quickly scan the .dll and .exe files for their details when the update is built inside wyBuild.
Do not use LoadLibrary(), or Assembly.Load() functions to load an assembly in memory to then parse it. This breaks when you have an x86 process trying to a load an x64 assembly (or vice versa).
Instead of using LoadLibrary (or one of its brethren) we’ll just treat the executables as dumb files. That is, just run a simple loop over the file and skip over the unneeded parts. You can check out the C# code posted at the bottom of this article, but you should be aware of 2 resources we used when designing the .NET detection algorithm:
The PECOFF spec gives you the general layout of .exe and .dll files, and the CLI Partition II gives .NET specific features that we detect. Namely, is the assembly strong signed, is it built for Any CPU or x86 alone, and what base version of the .NET framework is it built for (2.0 or 4.0).
Also, when you check out the code, notice how the code handles PE32 files versus how it handles PE32+ files. That is to say, 32-bit assemblies have a subtly different layout than 64-bit assemblies.
If you find this code useful, tell me how you’re using it in the comments.
Download the AssemblyDetails C# source. It works with .NET 2.0, 3.0, 3.5, 4.0.
AssemblyDetails ad = AssemblyDetails.FromFile(filename); // ad == null for non .NET assemblies if (ad != null) Console.WriteLine(Path.GetFileName(filename) + ": " + ad.CPUVersion + ", " + ad.FrameworkVersion); else Console.WriteLine(Path.GetFileName(filename) + ": Not a .NET 2.0+ executable.");
Update 7/3/2010: There was a slight bug in the first version. Re-download the code.
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.
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.
Now that you know what inter-process communication is, let me tell you the worst ways to do it.
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:
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:
With this simple setup the AutomaticUpdater control that’s on your application is completely isolated from wyUpdate.
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.
This week I was doing work on LimeLM that involved virtual machines. In particular preventing piracy in an environment where the whole PC can be duplicated bit-for-bit. As you can imagine this meant installing and using many virtual machines; VMware, Virtual PC, Virtual Box, Hyper-V, Parallels, and every other obscure VM.
You’re seeing this right – 4 windows stacked on top of one another. They’re even polite enough to welcome me twice.
The worst part is that I still haven’t read what the dialogs say – and this is even after I cropped & arranged the dialogs in Photoshop, proof-read this article 3 times, and written this very sentence. They could say some pretty vulgar things and I wouldn’t even know.
If a dialog has more than 3 words I just look at the buttons and guess what the dialog says. Here’s what I read:
I clicked OK on the last dialog, and a new dialog popped up:
Oh God, they’re breeding. I’m sure “Copyright Notice” is real page-turner, but I have better things to do.
By this point I’ve forgotten what Parallels Workstation is. I think it’s a dialog generating machine.
What can we learn from Parallels’ horrific design?
Parallels’ first-run faults seem easy to apply for web & desktop developers alike. But if you clear the front door – let users actually use your program – will you convert more trial users to paying users? What if you clutter the first run – do users care?
Yes, they do.
In wyBuild’s early betas (back when it was still called InstantUpdate Designer) I ran a split test comparing how long a person used wyBuild. Group A had a version of wyBuild with crap similar to Parallels Workstation; the user had to dismiss a couple of “useful” dialogs before they could use wyBuild. Group B had an experience similar to what we use today; a dead-simple first screen:
I foolishly thought the first-run dialog boxes would give users a better understanding of our product.
In retrospect the results aren’t surprising. Group B, the group that wasn’t interrupted, used wyBuild more than twice as long as Group A. More than that, the people in Group B were around 2 times as likely to save their project and build their first update.
So, the group that was bothered by a bunch of pointless dialogs often quit before they’d created their first update. (And this was back when wyBuild was free. The only measure of success was if the user actually used the product).
Because this data was collected remotely (it was opt-in, of course; I’m not a sleaze), we couldn’t ask the people in Group A why they gave up. If I were to guess I’d say their thoughts ranged from “It’s too confusing” to “I’ll do it later, when I have some free time” (i.e. never).
You almost certainly have a competitor that is faster, cheaper, better, or all of the above. So, the next time you add just one more dialog or just one more field to your order webpage, think about how many potential customers you’re losing.
Scratch that. Test to see how many users you’re losing.