The following functions are in error... And that's about it.

Fixing “The following functions are in error: Object reference not set to an instance of an object.” error in Azure Functions

This post was most recently updated on March 5th, 2019.

Reading Time: 3 minutes.

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!

In 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. Me, 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!

Fixing the errors by tweaking your local.settings.json & host.json

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 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 omitted for clarity. Only new additions 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 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 output directory in your local builds to enable Azure Functions CLI to acces newest values of your configuration
Setting your local.settings.json and host.json to be always copied to output directory in your local builds to enable Azure Functions CLI to acces newest values of your configuration

With these changes, you should be good!

Antti K. Koskela

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 a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world.

He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.

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

Leave a Reply

avatar
5000
  Subscribe  
Notify of