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.
Windows Explorer is a crucial component of any Windows
installation, that every end-user is fully familiar with. It’s the
out-of-the-box host program, over the Windows Shell, that provides a graphical and
hierarchical representation of many Windows objects such as the desktop, the
user’s documents, physical folders and files, or their content (like .zip files).
These items are organized into namespaces hierarchies. The Shell’s namespace graphical
representation also includes other visual information such as:
details views, list views, icon views
thumbnails and tooltips
toolbars and ribbons
Depending on the Windows version, the shell also comes with many
standard end-user tools and actions, that can act on items and folders in a
hierarchy, such as
context menus, with standard or specific items, added by other
copy, paste, cut, delete, link, drag and drop
go to, backward, forward, level up, level down
grouping and filtering
A Shell Namespace Extension is a virtual folder in
the shell namespace, among other shell folders. When a user browses into such a
virtual folder, the data is presented as a tree-structured hierarchy of folders
and files, much like the rest of the Shell namespace:
Users and applications can interact with the contents of
this virtual folder in much the same way as with any other namespace object.
In fact, even a standard Windows installation contains lots
of out-of-the-box namespace extensions:
“God Mode” folder and other well-known folders: Windows 7 GodMode and Other Folder Shortcuts
Shell Namespace Extensions are also referred sometimes as Shell
Data Source Objects, as an extension provides items and sub folders (folders
are just a certain type of items) and their columns or properties for a given junction
point in the shell namespace. A folder can somewhat be seen like a table,
each item being a row, each property being a column, and each property value being
Windows 10 version 1709 (or “Fall Creators Update”) also
introduces the “Files On-Demand” feature. It allows users to see all their
files stored on OneDrive from within the Windows Explorer, without having to
first download these files. ShellBoost has exclusive support for this on-demand
technology, with or without a Shell Namespace Extension support, through the OnDemandSynchronizer
Windows 10 version 1809 has introduced the “Windows Projected File System (ProjFS)” feature,
only for NTFS physical drives and only for 64-bit applications.
Although this technology is not strictly related to Shell
Namespace Extension development (in fact, it’s not even related to the Shell,
it operates at the lower File System level), ShellBoost provides some exclusive
support for it, in combination with Shell Namespace Extension development, through
the ProjectedFileSystem and ProjectedFileSystemProvider classes.
Beyond the fact it’s just so cool because it tightly
integrates with billions of copies of Windows running out there, here are some
reasons to implement such a thing:
With a namespace extension, you can expose any data or info set
to end-users, while implicitly providing them with a load of features provided
by the Windows Shell (navigation, search, copy, paste, links, etc.).
Since most Windows users in the world know the Windows Shell /
Explorer pretty well, this will considerably reduce the need for costly
end-user change management and/or training for your project adoption.
Depending on how your data is organized, you may even end up not
having to write anything else that a shell extension. Since folders and items
can be fully virtual, you can use them to represent anything you want.
Even an item content can be created on demand. So for example,
you can show an end-user a list of Excel or PDF files that don’t really exist,
but that you will create on the fly when the user will double-click on them
from the Explorer. These files content could be created on-the-fly from a CRM
system for example.
Without a Shell Namespace Extension, you cannot do these:
Have multiple items with the same name in a given shell folder.
It’s impossible to have two or more file system entry with the same name.
Have items in a shell folder with names containing reserved
characters such as ‘?’ or ‘:’.
Have fully virtual items, items without a physical presence on
the disk as files or folders, like database items, or files on a remote
computer or in the cloud.
Have these items support shortcuts, drag and drop, copy, paste,
modification, etc. just like they were regular files and folders.
Present a data source (whatever the data is) as folders and files
to an end-user.
Present fully virtual files (without any physical presence),
created on-demand, to an end-user.
There are many ways to extend the shell, and depending on
your needs, you can extend it without writing a namespace extension.
Customizing various menus displayed by Explorer
Customizing icons and thumbnails for items in the namespace
Customizing explorer toolbar, bands
Customizing the explorer ribbon
Handling a completely custom file format, if it does not need to
be displayed as a hierarchy.
Note although many of these actions can be implemented
independently of the item’s position in the namespace tree, writing a namespace
extension is still useful if you want to fine tune the related actions. For
example, a namespace extension can mask the ‘Delete’ command for a given item,
A namespace extension is not to be confused with favorites
or quick access icons, which are just links or references to already existing
namespaces folders. Using standard Windows menus, an end-user can already
create Quick Access links, shortcuts, or pin items or folders (virtual or not)
to the taskbar or the start menu (for version of Windows above 8). In the
following image, the “Pictures” folder is just a reference to an existing physical
Some virtual folders that are be installed by 3rd
parties, such as One Drive® or Dropbox® folders are namespace extensions, but
without any custom code. It’s possible because Windows provides a way to
declare a namespace extension based a physical directory on the disk. In this
case, the shell provides the code, and it just needs several registry entries
to be setup properly. This is explained in these Microsoft articles: Integrate a Cloud Storage Provider and Creating Shell Extensions with Shell Instance Objects.
The result is in the end quite like a favorite, or a shortcut to the folder, and
doesn’t allow more end-user action than what’s provided by the Shell.