.NET 5 support on Azure Functions

Published 12-10-2020 11:33 AM 29.7K Views

Update March 10, 2021

Azure Functions now supports .NET 5 in production. See the .NET Roadmap for Azure Functions for more details.



Since the first release of Azure Functions, .NET support has been tightly coupled to the Azure Functions runtime. While this tight integration enables features unique to .NET functions—such as rich binding types—it also means new releases of .NET can only be supported by updating the .NET version of the host.


.NET has adopted a support lifecycle policy that involves a yearly upgrade cycle, with even numbered versions designated as Long Term Support (LTS) releases. .NET 5 is the first Current (non-LTS) release under the new policy. The Azure Functions runtime is a critical component that powers on all of our customers’ production apps and our local development tooling. Because we’re sometimes required to support specific releases of the runtime for extended periods, we cannot upgrade it to a non-LTS version of .NET due to its short support timeline.


To enable .NET 5 in Azure Functions, we are moving to an out-of-process model that runs a .NET 5 worker process alongside the runtime. This is the same out-of-process model that all non-.NET Azure Functions languages have used successfully since Azure Functions V2.


The .NET 5 worker provides a similar Azure Functions programming model that you’re used to. At the same time, because it runs in a separate process, it allows you full control of your app’s dependencies without worrying about conflicts with the dependencies used by the runtime. The .NET 5 worker also introduces new features, such as a customizable middleware pipeline.


Starting today, you can access an early preview of the Azure Functions .NET 5 worker at this GitHub repository. You can run and debug .NET 5 function apps locally and deploy them to Azure using the Azure Functions Core Tools CLI. More tooling support, including Visual Studio and Visual Studio Code, will arrive in the coming weeks.


The .NET 5 worker will be generally available in early 2021.


We realize that customers who are early adopters of .NET 5 have been disappointed by the delay of .NET 5 in Azure Functions. Building a new language worker from scratch has taken some time. We understand your frustration and appreciate your patience. The investment to separate the .NET worker from the runtime will allow us to quickly support future .NET versions. We expect to support .NET 6 LTS as soon as it is released.




dotnet5 early preview cover 2.png

Occasional Visitor

Thank you @Anthony Chu - .NET 5 + middleware support will be a fantastic enhancement for functions.

Occasional Visitor

From the GitHub repository:

"One important difference with .NET 5 functions is that "rich bindings", such as Durable Functions or binding to SDK types like Cosmos DB client, are not supported."


Does this mean they'll never be supported or that they will be supported in a different way?


A lot of us have invested time and money in Durable Functions. Is this now dead ended???

@ericblI have the same thoughts.

Senior Member

@ericbl  I think the "rich-binding" limitation is only because of the "out-of-process" hosting model. So, the current set of features should be supported fine when Azure adds .NET 6 support with current in-process hosting model. Although, I'm not aware of any plans for that support in out-of-process model, at least not in .NET 5.


I understand there is a lot going on under the hood to make the pipeline scale and so on (Features of the Windows Process Activation Service (WAS) | Microsoft Docs)


Does the architecture ultimately create a new app domain? or am I being way to simplistic about how I'm thinking of "out of process"?




@Scotty_Tarvan The functions host spins up a separate process for the worker that's running on .NET 5. The two communicate over a gRPC channel. This is how Azure Functions works for non-.NET languages today.

Occasional Visitor

If we write functions with .NET 5 and this worker, what's the migration process to refactor it to .NET 6 when it's available in Azure? Based on past migrations, I'm guessing it'll be worth waiting for .NET, though maybe it won't be such a pain as it was migrating from .NET Core 1.5 upwards?


@LloydGM As the worker is a NuGet package, you'll be able to update the .NET version when .NET 6 comes out, and stay on the out-of-process worker model.


For .NET 6, you'll have a choice between using the new out-of-process model and the current in-process model.

Occasional Visitor

@Anthony Chu do you have a date to make this generally available? Thanks!

Occasional Visitor

@Anthony Chu What will be the migration path be? If it's going to be a PITA like it was repeatedly upgrading through the various iterations of .NET Core, it's not worth it, and we're better off using something else until Azure catches up. (Seriously, my team alone wasted over 200 hours refactoring our dozen apps through the major Core iterations, and we will never go down that path again.)


@MauricioArroyo Should be any day now. Keep an eye on this blog, the worker repo, or Azure Updates for announcements.


@LloydGM If you're using .NET Core 3.1 on Functions, you do not have to migrate to the out-of-process worker right now. We'll be shipping in-process support for .NET 6 and the migration should be quite smooth.


If you choose to migrate to out-of-process, it does require some refactoring and there may be some functionality that you're using now that is not available yet. However, once you're migrated, the out-of-process worker is just a NuGet package. You're in control of when you upgrade to new versions of .NET or new versions of the worker package.

Occasional Visitor

@Anthony ChuHappy to hear that it should appear any day now. Keeping my fingers corssed. We are waiting for it as well quite heavily.

Occasional Visitor

any news about the release date?

Thanks for help!


@ivan-pesenti Yes. Please take a look at this announcement for more information: https://techcommunity.microsoft.com/t5/apps-on-azure/net-on-azure-functions-roadmap/ba-p/2197916


I've also updated this post with a link to that. Thanks!

Frequent Visitor

Thanks for sharing ~

This is still not an option for visual studio users:
- manual upgrade of all startup DI and http/timer functions 

-no debug support in visual studio

-no deployment via azure pipelines


Tried to upgrade, read the articles, gave up after half a day and we only have about 200 functions. Large solutions may have thousands of functions. 





Occasional Visitor

@Scotty_Tarvan that's incorrect. There's debugging and there's azure deployments through the azure cli.

Occasional Visitor

The Isolated Az Function is like webjobs because it's a console app and it's hosted like an application (IMO, it's not serverless anymore). So what's the advantage of az function over webjob here?


@jamestran Event driven scaling and consumption pricing. The fact that the build output is an exe is an implementation detail. Your app scales the same way as .NET in process and other languages. There are also no changes in billing, you are still only billed when functions are executing.

Version history
Last update:
‎Mar 23 2021 10:02 AM
Updated by: