ShellBoost architecture is quite simple.
ShellBoost provides two components:
1)The ShellBoost Native Proxy assembly. This assembly is in fact provided as two binary files for x86 and
x64 support. It has a name like “ShellBoost.<id>.x86.dll” and
“ShellBoost.<id>.x64.dll”, <Id> being unique to the namespace
extension project. It means if you want to write two Shell Namespace Extensions
with ShellBoost, you will have to use two ShellBoost native proxy assemblies,
which also means two ShellBoost licenses.
2)The ShellBoost Core assembly. This is a
.NET assembly compiled as “Any Cpu” so the same binary supports x86 and x64
processes. It’s common to all ShellBoost projects.
<Your code>.exe is a .NET program
that will “serve” items and folders to the Shell. It can be any type of .NET
application: Console, Winforms, WPF, Windows Service, etc.
The proxy assembly has been written in C++
and has almost no dependency on any other DLL besides the standard Windows one
(it has no dependency on the C++ runtime files like MSVCRTxxx). This ensures
maximum compatibility with various Windows setup. This is the only assembly
that will run in-process with Windows Explorer. Note it will also run
in-process with other programs that would use any Shell functions that may load
directly or indirectly Shell Namespace Extensions. For example, if you use
Windows Notepad and choose the File / Open menu item, it’s possible that the
ShellBoost native proxy will be loaded in process with notepad.exe.
All proxy assemblies loaded in-process by
explorer.exe or any other exe, as a Shell Namespace Extension, will be seen as
“clients” by the ShellBoost RPC communication protocol, and will try to
communicate with a “server”. The server must be hosted by your own code, and
will “serve” items, folders, properties, etc. representing your Shell Namespace
Extension, when requested by the “clients”. The server, written by you, using
.NET, hosts ShellBoost.Core which will itself load the exact same proxy native
assembly binary, but used as a server this time. The same host process will
serve all client processes.
Here is an example of a ShellBoost
Namespace Extension: “AmalgaDrive”, which is one of the sample provided with
As you see, there are only 4 files needed
to support this extension. Even if the native proxy will be loaded in-process
by Explorer.Exe and by the Server process (here “AmalgaDrive.exe”), the file is
located at the same place, there’s no need to deploy it in multiple
As a Shell Namespace Extension .NET
developer, you don’t have to worry about the RPC communications between the ShellBoost
proxy and the .NET host process. This is all transparent when using the
ShellBoost Core .NET API. Unlike other protocols, RPC is super-fast and does
not occur any timeout during connection, disconnection, or even communication
If the Windows Shell cannot communicate
with its server, it may display an error message like this (the text of the
button and label can be changed in the ShellBoost Web Site). If the server
comes to life again, pressing “Refresh” should display the items in that folder: