| title | description | ms.service | ms.custom | ms.topic | ms.date | recommendations | ||
|---|---|---|---|---|---|---|---|---|
Differences between in-process and isolate worker process .NET Azure Functions |
Compares features and functionality differences between running .NET Functions in-process or as an isolated worker process. |
azure-functions |
|
conceptual |
08/03/2023 |
false |
There are two execution models for .NET functions:
[!INCLUDE functions-dotnet-execution-model]
[!INCLUDE functions-in-process-model-retirement-note]
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.
Use the following table to compare feature and functional differences between the two models:
| Feature/behavior | Isolated worker model | In-process model3 |
|---|---|---|
| Supported .NET versions | Long Term Support (LTS) versions, Standard Term Support (STS) versions, .NET Framework |
Long Term Support (LTS) versions, ending with .NET 8 |
| Core packages | Microsoft.Azure.Functions.Worker Microsoft.Azure.Functions.Worker.Sdk |
Microsoft.NET.Sdk.Functions |
| Binding extension packages | Microsoft.Azure.Functions.Worker.Extensions.* | Microsoft.Azure.WebJobs.Extensions.* |
| Durable Functions | Supported | Supported |
| 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 | HttpRequestData / HttpResponseData HttpRequest / IActionResult (using ASP.NET Core integration)5 |
HttpRequest / IActionResult5 HttpRequestMessage / HttpResponseMessage |
| Output binding interactions | Return values in an expanded model with: - single or multiple outputs - arrays of outputs |
Return values (single output only),out parameters,IAsyncCollector |
| Imperative bindings1 | Not supported - instead work with SDK types directly | Supported |
| Dependency injection | Supported (improved model consistent with .NET ecosystem) | Supported |
| Middleware | Supported | Not supported |
| Logging | ILogger<T>/ILogger obtained from FunctionContext or via dependency injection |
ILogger passed to the functionILogger<T> via dependency injection |
| Application Insights dependencies | Supported | Supported |
| Cancellation tokens | Supported | Supported |
| Cold start times2 | Configurable optimizations | Optimized |
| ReadyToRun | Supported | Supported |
| [Flex Consumption] | Supported | Not 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 could 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 can 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.
5 ASP.NET Core types are not supported for .NET Framework.
[!INCLUDE functions-dotnet-supported-versions]
[!div class="nextstepaction"] Learn more about the isolated worker model
[!div class="nextstepaction"] Migrate to the isolated worker model