Repository navigation
Migration Guide
All methods are async by now. The old goal of supporting sync and async makes no sense since all cloud transfer APIs are async and the handful of edge cases like local memory storage and local disk storage do not matter. So we droped "Async" in all API names.
One factory class per provider is the new standard:
AwsS3StorageAwsSqsStorageBackblazeB2StorageCloudflareR2StorageDigitalOceanSpacesStorageHetznerStorageMinlOStorageVultrStorageWasabiStorageAzureBlobStoreAzureDataLakeStoreAzureFilesStoreAzureKeyVaultStorageAzureQueueStorageAzureServiceBusGoogleCloudStorageFtpStorageSftpStorage
Extension methods are no longer required as a means for users to call functions within the factory classes. Henceforth, users can directly access to the factory classes:
-
StorageFactory.Blobs.AwsS3->AwsS3Storage.FromCredentials -
StorageFactory.Blobs.CloudflareR2->CloudflareR2Storage.FromCredentials
All Factory API will now return the concrete Store class rather than a generic IBucket. The advantages are:
- Store class implements multiple interfaces therefore returning a single interface does not suffice
- Store class implements special API outside interfaces which is now easily accessible
- Future interfaces are automatically available
- Full IntelliSense with no casting required
The entire FluentStorage API surface was redesigned from scratch to keep it meaningful, simple and consistent.
- All projects have been organized into folders.
- Exceptions moved into the
FluentStorage.ExceptionsNS - Enums moved into the
FluentStorage.EnumsNS
The following libraries have been deprecated and deleted from our codebase, reducing the maintenance effort and helping us focus on the important parts of our offering.
| Package | Reason | |
|---|---|---|
 |
FluentStorage.Databricks | We will no longer maintain this package because DBFS is not a mainstream storage backend for a storage abstraction library. |
 |
FluentStorage.Azure.EventHub | Due to low community usage, we will no longer maintain this library. |
 |
FluentStorage.Azure.DataLake | We are no longer maintaining this package as it only caters to DataLake Gen 1, which has been superseded by DataLake Gen2. Gen1 is considered a legacy service and is no longer the direction Microsoft recommends for new development. |
 |
FluentStorage.Azure.ServiceFabric | We will no longer maintain this package because ServiceFabric is not a first-class object storage or messaging service, which is outside our current scope, and it also has extremely low community usage. |
Change your NuGet packages and your imports using this mapping:
| Old name | New name |
|---|---|
| Storage.Net | FluentStorage |
| Storage.Net.Amazon.Aws | FluentStorage.AWS |
| Storage.Net.Gcp.CloudStorage | FluentStorage.GCP |
| Storage.Net.Databricks | No longer supported |
| Storage.Net.Ftp | FluentStorage.FTP |
| Storage.Net.Microsoft.Azure.Storage.Blobs | FluentStorage.Azure.Blobs |
| Storage.Net.Microsoft.Azure.Storage.Files | FluentStorage.Azure.Files |
| Storage.Net.Microsoft.Azure.EventHub | No longer supported |
| Storage.Net.Microsoft.Azure.ServiceBus | FluentStorage.Azure.ServiceBus |
| Storage.Net.Microsoft.Azure.KeyVault | FluentStorage.Azure.KeyVault |
| Storage.Net.Microsoft.Azure.ServiceFabric | No longer supported |
| Storage.Net.Microsoft.Azure.Queues | FluentStorage.Azure.Queues |
| Storage.Net.Microsoft.Azure.DataLake.Storage.Gen1 | No longer supported |
We now accept the IV and Key in the constructors of the *EncryptionSink classes.
Since most of the time we will be using Dependency Injection (DI) to instantiate our objects, each time the SymmetricEncryptionSink, the IV is set
public AesSymmetricEncryptionSink(string key) {
_cryptoAlgorithm = Aes.Create();
_cryptoAlgorithm.Key = Convert.FromBase64String(key);
_cryptoAlgorithm.GenerateIV();
}
This means that if a blob is stored, then it can only be unencrypted using the same instance of the Sink or with an instance of the Sink with the same IV (secret key)
If you are storing to AWS/Azure storage, then if you try and retrieve the blob at another time, you can't read the blob even though the original key might be the same, the secret generated at the time of encryption is no longer the secret that the sink is trying to use the decrypt.
Storage.Net has got this wrong and has used a pattern like this, which creates a transient class, however we fixed it to accept the IV and Key in the constructors of the sinks.