In last two articles, we have created an HTTP Triggered Azure Functions and we also have seen how the OpenAPI (Swagger page) can be enabled on existing project.

This article does not directly focus on the coding part. This article is going to explain an important basic concept about Azure Functions – execution models.

There are three different execution models supported and we are going to have a quick overview of these execution models.

What are execution models ?

Let’s first understand what does the term “execution model” mean.

Execution model of the Azure Functions decide how the code would be executed. The Azure Functions, when deployed, basically a host process is running on the server. Execution model decides whether “our” code would execute as a part of same process or whether it would execute in isolation.

Let’s have an overview of both execution models in the coming sections.

Note that these execution models are applicable for only .NET based Azure Functions.

In Process

As the name suggests, in-process model means the code would be executed as part of Azure Functions host process. This type of execution model supports only Long Term Support (LTS) versions of .NET. 

There is also another input – Functions Runtime Version. This version can be 1.x, 2.x, 3.x or 4.x – as of today. This version decides the .NET version (or .NET Framework version) that would be used by the process.

• When functions runtime is 1.x and execution model is in-process, the .NET Framework v4.8 is used as target version.
• For functions runtime version 2.x and 3.x with in-process execution model, the .NET Core versions 2.1 and 3.1 are used as target frameworks.
• For 4.x runtime version with in-process execution model, the .NET LTS version .NET 6 is used as target .NET version.

Isolated Worker Process

Now, let’s understand this execution model.

As the name suggests, here the code that we deployed does not run as a part of Functions host process. Initially, when Azure Functions were launched, they were supporting only in-process mode. The in-process mode also brings one limitation – the class library which contains the code for functions, needs to target to the same .NET version, which is used by the functions host process. This means you can use only LTS versions of .NET, while creating Azure Functions class library project.

With isolated worker process execution model, the library which contains functions code can have different .NET version than the host’s .NET version – as they are not running as part of same process. With this execution model, we – as a developer – get complete control over the process startup, middlewares used and configurations used.

How to select execution model while creating new project ?

When we are creating new Azure Functions project using Visual Studio, there is an option to select intended execution model. Surprisingly, the input name is not so obvious there. The input label says “Functions worker“, but the input is for selecting execution model. Although this existing label may be meaningful for some developers, I think it is not very obvious.

Anyway, the snapshot given below shows the options provided in the dropdown. The entries which has suffix isolated, are basically options for isolated worker process model.

When this project is created, the template has code to setup a Host (similar to Host in let’s say Web API project templates). This Host object then can be used to setup dependency injections, or initialize any custom configurations, or any other dependencies.

The in-process Azure Functions project is basically a class library while the isolated worker process project’s output type is console application. Both project contains both host.json and local.settings.json files.

I think that’s it for today’s post ! I hope you find this information helpful. Let me know which execution model are you using and if you find any reasons to change the execution model.