Azure Functions With .Net 5 - Execution On Isolated Process

Last year on November 10, 2020; .Net 5 was released. And Azure Functions, one of the biggest features for Azure, was left out of the release. It wasn't until March 10, 2021, that a new version was released to support .Net 5.

But with this new release, we found a new approach to the execution model. Here is where we now can see that Azure Functions are executed in an Isolated Process. But what is about this Isolated Process execution?

Since their inception the .Net and .Net Core function applications have run in the same host process, bringing with them unique advantages such as having a set of bindings and injections to the SDK. But on the other hand, the execution of functions for other languages is executed in an “out-of-process” model (outside the process) that allows executing the functionality in a separate process. That is, under the execution of a process that in turn is in charge of the execution of the functions.

And this is where the Azure Functions development and support team decides to adopt this model for .Net 5 support. Thus, if we want to work on this version, we will find a new way of working.

The first change that we are going to notice is that when we create a new project, let's say in Visual Studio, we will find the presence of the Program.cs class. Which is the entry point of the execution of the functions, that is, the process in charge of the execution.

Azure Functions with .Neet 5 - Execution on Isolated Process

Previously in Azure Functions for .Net Core 3.1, we could create a class that inherits from FunctionsStartup so that it is executed on launch. But in this aproach, we already have this functionality already in our projects.

Another change that we are going to find is that the base Nuget packages that we are going to use will be,

Microsoft.Azure.Functions.Worker
Microsoft.Azure.Functions.Worker.Sdk

and the link extension packages will be,

Microsoft.Azure.Functions.Worker.Extensions.*

Where * represents the trigger package (s) that we will be using in our functions. For instance,

Microsoft.Azure.Functions.Worker.Extensions.Http
Microsoft.Azure.Functions.Worker.Extensions.Timer

Here is a table with the changes or differences with Azure Functions for .Net 3.1

Feature/behavior In-process (.NET Core 3.1) Out-of-process (.NET 5.0)
.NET versions LTS (.NET Core 3.1) Current (.NET 5.0)
Core packages Microsoft.NET.Sdk.Functions Microsoft.Azure.Functions.Worker
Microsoft.Azure.Functions.Worker.Sdk
Binding extension packages Microsoft.Azure.WebJobs.Extensions.* Under Microsoft.Azure.Functions.Worker.Extensions.*
Logging ILogger passed to the function ILogger obtained from FunctionContext
Cancellation tokens Supported Not supported
Output bindings Out parameters Return values
Output binding types IAsyncCollectorDocumentClientBrokeredMessage, and other client-specific types Simple types, JSON serializable types, and arrays.
Multiple output bindings Supported Supported
HTTP trigger HttpRequest/ObjectResult HttpRequestData/HttpResponseData
Durable Functions Supported Not supported
Imperative bindings Supported Not supported
function.json artifact Generated Not generated
Configuration host.json host.json and custom initialization
Dependency injection Supported Supported
Middleware Not supported Supported
Cold start times Typical Longer, because of just-in-time start-up. Run on Linux instead of Windows to reduce potential delays.
ReadyToRun Supported TBD

** https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide#differences-with-net-class-library-functions


Similar Articles