Azure Functions in .NET 7: The Mandatory Isolated Process

Azure Functions is a major component of the Serverless resources provided by Microsoft.

First seen in early 2022, the new .NET 7 framework brings some changes for Azure’s cloud. And notably a not-so-visible but significant change for Azure Functions appears: the Isolated Process will be the only possible hosting model.

Azure Functions

As Microsoft’s documentation aptly puts it:

Firstly, Azure Functions allow you to implement your system’s logic in readily available code blocks, which are called “functions”. Different functions can run whenever you need to respond to critical events.

Secondly, as requests increase, Azure Functions respond to the demand with as many resources and function instances as necessary, but only when needed. When demands decrease, additional resources and application instances automatically reduce.

The In Process vs Isolated Process

In Process and Isolated Process

In Process and Isolated Process are two different hosting models for Azure Functions. The first runs the Azure Functions runtime in the same process as the web application, API, or platform that hosts it. This can improve the performance and efficiency of functions but also means that any function-related issue can affect the overall hosting process.

Isolated Process hosting, on the other hand, runs the Azure Functions runtime in a separate process from the web application or hosting platform. This provides a higher degree of isolation and can prevent function-related issues from affecting the hosting process. However, this could also lead to a decrease in performance and efficiency compared to in-process hosting.

In .NET 6, the choice between In Process hosting and Isolated Process hosting depends on the specific requirements and needs of your Azure Functions and the hosting environment. However, starting from .NET 7, the choice has been made for you.

Code Changes

The csproj

To start, the .csproj is slightly different:

The important things to remember are:

• the <OutputType> set to Exe
• the dependency changes (focus on that later).

Settings

A quick look at the local.settings.json file (in the app settings on Azure) where we specify that the function is indeed in dotnet isolated:

This will therefore imply the same change in the App Settings of the Function App.

The startup / program

Then we see a change in the function implementation. Dependency injection that is done in a Startup.cs file created in In Process is now done in the Program.cs file:

In Process (Startup.cs):

using Microsoft.Azure.Functions.Extensions.DependencyInjection; 
using Microsoft.Extensions.DependencyInjection; 

[assembly: FunctionsStartup(typeof(FAProjet.Startup))] 

namespace FAProjet 
{ 
    public class Startup : FunctionsStartup 
    { 
        public override void Configure(IFunctionsHostBuilder builder) 
        { 
            builder.Services.AddLogging(); 
            builder.Services.AddHttpClient(); 
            builder.Services.AddSingleton<IApiClientService, ApiClientService>(); 
        } 
    } 
}

Isolated Process (Program.cs):

using Microsoft.Extensions.Configuration; 
using Microsoft.Extensions.DependencyInjection; 
using Microsoft.Extensions.Hosting; 

var host = new HostBuilder() 
    .ConfigureServices(services => 
    { 
        services 
            .AddLogging() 
            .AddHttpClient() 
            .AddSingleton<IApiClientService, ApiClientService>(); 
    }) 
    .ConfigureFunctionsWorkerDefaults() 
    .Build(); 

host.Run();

The Functions

Finally, we get to the heart of the matter with the changes in the functions themselves, which boil down to two things:

• the [FunctionName(“…”)] attribute becomes (drum roll) simply [Function(“”)]
• the triggers evolve in their uses

In Process:

using Microsoft.AspNetCore.Http; 
using Microsoft.AspNetCore.Mvc; 
using Microsoft.Azure.WebJobs; 
using Microsoft.Azure.WebJobs.Extensions.Http; 
using Microsoft.Extensions.Logging; 
using Newtonsoft.Json; 

namespace FunctionAppNet6 
{ 
    public static class Function1 
    { 
        [FunctionName("Function1")] 
        public static async Task<IActionResult> Run( 
            [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req, 
            ILogger log) 
        { 
            log.LogInformation("C# HTTP trigger function processed a request."); 

            string name = req.Query["name"]; 

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync(); 
            dynamic data = JsonConvert.DeserializeObject(requestBody); 
            name = name ?? data?.name; 

            string responseMessage = string.IsNullOrEmpty(name) 
                ? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response." 
                : $"Hello, {name}. This HTTP triggered function executed successfully."; return new OkObjectResult(responseMessage); 
        } 
    } 
}

Isolated Process:

using System.Net; 
using Microsoft.Azure.Functions.Worker; 
using Microsoft.Azure.Functions.Worker.Http; 
using Microsoft.Extensions.Logging; 

namespace FunctionAppNet7 
{ 
    public class Function1 
    { 
        [Function("Function1")] 
        public HttpResponseData Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req, 
            ILogger logger) 
        { 
            logger.LogInformation("C# HTTP trigger function processed a request."); 

            var response = req.CreateResponse(HttpStatusCode.OK); 
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8"); 

            response.WriteString("Welcome to Azure Functions!"); 

            return response; 
        } 
    } 
}