Keep Azure Function assemblies monolithic, or be prepared to work deal with mismatching Azure Storage assemblies.
Azure Function projects which attempt to share common code via other assemblies will fail to compile with:
CS0433: The type 'CloudBlob' exists in both 'Microsoft.Azure.Storage.Blob, Version=220.127.116.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35' and 'Microsoft.WindowsAzure.Storage, Version=18.104.22.168, Culture=neutral, PublicKeyToken=31bf3856ad364e35' <Assembly with Azure Functions and including shared assembly which includes Azure Storage assembly>
The mismatch occurs due to the Azure Storage versions included in the Azure WebJobs extensions and more general Azure Storage. The nearby AsFnTrials Solution Hierarchy screenshot highlights the mismatched versions. The easiest way to avoid this compilation error is to keep all of the code in a single assembly – e.g., move BlobHelper.cs to SharedAsmb and remove CommonLib (or remove it from dependencies).
The downside with this approach is that sharing code gets more complicated, particularly when existing shared code exists.
At some point you’re going to want to add an object to the Values section of local.settings.json. Don’t! Declaring an object (or array) in the Values breaks the configuration, resulting in Missing value for AzureWebJobsStorage in local.settings.json. Notice the customObj declaration below.
Just having customObj declared will breaks things. Yes, it’s valid JSON; no, your functions won’t be able to retrieve settings from Value.
A simple key-value pair works – like customKey above. After removing customObj, retrieving the setting for customKey from Values is straight-forward
var customVal = System.Environment.GetEnvironmentVariable("customKey");
Beyond this simple case for local.settings.json, use app configs, and remember that Azure Functions v2 switched to ASP.NET Core Configuration, and does not support ConfigurationManager. See Jon Gallant’s post for details.