Migration Guide

Migrating from FluentStorage v7 to v8+

Removed packages

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 package.
FluentStorage.Azure.DataLake	We are no longer maintaining this package because it only supports Azure Data Lake Gen1, which has been superseded by Azure Data Lake Storage Gen2. Gen1 is a legacy service and is no longer recommended by Microsoft for new development.
FluentStorage.Azure.ServiceFabric	We will no longer maintain this package because Service Fabric is neither a first-class object storage service nor a messaging service, which places it outside our current scope. It also has extremely low community usage.

Migrating from Storage.NET

Packaging changes

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	FluentStorage.Databricks
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	FluentStorage.Azure.EventHub
Storage.Net.Microsoft.Azure.ServiceBus	FluentStorage.Azure.ServiceBus
Storage.Net.Microsoft.Azure.KeyVault	FluentStorage.Azure.KeyVault
Storage.Net.Microsoft.Azure.ServiceFabric	FluentStorage.Azure.ServiceFabric
Storage.Net.Microsoft.Azure.Queues	FluentStorage.Azure.Queues
Storage.Net.Microsoft.Azure.DataLake.Storage.Gen1	FluentStorage.Azure.DataLake

Encryption changes

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.