Azure Functions Adds .NET 11 Support: Required SDK, Isolated Worker and Hosting Restrictions

What shipped​

The announcement says developers can build new serverless apps on .NET 11 or update existing isolated worker apps to target it. Microsoft's Learn documentation describes the support more precisely. Support is currently available for C# apps. The Microsoft blog post adds that F# support is temporarily unavailable.

Microsoft's Learn guide says .NET 11 runs on Azure Functions runtime 4.x in the isolated worker model, and the in-process model doesn't support it. Learn's supported-languages table lists .NET 11 as GA with an end-of-support date of "See policy." .NET 10 is listed with an end-of-support date of November 14, 2028.

The Azure Updates page for this item rendered "0 Updates found" when it was fetched. The Microsoft Community Hub announcement and the Learn documentation therefore carry the details. This article relies on those.

The new project SDK: Azure.Functions.Sdk​

The release introduces a required project SDK for .NET 11 function apps: Azure.Functions.Sdk. Before, you declared Microsoft.NET.Sdk and added the Microsoft.Azure.Functions.Worker.Sdk package as a reference. Now the Functions build integration goes into the Project element's SDK declaration.

Microsoft says the new SDK:

• Supplies the underlying .NET SDK.
• Sets AzureFunctionsVersion to v4.
• Adds the analyzers and source generators that prepare functions for deployment.
• Integrates with Functions tooling, so dotnet run starts the Functions host when Azure Functions Core Tools is installed.

The SDK replaces the build SDK package, not the worker runtime package. Keep an explicit Microsoft.Azure.Functions.Worker reference, plus the trigger and binding extension packages your functions use. The Learn guide says the explicit reference lets NuGet resolve the highest worker version your dependency graph requires. If the package is missing after restore, the SDK emits diagnostic AZFW0111.

Versions that matter​

• Azure.Functions.Sdk: use version 1.0.1 or later for .NET 11.
• Microsoft.Azure.Functions.Worker: Microsoft recommends 2.50.0 or later. The Learn guide calls this the same baseline as .NET 10.
• Template example versions: The generated project uses Worker 2.52.0, OpenTelemetry 1.2.0, and ASP.NET Core HTTP integration 2.1.1. Microsoft says these reflect the current template and are not minimums for every app.

The template pulls in OpenTelemetry and ASP.NET Core HTTP integration packages. Keep or trim them to match your telemetry and trigger setup.

Getting started​

1. Install the .NET 11 SDK.
2. Update your Azure Functions development tools and templates.
3. With the updated Core Tools, run:

func init --worker-runtime dotnet-isolated --target-framework net11.0

1. Check that the generated project uses Azure.Functions.Sdk and targets net11.0. Keep the template's worker reference and add the binding extensions your functions need.
2. Build and run locally.
3. Deploy to a function app configured for the .NET 11 isolated worker stack.

Success means the generated project declares the new SDK and net11.0. It also means the app runs locally under dotnet run or the Functions host and deploys to an app set to the .NET 11 isolated stack.

Upgrading an existing isolated worker app​

Microsoft's recommended order:

1. Update dependencies and check compatibility with .NET 11.
2. Change the project SDK to Azure.Functions.Sdk/1.0.1 and the target framework to net11.0.
3. Remove the Microsoft.Azure.Functions.Worker.Sdk package reference.
4. Keep an explicit Microsoft.Azure.Functions.Worker reference.
5. Remove OutputType and AzureFunctionsVersion, since the new SDK sets them.
6. Remove FunctionsEnableWorkerIndexing if it's present. Worker indexing is always on with the new SDK.

Microsoft says the build SDK migration itself doesn't require changes to Program.cs, function classes, or host.json when you use a current worker package. That claim covers the SDK swap only. Moving to .NET 11 is a separate framework upgrade, so test your triggers, bindings, and deployment before production.

Common failure points​

Still on in-process​

Learn is explicit: the in-process model supports only .NET 8, and you must migrate to isolated worker to use a later version. Microsoft lists November 10, 2026 as the end of in-process support. That is the same day as this announcement, so teams on in-process need to migrate. Changing TargetFramework won't get you there.

Linux Consumption​

.NET 11 is supported only in the isolated worker model. Separately, the announcement says Linux Consumption doesn't support .NET 10 or later. Apps on that plan should review the Flex Consumption migration guidance before upgrading. Learn also says .NET 9 is the last .NET version supported on Linux Consumption. It says the plan is retiring on September 30, 2028, and that Windows Consumption apps aren't currently affected. That retirement is existing documentation, not part of this GA announcement.

Custom containers​

Microsoft says .NET 11 Functions base images are published as chiseled images. Use mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated11.0-chiseled. The 4-dotnet-isolated11.0 and 4-dotnet-isolated11.0-appservice tags aren't published. Chiseled images include no shell or SSH server. If your Dockerfile or debugging workflow assumes a shell, plan for that.

Tooling​

Windows developers should note one detail from the Learn guide. With the new SDK, dotnet run support requires Core Tools, and on Windows you should install Core Tools through a mechanism other than npm.

Pre-release signals​

Microsoft's engineering tracking issue for the worker repository shows how the rollout went. As of an October 5, 2026 update, Azure Functions Core Tools v4.15.2 supported .NET 11 isolated worker apps. The VS Code Azure Functions extension v1.22.2 did too. At that point, .NET 11 runtime support was available on Flex Consumption and Linux Dedicated plans. The same update noted Visual Studio support had not yet shipped publicly, and that platform images then contained .NET 11 Preview 7 bits. That is a snapshot from October. Check the current state of your tools before upgrading.

What this doesn't establish​

The sources reviewed don't show any of the following:

• A pricing change.
• A regional rollout list.
• A performance gain.
• New triggers or bindings.

Treat the release as a runtime and tooling support milestone. Don't treat it as a feature drop.

Bottom line​

For teams already on isolated worker with a current worker package, the path is mostly a project-file edit. Swap the SDK, retarget to net11.0, drop the old SDK package, and test. For teams on in-process or Linux Consumption, the work is bigger: migrate the execution model or hosting plan first, then think about .NET 11.