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 no dependency on any other binaries besides the standard Windows one
(it has notably no dependency on the C++ runtime redistributable files like
MSVCRTxxx). This ensures maximum compatibility with various Windows setups, in
any language. 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 (such as TCP/IP), local RPC is
super-fast and does not occur any timeout during connection, disconnection, or
even communication issues.
If the Windows Shell cannot communicate
with its .NET 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: