Why you wont find C# example code for writing Shell Extension handlers

Jesse Kaplan posted the following (thanks to Junfeng Zhang)

Writing in-process \shell extensions in managed code is actually a very dangerous thing to do because it has the effect of injecting your managed code (and the .NET Framework) into every application on the machine that has a file open dialog.

The problems occur because only one version of the .NET Framework can be loaded in a process at any given time (other shared components such as java and msxml have the same property and thus the same restriction).

If you write your shell extension using the 2.0 .NET Framework and an application built with the 1.1 .NET Framework uses a file open dialog, your shell extension will fail because it can not run on an earlier version. Things can get even worse if your shell-extension manages to get loaded in a process before another applications managed code does: your extension may force an existing application onto a different runtime version than the one it was expecting and cause it to fail.

Because of these problems we strongly recomend against using any single-instance-per-process runtime or library (such as the .NET Framework, java, or msxml) in an in-process shell extension.

Interesting scientific study about font usage on web pages.

Jeff Atwood posted a cool article from Wichita State about font legibility. Serif mono-spaced fonts were the worst (sorry Courier) and Tahoma did the best.

The study is worth reading, the testing methodology was objective and at pretty much validates what fonts you think should be used for a given type of web site. The other good tip in Jeff’s post was that Software Usability Research Laboratory (SURL) at Wichita State has an excellent newsletter that documents their usability studies.

Client vs Developer

Client vs Developer wars.
This is stuff isn’t directly applicable to our development patterns, but it has some useful information.

“Grayscreen” prototyping (building a simple HTML model of a website) provides an extremely effective way of communicating a website’s content, structure, and functionality before design and programming begin. Prototyping overcomes many other difficulties commonly associated with web development, such as managing expectations, communicating effectively, working through the design process, and creating and delivering content.

It’s another example of how design up front methods save time and money.

Good article plus a free book in PDF format.