ShellBoost architecture

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 or .dll is a .NET binary that will “serve” items and folders to the Shell. It can be any type of .NET application: Console, Winforms, WPF, Windows Service, etc. It can be and .exe, or a .dll hosted by another .exe, including native applications, provided they can host a .NET .dll.

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 ShellBoost (https://github.com/aelyo-softworks/AmalgaDrive), once deployed:

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 directories.

RPC Protocol

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 suffer from any timeout during connection, disconnection, or even communication issues.

If the Windows Shell cannot communicate with its .NET server (that host the ShellBoost binaries), it may display an error message like the one in the following screenshot (the text of the button and label are configurable and can be changed in the ShellBoost Web Site). If the server comes to life again, pressing “Refresh” should display the items in that folder: