Avoid Shared Assemblies with Azure Functions

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=9.4.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' and 'Microsoft.WindowsAzure.Storage, Version=9.3.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' <Assembly with Azure Functions and including shared assembly which includes Azure Storage assembly>
AzFnTrials Solution Hierarchy

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.

Breaking Azure Functions with local.settings.json

Because local.settings.json is finicky!

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.

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "AzureWebJobsDashboard": "UseDevelopmentStorage=true",
    "customKey": "customValue",
    "customObj": {
      "customObjKey": "customObjValue"
    }
  }
}

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.