Why ShellBoost?

 ShellBoost is a software component that allows .NET developers to easily write Windows Shell Namespace Extensions. Writing a Shell Namespace Extension is a difficult and expensive task. ShellBoost makes that much easier and cheaper.

Technically, a Windows Shell Namespace Extension is an in-process extension. It means it’s one .dll file that is also a COM (Component Object Model) server that is configured in the registry so Explorer can find it and load it in its own address space. There are other extensions to the shell that can be written as out-of-process extension, like preview handlers or context menus, but a Shell Namespace Extension always runs in-process.

The bad news: Explorer just does not support hosting .NET assemblies

 

One of the main reasons why ShellBoost exists is simply because Microsoft recommends against writing in-process extensions using .NET and does not support it. This is clearly stated in the official  Guidance for Implementing In-Process Extensions article, partially quoted here:

In-process extensions are loaded into any processes that trigger them. For example, a Shell namespace extension can be loaded into any process which accesses the Shell namespace either directly or indirectly. The Shell namespace is used by many Shell operations, such as the display of a common file dialog, the launch of a document through its associated application, or the obtaining of the icon used to represent a file. Because in-process extensions can be loaded into arbitrary processes, care must be taken that they do not negatively impact the host application or other in-process extensions.

One runtime of particular note is the common language runtime (CLR), also known as managed code or the .NET Framework. Microsoft recommends against writing managed in-process extensions to Windows Explorer or Windows Internet Explorer and does not consider them a supported scenario.

Writing a Shell in-process extension is tough

 

So, it means you must write in-process extensions using another language, which is often C or C++. Although C++ is one of the most widely used programming languages in the world, the language is still today more difficult to grasp, for a clear majority of programmers, than C# or VB.NET. Productivity is the key word here. And the issue is not only the language itself, but also all these important technologies, some of them rather low-level, that one must master to achieve such a goal:

Windows programming: It’s not because you are a good C++ programmer that you know your ways through the Windows SDK, headers, macros, etc. that are mandatory to use.

COM programming: On top of Windows programming, you’ll need to understand how to write low-level COM objects (again, without .NET).

Shell programming: The shell is a whole world by itself. There are lots of COM interfaces that needs to be implemented. Many things are not fully documented, and it sometimes take a long time to understand the relations between various components of the system.

Writing a Shell in-process extension is tedious

There are some problems very specific to writing an in-process extension to the Shell:

Supporting 32 and 64-bit: Since Windows ships in 32 or 64-bit, Explorer may need one version or another, so there are good chances that you will need to provide two binaries for your extension. ShellBoost eliminates that issue, you only must write one .NET executable that can be compiled as “Any Cpu”.

Restarting Explorer: You will have to restart the Explorer process (or processes) and all processes that load your extension in-process (all processes that use the Common Dialogs, Open, Save, etc.) all the time, especially when you want to compile a new version (otherwise the .dll binary will stay locked by the system). With ShellBoost and its unique out-of-process architecture, you can start and stop your server process, Explorer and other processes don’t have to be restarted, as RPC cross-process communication will resume automatically without any timeout as soon as the server becomes available.

Restarting all Common Dialog client apps: You will have to restart explorer process, but for the same reasons, you will also have to restart all processes that have used the Common Dialog (notepad, Office apps, any etc.) and have loaded your extension in their process. This can be very painful during development times.

Deployment is difficult: In-process shell namespace extensions are loaded in explorer.exe processes but also in all Common Dialog client apps processes, which means basically almost all applications using files on a machine. When you want to update your binaries, you probably will have to restart the machine. With ShellBoost architecture, you only must stop and restart your updated .NET application.

Writing a Shell in-process extension is risky

As the name implies, an in-process extension is loaded in-process with explorer.exe processes and all Common Dialog client apps processes. It’s not rare that a bug, in such a crucial binary, crashes its host process. ShellBoost out-of-process architecture prevents bugs in your code to crash end-user’s vital applications.

You need an extension, but you don’t want to invest too much in that technology

After all, in a programmer’s lifetime, it’s not so frequent to have to write Shell Namespace Extensions. Although integrating with the shell is super useful and allows us to offer the end-user a standard look and feel environment, we usually don’t need to write such a beast every Monday. So, unless you make a living writing Shell Namespace Extensions, it’s not worth the considerable time and effort that you will have to spend.