This post was most recently updated on October 3rd, 2022.

2 min read.

Another day, another issue with Azure Functions! For such a simple and powerful tool, it sure does produce a lot of topics for blog articles! 😁 So, in this article, I’m explaining a couple of possible reasons why you might get an error along the lines of “Missing value for AzureWebJobsStorage” when debugging Azure Functions locally.

But before jumping into the solution(s), let’s take a closer look at the issue at hand, shall we?

Problem

Table of Contents

When firing up your Azure Functions project locally, this error is what you’re confronted with:

“Missing value for AzureWebJobsStorage in local.settings.json. This is required for all triggers other than httptrigger, kafkatrigger. You can run ‘func azure functionapp fetch-app-settings ‘ or specify a connection string in local.settings.json.”

But… You might actually have that property in the file – so what’s the error about, then? Let’s take a look!

What is “AzureWebJobsStorage” property used for?

The Azure Functions runtime uses this storage account connection string for its normal operation. Some uses of this storage account include key management, timer trigger management, and Event Hubs checkpoints. The storage account in question must be a general-purpose one that supports blobs, queues, and tables.

However – when running the runtime locally, this property in your local.settings.json file under “Values” should usually contain “UseDevelopmentStorage=true“, in which case the runtime should use your Azure Storage Explorer or Azurite locally.

Solution

The solution might be one of the following – I’m starting from the most obvious and simple one, which is likely where you should start as well.

Time needed: 10 minutes.

4 ways to fix “Missing value for AzureWebJobsStorage in local.settings.json”!

First things first – add “AzureWebJobsStorage” value to your local.settings.json file
Obviously, you could be missing this app setting completely – maybe by adding it somewhat like this:

And in copy-pasteable form – this is what you should add to local.settings.json -file’s “Values”-node:
"AzureWebJobsStorage": "UseDevelopmentStorage=true"

Simple as that! Except if it doesn’t work, try the other options below.

Close and reopen your Visual Studio instance
Just in case – it’s worth trying out.

It’s easy, it’s quick, and it has helped me once or twice!
No nested values in local.settings.json
Valid JSON can have values nested infinitely deep. But your local.settings.json file does not support that (beyond predefined “sections”, such as “Values” (for app settings) or “ConnectionStrings“, however!

Verify you’re not trying anything too fancy there.

What’s a bit confusing, however, is that the appsettings.json file DOES support nested configuration values. So no consistency here. 😊
Make sure your local.settings.json file is getting deployed (copied) to the output folder
Modify your .csproj file to have this:

<None Update="local.settings.json"> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory> </None>

This applies at least to .NET with recent versions of Visual Studio, but YMMV. 😌

And at this point, you should be good!

Did it work for you? Am I missing something? Let me know in the comments section below!

References

https://github.com/Azure/azure-functions-core-tools/issues/1473

Author

Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Office Development.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)