CBFS Shell Architecture

CBFS Shell architecture provides two components:

  • The CBFS Shell Native Proxy DLL. This DLL is provided as several binary files, one for each supported processor architecture. It has names like CBFSShell.<id>.x86.dll, CBFSShell.<id>.x64.dll, and CBFSShell.<id>.ARM64.dll. With the <Id> part of the name unique to each Namespace Extension project. If you create two Shell Namespace Extensions with CBFS Shell, you will have to use two separate native proxy DLLs.
  • The CBFS Shell Core Assembly. This is a .NET assembly. Because it is compiled as "Any CPU", the same binary supports x86, x64, and ARM64 processes. It's common to all CBFS Shell-based projects.

<Your Code>.exe from the example above is a .NET binary that will "serve" items and folders to the Shell. All types of .NET applications are supported: Console, Winforms, WPF, or Windows Service. It can be an .exe or a .dll hosted by another .exe, including native applications, provided they can host a .NET .dll.

CBFS Shell Native Proxy DLL

This DLL is the only block of code that will run in-process with Explorer. It also will run in-process with other programs that use any Shell functions, which may load directly or indirectly Shell Namespace Extensions. For example, if you use Windows Notepad and choose the File / Open menu item, it is possible that the CBFS Shell native DLL will be loaded into the notepad.exe process. The native proxy DLL is written in C++ and is not dependent on any binaries other than the standard Windows binary (notably, it has no dependency on the C++ runtime redistributable files like MSVCRTxxx). This ensures maximum compatibility with various Windows configurations in any language.

All proxy DLLs loaded into explorer.exe processes or any other process, as a Shell Namespace Extension, are the "clients" in the CBFS Shell RPC communication protocol. These clients will try to communicate with a "server". The server must be hosted by your own code, and when requested by the "clients", will "serve" items, folders, and properties representing your Shell Namespace Extension. The server, written by you using .NET, hosts the CBFS Shell Core Assembly, which will load the native proxy DLL in a "server" mode. The same server process will serve all client processes.

Important: The described architecture means that one proxy DLL may be used in one project because it will attempt to reach one server process using the RPC communication protocol.

RPC Protocol

As a Shell Namespace Extension .NET developer, you don't have to worry about the RPC communications between the CBFS Shell proxy and the .NET host process. When you use the CBFS Shell .NET API, the RPC communication is transparent.

Internally, the local RPC channel is used. Unlike other protocols (such as TCP/IP), the local RPC is super fast and does not suffer from any timeout during connection or disconnection, and does not even have communication issues.

If the native DLL on the Windows Shell side cannot communicate with the corresponding .NET server, it may display an error message, like the following screenshot (the text of the button and label are configurable using CBFS Shell API). If the server comes to life again, pressing "Refresh" should display the items in that folder:


Following is an example of a CBFS Shell Namespace Extension AmalgaDrive.

As you can see, only four files are needed to support this extension. Even if the native proxy is loaded in-process by explorer.exe and by the server process AmalgaDrive.exe, the file is located in the same place. Therefore, it does not need to be deployed to multiple directories.

Copyright (c) 2022 Callback Technologies, Inc. - All rights reserved.
CBFS Shell 2022 .NET Edition - Version 22.0 [Build 8172]