Article originally posted on InfoQ. Visit InfoQ

Microsoft announced on September 26th that Azure Functions runtime v4 will support running .NET Framework 4.8 functions in an isolated process, allowing the developers to move their legacy .NET functions to the latest runtime. The isolated process execution decouples the function code from the Azure Functions’ host runtime, which in turn allows running different .NET frameworks within a single environment.

Azure Functions now offer four runtime versions for functions written in .NET:

• v1: Runs on .NET Framework 4.8 only. Supported without end-of-life announcement yet. No security updates.
• v2: Runs on .NET Core 2.1. currently not supported for new functions. No security updates.
• v3: Runs on .NET Core 3.1. Supported until December 2022 (linked to .NET 3.1 end-of-life).
• v4: Runs on .NET 6 but supports all versions of .NET (including .NET Framwork 4.8) when running in isolated mode.

Azure Functions runtime v4 introduces isolated process execution. Until v4, function code runs in the same context of the underlying function host process that’s running on the server. It allows for fast performance and startup time, but it ties the developer to the .NET version that the runtime is using.

Isolated process execution launches the function code in a separate console application on the function host server. The function host then invokes the function code using inter-process communication. According to Microsoft’s announced Azure Functions roadmap update, the in-process and isolated process execution models will coexist in v4 runtime until feature and performance parity is achieved. Once a sufficient parity is achieved, the runtime will only allow isolated process execution.

From the technical perspective there are some adjustments that developers have to do to change their existing functions to run in an isolated process, outlined by Microsoft in a quick guide in the documentation. Functions running inside an isolated process can’t use direct trigger and binding references (such as accessing the BrokeredMessage when binding to a Service Bus queue). They can only use simple data types and arrays. The original HTTP context is available as an instance of HttpRequestData class. In the same fashion, writing to a HTTP output is achieved using HttpResponseData class. The Azure Function runtime manages the mapping of those classes to the real HttpContext instance. Developers will also have to update unit tests that cover existing in-process function classes, using fake data for incoming HTTP data. One such approach has been explained by Carlton Upperdine on his blog.

The bindings for functions running in an isolated process are different from the bindings of in-process functions. While the in-process ones leverage the underlying Azure WebJob definitions and bindings, isolated process functions must add the Microsoft.Azure.Functions.Worker.Extensions NuGet packages.

On the other hand, using the isolated process execution will allow developers to build the underlying host pipeline in the Program.cs file, like the way ASP.NET Core applications build their own execution host. It supports building custom middlewares and injecting dependencies in a straightforward fashion. For convenience, there is a ConfigureFunctionsWorkerDefaults method that sets up the host execution pipeline with integrated logging, a default set of binders, adds gRPC support and correctly sets up the JSON serializer for property casing.