Shell extensions in C# and/or VB.NET

· November 8, 2006

Update: .NET 4.x and later should allow different .NET versions to be loaded side-by-side in the same process, so the argument below probably does not stand anymore (if your extensions use .NET 4.x or later). It’s still dangerous waters in my opinion.

 

Please, repeat with me.

I WILL NEVER WRITE SHELL EXTENSIONS IN C# OR VB.NET.

Not even if Dino Esposito suggests it.

It’s bad for many reasons.

Shell extensions are loaded in almost every application you run (read : every application with a file open dialog or save or browse for folder…). If your shell extension is written in a .NET language (C#, VB.NET, but also Managed C++, C++/CLI) you simply inject the whole CLR in almost every application.

This has these consequences :

  • In a managed program your shell extension could find itself to run under a different CLR version than expected. Unless your shell extension is CLR-1.0 it’ll probably fail to run.
  • In a mixed mode program which loads a managed module in a second step (for instance a plugin) your shell extension could have forced a different CLR version to load and cause the application to fail.
  • Visual Studio 2002 or 2003 could fail to debug an otherwise perfectly debuggable program if .NET Framework 2.0 or 3.0 is installed. This is because VS2002/3 fail to debug applications using CLR 2.0+ (you must use 2005), but it could get loaded because of your extension. You can use a manifest file to force CLR1.x to be loaded but it’s feasible only for your internal use, not for distribution.

So essentially, writing a shell extension in .NET is a good way to break applications and debuggers randomly.

It’s sad but UI in shell extensions must be written in p(l)ain C++.. :( :( :(

References :

 

Photo by Kevin Walsh