.NET 10 isolated host fails on Linux EP1; .NET 8 succeeds

Question

.NET 10 isolated host fails on Linux EP1; .NET 8 succeeds

Misha Anker 41

I am trying to upgrade an Azure Functions v4 app from .NET isolated 8.0 to .NET isolated 10.0. Environment:

Azure Functions v4, .NET isolated

Linux Elastic Premium EP1

UK South

ASP.NET Core HTTP functions

Deployed as a ZIP package

Worker packages include Microsoft.Azure.Functions.Worker 2.52.0 and Worker.Sdk 2.1.0 The production app is healthy on: dotnet-isolated|8.0 To isolate the issue, I created a deployment slot cloned from the healthy production app. The timer trigger was disabled only in the slot to prevent side effects. Results in the same slot:

.NET 8

Deployed the known-working production ZIP.

The host started successfully.

An unknown route returned HTTP 404 rather than a platform 503.

syncfunctiontriggers returned: {"status":"success"}

.NET 10

Published the current application targeting net10.0.

ZIP deployment completed successfully.

Changed only the slot runtime to: DOTNET-ISOLATED|10.0

The host then failed before any application telemetry appeared.

Requests returned HTTP 503.

syncfunctiontriggers returned: Encountered an error (ServiceUnavailable) from host runtime.

Rollback

Restoring the slot to dotnet-isolated|8.0 and the known-working ZIP immediately restored normal host behaviour and successful trigger synchronization. No swap to production was performed. Production remains healthy on .NET 8. Is this a known issue or limitation with .NET isolated 10.0 on Linux Elastic Premium Function Apps? Are there specific host image, runtime, or configuration requirements for .NET 10 isolated that should be applied? It's not occuring in the development instance which is a standard consumption plan

0 comments

1 answer

Your answer

Answer 1

Hola Misha,

The hosting plan itself shouldn't be the limitation here. Microsoft currently supports .NET 10 on Azure Functions v4 using the isolated worker model, and the Linux restriction they document applies to the Linux Consumption plan, not Elastic Premium.

There is one configuration detail in your post that I'd address before looking at the EP1 environment. For .NET 10, Microsoft's current requirements are Microsoft.Azure.Functions.Worker 2.50.0 or later and Azure.Functions.Sdk 1.0.0 or later as the build SDK. You're already on Worker 2.52.0, but you're still using Microsoft.Azure.Functions.Worker.Sdk 2.1.0.

Microsoft's current migration guidance is to change the project SDK from Microsoft.NET.Sdk to Azure.Functions.Sdk/1.0.0, remove the Microsoft.Azure.Functions.Worker.Sdk package reference, and keep Microsoft.Azure.Functions.Worker at a supported version.

So I'd test that change first and rebuild the ZIP from a clean restore before changing anything else in the Function App. That gives you a deployment built using Microsoft's currently documented .NET 10 toolchain rather than the older Worker.Sdk build path.

If it still fails after that, the next thing I'd want is the first host/worker startup error from the EP1 slot. Since you're getting a 503 before application telemetry appears and syncfunctiontriggers also fail, the likely cause is an error below the application layer. You can check the Function App filesystem under: /home/LogFiles/Application/Functions/Host/

Look at the log generated immediately after starting the .NET 10 deployment. An error indicating that the required .NET runtime isn't installed, that the dotnet Worker failed to launch, or that an assembly couldn't be loaded would quickly distinguish a platform image/runtime problem from a deployment package problem.

There has also been a very similar Azure Functions issue reported for .NET 10 on Linux, where .NET 8 worked, while the deployed host couldn't find the .NET 10 runtime.

Thanks,

James