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
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
for Implementing In-Process Extensions article, partially quoted
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
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.
On top of Windows programming, you’ll need to understand how to write low-level
COM objects (again, without .NET).
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
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 File 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 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 must stop and restart your updated .NET
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