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
Extensions always run in-process.
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
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
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 vast 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.
There are some problems very specific to writing an
in-process extension to the Shell:
Supporting 32 and 64-bit: Since Windows still 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 process compiled as “Any
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 File Dialogs, Open, Save, etc.) all the time,
especially when you want to compile a new version (otherwise the .dll binary will
stay locked). 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 File 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 File 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 File
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 have
to stop and restart your updated .NET application.
As the name implies, an in-process extension is loaded
in-process with explorer.exe processes and all Common File 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.
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.