Differences between in-process and isolated worker process .NET Azure Functions
There are two process models for .NET functions:
| Execution mode | Description |
|---|---|
| In-process | Your function code runs in the same process as the Functions host process. Supports only Long Term Support (LTS) versions of .NET. To learn more, see Develop .NET class library functions. |
| Isolated worker process | Your function code runs in a separate .NET worker process. Use with supported versions of .NET and .NET Framework. To learn more, see Develop .NET isolated worker process functions. |
This article describes the current state of the functional and behavioral differences between the two models. To migrate from the in-process model to the isolated worker model, see Migrate .NET apps from the in-process model to the isolated worker model.
Execution mode comparison table
Use the following table to compare feature and functional differences between the two models:
| Feature/behavior | In-process3 | Isolated worker process |
|---|---|---|
| Supported .NET versions | Long Term Support (LTS) versions6 | Long Term Support (LTS) versions6, Standard Term Support (STS) versions, .NET Framework |
| Core packages | Microsoft.NET.Sdk.Functions | Microsoft.Azure.Functions.Worker Microsoft.Azure.Functions.Worker.Sdk |
| Binding extension packages | Microsoft.Azure.WebJobs.Extensions.* | Microsoft.Azure.Functions.Worker.Extensions.* |
| Durable Functions | Supported | Supported (Support does not yet include Durable Entities) |
| Model types exposed by bindings | Simple types JSON serializable types Arrays/enumerations Service SDK types4 |
Simple types JSON serializable types Arrays/enumerations Service SDK types4 |
| HTTP trigger model types | HttpRequest / IActionResult5 HttpRequestMessage / HttpResponseMessage |
HttpRequestData / HttpResponseData HttpRequest / IActionResult (using ASP.NET Core integration)5 |
| Output binding interactions | Return values (single output only),out parameters,IAsyncCollector |
Return values in an expanded model with: - single or multiple outputs - arrays of outputs |
| Imperative bindings1 | Supported | Not supported - instead work with SDK types directly |
| Dependency injection | Supported | Supported (improved model consistent with .NET ecosystem) |
| Middleware | Not supported | Supported |
| Logging | ILogger passed to the function ILogger<T> via dependency injection |
ILogger<T>/ILogger obtained from FunctionContext or via dependency injection |
| Application Insights dependencies | Supported | Supported |
| Cancellation tokens | Supported | Supported |
| Cold start times2 | Optimized | Configurable optimizations (preview) |
| ReadyToRun | Supported | Supported |
1 When you need to interact with a service using parameters determined at runtime, using the corresponding service SDKs directly is recommended over using imperative bindings. The SDKs are less verbose, cover more scenarios, and have advantages for error handling and debugging purposes. This recommendation applies to both models.
2 Cold start times may be additionally impacted on Windows when using some preview versions of .NET due to just-in-time loading of preview frameworks. This impact applies to both the in-process and out-of-process models but may be noticeable when comparing across different versions. This delay for preview versions isn't present on Linux plans.
3 C# Script functions also run in-process and use the same libraries as in-process class library functions. For more information, see the Azure Functions C# script (.csx) developer reference.
4 Service SDK types include types from the Azure SDK for .NET such as BlobClient. For the isolated process model, Service Bus triggers do not yet support message settlement scenarios.
5 ASP.NET Core types are not supported for .NET Framework.
6 The isolated worker model supports .NET 8 as a preview, currently for Linux applications only. .NET 8 is not yet available for the in-process model. See the Azure Functions Roadmap Update post for more information about .NET 8 plans.
Supported versions
Versions of the Functions runtime support specific versions of .NET. To learn more about Functions versions, see Azure Functions runtime versions overview. Version support also depends on whether your functions run in-process or isolated worker process.
Note
To learn how to change the Functions runtime version used by your function app, see view and update the current runtime version.
The following table shows the highest level of .NET or .NET Framework that can be used with a specific version of Functions.
| Functions runtime version | In-process (.NET class library) |
Isolated worker process (.NET Isolated) |
|---|---|---|
| Functions 4.x | .NET 6.01 | .NET 6.01 .NET 7.02 .NET Framework 4.83 .NET 8.0 (Preview)4 |
| Functions 1.x5 | .NET Framework 4.8 | n/a |
1 Per the .NET Official Support Policy, .NET 6 will reach end of support on November 12, 2024.
2 Per the .NET Official Support Policy, .NET 7 will reach end of support on May 14, 2024.
3 Build process also requires .NET 6 SDK.
4 Preview support for .NET 8 function apps is currently limited to Linux applications. To develop using .NET 8 Preview SDKs in Visual Studio, you must use Visual Studio 2022 Preview. Within Visual Studio, you must also get the latest toolset and template updates by navigating to Tools->Options, selecting Azure Functions under Projects and Solutions, and then clicking the Check for updates button and installing updates as prompted.
5Support will end for version 1.x of the Azure Functions runtime on September 14, 2026. We highly recommend that you migrate your apps to version 4.x for full support.
For the latest news about Azure Functions releases, including the removal of specific older minor versions, monitor Azure App Service announcements.
Next steps
Feedback
Submit and view feedback for