I’ve seen this question pop up in a few different forms:

• How do I detect .NET assemblies?
• How can I detect the difference between .NET 2.0 and .NET 4.0 assemblies?
• How can I detect the difference between x86, x64, and AnyCPU .NET assemblies?

And the list goes on and on. But this raises the question…

Why detect .NET assemblies?

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:

• NGEN assemblies
• Install & update COM assemblies using RegAsm
• Install & update assemblies in the GAC (Global Assembly Cache).

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.

How not to do .NET detection

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).

How to detect .NET

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:

• CLI Partition II: Metadata Definition and Semantics (get the PDF) from the ECMA C# and Common Language Infrastructure Standards
• Portable Executable and Common Object File Format Specification (i.e. the PECOFF Spec)

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.

Tell me if you find this useful – how are you using it?

If you find this code useful, tell me how you’re using it in the comments.

Get the C# source

Download the AssemblyDetails C# source. It works with .NET 2.0, 3.0, 3.5, 4.0.

Example usage:

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.

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.

Named Pipes

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.

Keyboard accessibility

Start your application and unplug your mouse. Can you navigate and use your application? If you hit the tab key does the next logical control get focused? Can you open the file menu by pressing Alt-F?

Set tab ordering

Simply set the “TabIndex” property of your controls in ascending starting with 0. This way when your users press the tab key they next focused control is the next control in the flow of your form.

Menu quick keys

To add “quick key” ability to your menus you just need to put an ampersand (“&”) before the letter that will be used for quick access. For example, instead of a menu item captioned “File”, caption it “&File” instead. Now your users can access that menu quickly by pressing Alt-F.

SystemStyle Buttons, Radio Buttons, and Checkboxes

In Windows Vista Microsoft changed the buttons, radio buttons, and checkboxes to have subtle animations. When you hover, check, and click these controls they all yield organic animations. But if you built your app using Windows Forms the subtle animations aren’t there.

To add these animations all you have to do is set the “FlatStyle” of these controls to “System”.

Windows UX Guide

Microsoft has assembled a great collection of guidelines for designing applications. It’s filled with screenshot examples showing good & bad designs. Plus it’s surprising self deprecating – some of their examples of bad design are screenshots taken directly from Microsoft apps.

You should skim the guide at least once and bookmark it for later.

7 Days of Windows 7

That’s it for the series. If you missed the earlier articles you can see the full list of articles in the series.