SharpShell wraps Windows shell extensions as COM servers you can write in C#

What a shell extension actually is, and why it is awkward

A Windows shell extension is a COM server. The shell loads your DLL, calls interfaces it defines, and expects specific marshalling rules, a specific registration in the registry, and answers on the right thread. Every one of those is a barrier between a C# developer and a working feature.

SharpShell's pitch is that you implement the extension point as a normal managed class and the library handles the interop and the hosting. The stated purpose in the README is to make it easy to create Windows Shell Extensions using the .NET Framework.

The supported surface is broad, and the breadth is the clearest statement of what the library does. Context menus, icon handlers for custom icon appearance, info tip handlers for shell tooltips, drop handlers for drag and drop, preview handlers for rich previews in Explorer, icon overlay handlers, thumbnail handlers described as COM servers customising thumbnail appearance, property sheet extensions adding pages to the property dialogs of files, shares and folders, and desk band extensions adding functionality to the desktop or task bar.

Each of those is a different COM interface with different lifecycle expectations. Covering nine of them from one abstraction is the reason this library exists rather than a set of thin interop helpers.

Three packages, and one of them handles registration

Installation is through the NuGet package manager, either by searching for SharpShell or from the Package Manager Console.

PM > Install-Package SharpShell

The official packages are three, and they split along lines you will care about on day one. SharpShell is the core library. SharpShellTools is the tools package, typically for build-time or authoring work rather than the runtime extension itself. ServerRegistrationManager is the one that matters operationally: shell extensions have to be registered with the shell before they will load, and that registration is per-machine or per-user state outside your installer.

That third package is the part that decides whether your feature works on someone else's machine. An extension DLL that compiles and runs locally but is never registered does nothing, silently. Deployment is therefore part of the design, not an afterthought, and the README points to the deploying guide under docs/installing as one of the two most useful documents, alongside the troubleshooting page.

The documentation itself has been reorganised into the docs directory, so older links to sections in the main README may point somewhere else now.

Icon overlays show the design goal more clearly than the API does

The icon overlay handler is the example the README spends the most words on, and it is the right one to study. An overlay draws a small badge on top of a file icon in Explorer to show extra state. The README's example is Dropbox showing whether a file is synchronised.

That means the extension is asked about the state of an arbitrary item, in a directory listing, potentially for many files, at unpredictable times. The library has to return fast, handle items it does not recognise, and not block Explorer. An extension that does this badly is not a wrong feature, it is a broken file manager.

The same constraint shapes context menus and drop handlers, which are interactive and user-driven rather than bulk, and preview handlers, which render on demand when a user selects an item. Preview handlers in particular have to write into an object Explorer hands you rather than draw anywhere they like.

Property sheet and desk band extensions are the less obvious entries. Property sheets add pages to the properties dialog for files, folders and network shares, which is a dialog-embedded surface. Desk bands add custom functionality to the desktop or task bar, which is a persistent UI element that has to behave when the user resizes and re-lays-out the shell.

The repository structure tells you what is maintained

The tree is small: a SharpShell directory for the library, SharpShellNativeBridge for the native side of the interop, SharpShellInstallerSample, a Tests directory, docs, and an appveyor.yml for continuous integration.

Version history is the thing to weigh before adopting. The last tagged release is v2.7.2.0 from 2019-11-07, after v2.7.1 in 2018 and v2.7.0 in 2018. The last push to the repository was on 2026-09-10, so commits are still landing, but they are landing without a NuGet release.

That gap matters for a package you install from NuGet. The version you get is from 2019, and the source you can read is newer. If you need a fix, you are building from source rather than bumping a package reference.

The framework target is stated in the README as the.NET Framework, which is the older Windows desktop stack. That is a real constraint for a project starting today on.NET 5 or later, and it is worth resolving early because it determines whether you use SharpShell or write the interop yourself.

Where the alternatives fit

Three options sit alongside SharpShell, and they differ in how much interop you accept.

Writing the COM interop yourself is what SharpShell replaces. In C# you can declare the interfaces with ComImport and attributes and host them with the AppDomain registration APIs. The result is more code per extension and no shared plumbing, and it is what you end up doing anyway if the extension you need is one SharpShell does not cover.

A native implementation is another option. It avoids the CLR hosting question entirely and is what some shell extension points still expect, though the cost is a separate toolchain and no shared code with the rest of your product.

Third, no extension at all. Many integrations that want an overlay or a preview can be delivered inside the application and only partially in the shell, or through a file association rather than an overlay handler. That is the option to check first, because a shell extension has a permanent cost: it is loaded by Explorer, its registration must be planned for each deployment target, and it fails in ways users report as Windows being slow.

The licence is MIT, which is permissive and does not affect the choice.

Editorial conclusion

Adopt SharpShell if you must ship an Explorer integration written in managed code and nobody on the team wants to hand-write COM interop for each shell interface. Do not adopt it for a new product today: the last release was v2.7.2.0 in 2019 while the repository is still being pushed to, so you are buying a mature but dated surface. Before starting, confirm the shell extension you need is on the supported list and plan for registration in the docs' deployment guide.

Frequently asked questions

Official sources

1. dwmkerr/sharpshell on GitHub
2. Issues
3. License: MIT
4. README
5. Releases