VistaBridge Considered Harmful; An Alternative

I've been playing with VistaBridge for a little while now, and the more I work with it, the more I realize that it's not ready for prime time. If you really look at the source, you'll see that it's filled with to-do's and comments along the lines of "This doesn't work". It tries to detect the presence of the correct version of comctl32.dll using an absolute path. The Visual Studio designer doesn't like some of its components: it won't display a window that uses task dialog progress bars and of the other VistaBridge controls.

Of course, VistaBridge is sample code; it was never intended to be used as-is in production code. Nevertheless, from web chatter it would appear that many developers have tried to use it. Developers should understand that it is unfinished--and apparently abandoned--code, so use it as inspiration only. [Update: not abandoned! See Kate Gregory's comment.]

The other problem with VistaBridge is that it just doesn't work very well.

There are a number of issues, but the biggest problem has been the dreaded "entry point not found" error when trying to call TaskDialog, TaskDialogIndirect, and the other Vista-only APIs. It was well understood that this probem had to do with side by side assemblies: these functions are present only in comctl32.dll version 6, but, for compatibility reasons, Vista will load an earlier version unless you tell it otherwise. The approach most people (including me) have been taking is to use a manifest. This has proven to be tricky, and may not be the right solution anyway, especially if what you're writing is a library: you don't necessarily want to force the entire application to use common controls 6.

The right solution is to push a new activation context when calling one of the Vista-only APIs. The activation context will use the correct version of comctl32.dll while leaving the rest of the application alone, and no manifest is required.

Fortunately, this is easy to do. Some very helpful people at Microsoft (thanks, Scott, Rob, and Anson) pointed me to some complete code that already exists in the MS Knowledgebase. The code from the article (KB 830033) does the trick as is. Even though the article is talking about a different issue (applying theming to Office add-ins), it does exactly what we want, and you can plop it into your application or library exactly as shown.

I've put together a C# class library that supports task dialogs using this technique and posted the Visual Studio 2008 solution here. The solution includes a simple demo app that displays a number of different styles of task dialogs, most of which are defined in XAML window resources. The library has not been through much testing, so use it to learn the techniques only. It's not intended for use in production code.