azure-functions-host: Object reference not set to an instance when upgrading to .NET 8

We are experiencing this, even when setting netFrameworkVersion to ‘v8.0’ in our bicep deployment.

@forki Apologies for the delay. We’ve identified a glitch with core tools version 4.0.5455 impacting net8 apps in the default publish action. Not to worry, though – you can manually set the version using the dotnet-version option.

Example command:

func azure functionapp publish shkr-net8-20231203-winc-nrwyeast --dotnet-version '8.0' --force --verbose

I want to express our gratitude for your patience and valuable feedback as we actively work on a fix for core tools. You can track the progress at GitHub Issue #3541.

Thanks again for your understanding.

I had this issue and it turned out to be an error in reporting more than an error in operation.

After going into “Advanced Tools” and downloading the diagnostics dump from the tools menu, it became apparent that the root cause is that the process was falling over before the functions could be registered, which led to the error reported in the console. In my case, it was permissions to another Azure resource (Key Vault).

It would be great if Microsoft surfaced the root cause in this case rather than the one reported.

For others experiencing this issue, I would recommend using the Advanced Tools to get the logs and ensure that you don’t have any issues in the startup sequence.

@kshyju is someone from Microsoft looking into this? seems like many users have this problem

If I run .\node_modules\azure-functions-core-tools\bin\func azure functionapp publish FUNCTIONAPPNAME

the az is doing the following: Setting Functions site property 'netFrameworkVersion' to 'v6.0'

and this resets the .NET 8 flag on the server and I get the Null reference exception again.

@stishkin Is there any reason you are using a specific version tag? I suggest you use the tag without the specific version.

mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0 . Let me know how that goes.

Here is an example of running a minimal NET8 function app with the correct docker image. https://github.com/kshyju/MoreDotnetIsolatedSamples/tree/master/Net8WithDocker

At the risk of being potentially off-topic, we are seeing the same behavior in the Portal when we deploy using “Run from Package” via the ADO “Azure Functions Deploy” task if the app is on .NET 8. Would that be the same problem and will be fixed when Core Tools is fixed?

@kshyju Thanks - this worked great.

We experience exactly the same problems. netFrameworkVersion is set to ‘v8.0’ and use32BitWorkerProcess is set to false and we still get the callstack ‘Object reference is not set to an instance of an object.’

@bvmeer as mentioned above, I believe the solution is in the netFrameworkVersion setting, not the bitness. Can you try that out?

This worked for me.

The framework version is set to net8

After changing the .NET Version to .NET 8 Isolated and Platform to 64 Bit the function started working for me as well.

We’ve upgraded the functions of a pair of projects to NET8 and we’re experiencing the same error. As suggested here (https://learn.microsoft.com/en-us/answers/questions/1340254/how-to-get-specific-detail-causing-azure-function) i checked the “diagnose and solve blade” and found “Detected host offline in your function app.”…

This is the stack trace:

System.NullReferenceException : Object reference not set to an instance of an object.
 
  at async Microsoft.Azure.WebJobs.Script.WorkerFunctionMetadataProvider.GetFunctionMetadataAsync(IEnumerable`1 workerConfigs,Boolean forceRefresh) at /_/src/WebJobs.Script/Host/WorkerFunctionMetadataProvider.cs : 84
 
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 
  at async Microsoft.Azure.WebJobs.Script.WebHost.FunctionMetadataProvider.GetFunctionMetadataAsync(IEnumerable`1 workerConfigs,IEnvironment environment,Boolean forceRefresh) at /_/src/WebJobs.Script/Host/FunctionMetadataProvider.cs : 45
 
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 
  at Microsoft.Azure.WebJobs.Script.FunctionMetadataManager.LoadFunctionMetadata(Boolean forceRefresh,Boolean includeCustomProviders,IFunctionInvocationDispatcher dispatcher,IList`1 workerConfigs) at /_/src/WebJobs.Script/Host/FunctionMetadataManager.cs : 146
 
  at Microsoft.Azure.WebJobs.Script.FunctionMetadataManager.GetFunctionMetadata(Boolean forceRefresh,Boolean applyAllowList,Boolean includeCustomProviders,IList`1 workerConfigs) at /_/src/WebJobs.Script/Host/FunctionMetadataManager.cs : 90
 
  at Microsoft.Azure.WebJobs.Script.DependencyInjection.ExternalConfigurationStartupValidator.Validate(IConfigurationRoot originalConfig) at /_/src/WebJobs.Script/DependencyInjection/ExternalConfigurationStartupValidator.cs : 42
 
  at Microsoft.Azure.WebJobs.Script.DependencyInjection.ExternalConfigurationStartupValidatorService.StartAsync(CancellationToken cancellationToken) at /_/src/WebJobs.Script/DependencyInjection/ExternalConfigurationStartupValidatorService.cs : 33
 
  at async Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)
 
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 
  at async Microsoft.Azure.WebJobs.Script.WebHost.WebJobsScriptHostService.UnsynchronizedStartHostAsync(ScriptHostStartupOperation activeOperation,Int32 attemptCount,JobHostStartupMode startupMode) at /_/src/WebJobs.Script.WebHost/WebJobsScriptHostService.cs : 328

Now, as also suggested in that blade i switched to “64bit” execution and apparently the error is gone (for a single function). I’ll apply these instructions to the other ones we’ll see if solves/improves: https://learn.microsoft.com/en-gb/azure/azure-functions/dotnet-isolated-process-guide#placeholders

It is working fine for me locally.

North Central US 2023-11-16T13:58:46.080 [Error] A host error has occurred during startup operation '08b00628-22b0-4d4a-a873-e49db2e1125d'.

I can’t test locally for unrelated reasons. We’re on West Europe. Here is a invocation ID from .NET 7 (we switched back for now):

2023-11-16T07:38:39Z [Verbose] Posting invocation id:b8ac264d-a483-4502-be95-24211d8fad2c on workerId:4892cc60-6a83-49b6-aab1-9c1025c6b2c5