Managed Preview Handlers

To set context, a preview handler in Windows Vista and/or Outlook 2007 is a component that provides a preview window for a specific file type (or set of file types).  For example, the default preview handler for .jpg files will display a preview of the image in the Windows Explorer or Outlook preview pane:

I’ve always had the impression that writing a shell preview handler was a daunting task involving lots of native code implementing obscure COM interfaces.  I’ve also been sure that the managed interop story was very sad, for the following simple (and convincing) reason: Assume that all preview handlers ran inside the explorer.exe (or outlook.exe) process.  What if preview handler A was built against CLR v1.1 and preview handler B was built against CLR v2.0?  Well, if handler B was loaded first, CLR 2.0 would be loaded into the process and then handler A would happily use it – after all, CLR 2.0 is backwards compatible with CLR 1.1.  However, if handler A was loaded first, CLR 1.1 would be loaded into the process, and handler B would not be able to run at all – because there is just one version of the CLR that can be loaded into a given process.  (This last remark will cease to be true as of CLR 4.0, but preview handlers have been there for a couple of years now.)

However, this was a myth.  I will be the first to admit that I didn’t do my homework.  Preview handlers always run out of process, by default in the surrogate host called Prevhost.exe (these handlers won’t be compatible with Outlook 2007 on Windows XP).  How is this any better than running all preview handlers in the Explorer.exe process?

Well, it’s possible to specify that your preview handler should be launched in a separate instance of Prevhost.exe instead of sharing the default one.  This effectively gives you the tools to separate managed preview handlers into different processes, e.g. according to the version of the CLR they were built against.

Still, writing a managed preview handler wouldn’t be trivial – there are several COM interfaces to implement, and some registry keys to set so that your handler is recognized by the shell.

Fortunately, Stephen Toub’s amazing article from MSDN Magazine titled “Writing Your Own Preview Handlers” provides a managed framework for developing preview handlers.  Writing a managed preview handler using that framework is as easy as:

1. Deriving a class from StreamBasedPreviewHandler or FileBasedPreviewHandler
2. Implementing the CreatePreviewHandlerControl method
3. Deriving a class from StreamBasedPreviewHandlerControl or FileBasedPreviewHandlerControl

The rest is the details of drawing a Windows Forms representation of your file type (and of course you can integrate WPF inside using the ElementHost wrapper control).

If you never got the chance to experiment with the Windows Shell, writing a managed preview handler is an incredibly easy opportunity to get started.  If there’s any file type that you wished there was a preview handler for, you can finally write one yourself!

References

Reference: 

Managed Preview Handlers