- Introduction
- Developer’s Guide
- Samples
- Reference
Developing your own Cloud Drive
ShellBoost contains features that can help you develop a “Cloud Drive”, or a “Cloud Storage” engine. However, there are many ways this can be done. In this chapter, we present different solutions as a comparison table to help you decide what’s the best approach in your context.
All the solutions presented here presume there is some backend system that represents the “Cloud”. Note it’s not necessary located on the Internet, it can just be represented by an API that connect to this system.
|
Shell Namespace Extension |
Files-OnDemand + Synchronizer Process |
Hybrid: Virtual Drive + Shell Namespace Extension
|
Overview |
In the Explorer tree view, this is materialized by a custom tree node, usually located under the “This PC” tree node, with a specific name, not a drive letter. |
In the Explorer tree view, this is “just” a standard physical directory. It can also have a Shortcut in the top of the Explorer Tree View. This requires a process to synchronize folders and files between the backend and the local physical path. It’s like One Drive for Windows. |
In the Explorer tree view, this is materialized by two tree nodes: a Shell Namespace Extension node usually located under the “This PC” tree node, with a specific name, not a drive letter a regular drive or directory tree node (like x:\ or d:\myCloud). This requires a kernel component that exposes any data source as a file system drive or directory (for example WinFSP). |
UI Customization |
The UI (context menus, columns, etc.) can be fully customized. This includes special columns such as the “Status” column (the same one that can be seen in OneDrive for Windows). Note this column is visible in all Explorer views: icons, tiles, etc. (note this “Status” column requires Windows 1709+).
|
Since it’s just a standard physical directory, you can only customize it using external Shell extensions. For example, if you want to add a context menu or custom columns, you will have to write custom COM handlers. |
Same as for the Shell Namespace Extension solution. |
Common Dialog support |
Common Dialogs are generally supported for Open & Save. Some (rare) applications that don’t use Common Dialogs at all may not see the Shell Namespace Extensions. |
It’s just a standard physical directory, so everything works as usual. |
They are supported by the kernel component virtual drive/directory since it’s seen as a physical directory. For the Shell Namespace Extension tree node, they are also supported for Open & Save in most applications. Note however that opening or saving again the same file may show the virtual drive/directory tree node instead of the Shell Namespace Extension tree node. |
Pros |
Full UI Customization |
This is the only solution that supports true placeholders “On-Demand” files, that can exist without any physical content allocated on the disk. Note this also works for sized Thumbnails (for certain types of files like images, etc.) which can be created On-Demand without allocating data for the file itself. |
“Legacy” apps can use the drive/directory while other apps (or the end-user) can use the Shell Namespace Extension with customized UI. |
Cons |
Some applications are not capable of using tree node in Explorer that are not backed by real physical folders. Console-mode application (batches, etc.) cannot see it. Saving scenarios from Common Dialogs hosted by applications are usually not supported when serving virtual ShellItems (item without a FileSystemPath property set). |
The synchronizer process is very difficult to write. Fortunately, ShellBoost provides the MultiPointSynchronizer class for this exact purpose. UI Customization can only be done by external (usually native COM) components. Custom property handlers are specific for a file type, so you will not be able to add a common custom column for all items in a Shell view. No metatada (EXIF, etc.) can be seen for dehydrated files. Only thumbnails can be made available. Requires Window 10 1709 and latest versions are recommended. |
Requires administrator rights for setup. Uses a kernel component. Because of the low-level connection between your backend and the kernel proxy, the number of calls into your backend (partly due to the Shell Namespace Extension above) can kill performance if great care has not been taken of in developing this part. |
Minimum required rights for setup |
End-user |
End-user |
Installing a kernel component requires administrator rights. |
Minimum Windows Requirement |
Windows Vista |
Windows 10 1709 |
Windows 7 and possibly Windows 10 1709 if special features (“Status” column, etc.) are needed |
Relevant ShellBoost samples |
Cloud Folder (.NET 5) Cloud Folder Fx (.NET Framework) |
Cloud Folder Sync (.NET 5) |
Cloud Folder Proxy (.NET 5) |
In the ShellBoost Cloud Folder samples context mentioned above, the backend is represented by two sample projects:
The Cloud Folder Site sample, which is an ASP.NET Core web site. It uses SQL Server or a local Windows NTFS path as a storage backend, and ASP.NET Core SignalR for publishing events to clients.
The Cloud Folder Client sample, which is a Windows Forms client that allows you to test the backend: create, read, update, delete items and folders, etc. It also uses ASP.NET Core SignalR for subscribing to events so it refreshed automatically when the backend items changes.