This post was most recently updated on March 25th, 2023.
2 min read.Let me start this article, by reminding everyone that Azure Functions are awesome, and you should use them despite some hiccups. Having said that, let’s fix some errors!
At the beginning of September 2018, Microsoft started pushing out breaking changes to Azure Functions 2.x. They had announced this a full month in advance, so they expected everyone in the world to update their Azure Functions to avoid the functions from breaking.
I guess, however, that in real life, a month is not that much. I, and a bunch of other people on the internet, ran into some issues with our Azure Functions. This post will describe what I did to fix them!
What happened?
The announcement (I also recall getting an email about this):
If you are running on the Azure Functions 2.0 preview and don’t want your app to break, you need to pin your Function App by following the instructions in the What can I do to avoid being impacted? section at the bottom of this announcement.
https://github.com/Azure/app-service-announcements/issues/129
I didn’t take action. So later on, I ran into issues.
What kind of issues, then? Well, I started getting these errors (even when locally trying to debug):
System.Private.CoreLib: Could not load type ‘Microsoft.Azure.WebJobs.ExecutionContext’ from assembly ‘Microsoft.Azure.WebJobs.Extensions, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’. … The following [X] functions are in error: [FunctionName]: Object reference not set to an instance of an object.
Azure Functions Runtime
Object reference? What object reference?
In fact, the error is referring to missing configuration keys in your host.json file!
The issue, at least for me, was caused by the breaking changes Microsoft pushed out. Starting from 2.0.12050-alpha, a lot of new configuration keys have been moved to host.json, the schema has changed, and you just need to do some tweaking in general.
Below, I’ll go through the steps to fix the issue!
SOLUTION
Fix the errors by tweaking your local.settings.json & host.json
Time needed: 10 minutes
For me, these steps fixed the issue:
Add these (or similar) to your local.settings.json
-
{
"version": "2.0",
"extensions": {
"http": {
"routePrefix": "api",
"maxConcurrentRequests": 5,
"maxOutstandingRequests": 30
},
}
}
The rest of the implementation was omitted for clarity. You might have something else in your “extensions” since you might not be triggering on HTTP calls, but rather using some other integration available. - Additionally, add these to your host.json:
{
"Values": {
// this means you'll be locking your Azure Functions App Service to running only .NET languages (typically C#). Other possibilities are "java" and "node"
"FUNCTIONS_WORKER_RUNTIME": "dotnet"
}
}
Again, the rest of the implementation was omitted for clarity. Only new additions are shown here. - To ensure, that your local Azure Functions CLI actually applies these changes, you might want to set your host.json and local.settings.json to be copied to the output directory automatically, so that your CLI actually picks them up when you start debugging. See below how to do that:
Setting your local.settings.json and host.json to be always copied to the output directory in your local builds to enable Azure Functions CLI to access the newest values of your configuration
With these changes, you should be good!
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 Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
- “Critical Error – Your Start menu isn’t working” - April 23, 2024
- How to export a CSR you’ve created on Windows? - April 16, 2024
- How to output all Environment Variables in Azure DevOps with PowerShell? - April 9, 2024
