You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-functions/dotnet-isolated-in-process-differences.md
+2-3Lines changed: 2 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ Use the following table to compare feature and functional differences between th
27
27
28
28
| Feature/behavior | Isolated worker model | In-process model<sup>3</sup> |
29
29
| ---- | ---- | ---- |
30
-
|[Supported .NET versions](#supported-versions)| Long Term Support (LTS) versions,<br/>Standard Term Support (STS) versions,<br/>.NET Framework | Long Term Support (LTS) versions<sup>6</sup>|
30
+
|[Supported .NET versions](#supported-versions)| Long Term Support (LTS) versions,<br/>Standard Term Support (STS) versions,<br/>.NET Framework | Long Term Support (LTS) versions, ending with .NET 8|
|[Flex Consumption]|[Supported](./flex-consumption-plan.md#supported-language-stack-versions)| Not supported |
45
46
46
47
<sup>1</sup> 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.
47
48
@@ -53,8 +54,6 @@ Use the following table to compare feature and functional differences between th
53
54
54
55
<sup>5</sup> ASP.NET Core types are not supported for .NET Framework.
55
56
56
-
<sup>6</sup> .NET 8 is not yet supported on the in-process model, though it is available on the isolated worker model. For information about .NET 8 plans, including future options for the in-process model, see the [Azure Functions Roadmap Update post](https://aka.ms/azure-functions-dotnet-roadmap).
Copy file name to clipboardExpand all lines: articles/azure-functions/functions-app-settings.md
+15-5Lines changed: 15 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -390,6 +390,16 @@ The following major runtime version values are supported:
390
390
|`~2`| 2.x | No longer supported |
391
391
|`~1`| 1.x | Support ends September 14, 2026 |
392
392
393
+
## FUNCTIONS\_INPROC\_NET8\_ENABLED
394
+
395
+
Indicates whether to an app can use .NET 8 on the in-process model. To use .NET 8 on the in-process model, this value must be set to `1`. See [Updating to target .NET 8](./functions-dotnet-class-library.md#updating-to-target-net-8) for complete instructions, including other required configuration values.
396
+
397
+
|Key|Sample value|
398
+
|---|------------|
399
+
|FUNCTIONS_INPROC_NET8_ENABLED|`1`|
400
+
401
+
Set to `0` to disable support for .NET 8 on the in-process model.
This app setting is a temporary way for Node.js apps to enable a breaking change that makes entry point errors easier to troubleshoot on Node.js v18 or lower. It's highly recommended to use `true`, especially for programming model v4 apps, which always use entry point files. The behavior without the breaking change (`false`) ignores entry point errors and doesn't log them in Application Insights.
@@ -405,11 +415,6 @@ For Node.js v18 or lower, the app setting can be used and the default behavior d
405
415
|FUNCTIONS\_NODE\_BLOCK\_ON\_ENTRY\_POINT\_ERROR|`true`|Block on entry point errors and log them in Application Insights.|
406
416
|FUNCTIONS\_NODE\_BLOCK\_ON\_ENTRY\_POINT\_ERROR|`false`|Ignore entry point errors and don't log them in Application Insights.|
407
417
408
-
## FUNCTIONS\_V2\_COMPATIBILITY\_MODE
409
-
410
-
>[!IMPORTANT]
411
-
> This setting is no longer supported. It was originally provided to enable a short-term workaround for apps that targeted the v2.x runtime to be able to instead run on the v3.x runtime while it was still supported. Except for legacy apps that run on version 1.x, all function apps must run on version 4.x of the Functions runtime: `FUNCTIONS_EXTENSION_VERSION=~4`. For more information, see [Azure Functions runtime versions overview](functions-versions.md).
412
-
413
418
## FUNCTIONS\_REQUEST\_BODY\_SIZE\_LIMIT
414
419
415
420
Overrides the default limit on the body size of requests sent to HTTP endpoints. The value is given in bytes, with a default maximum request size of 104857600 bytes.
@@ -418,6 +423,11 @@ Overrides the default limit on the body size of requests sent to HTTP endpoints.
> This setting is no longer supported. It was originally provided to enable a short-term workaround for apps that targeted the v2.x runtime to be able to instead run on the v3.x runtime while it was still supported. Except for legacy apps that run on version 1.x, all function apps must run on version 4.x of the Functions runtime: `FUNCTIONS_EXTENSION_VERSION=~4`. For more information, see [Azure Functions runtime versions overview](functions-versions.md).
430
+
421
431
## FUNCTIONS\_WORKER\_PROCESS\_COUNT
422
432
423
433
Specifies the maximum number of language worker processes, with a default value of `1`. The maximum value allowed is `10`. Function invocations are evenly distributed among language worker processes. Language worker processes are spawned every 10 seconds until the count set by `FUNCTIONS_WORKER_PROCESS_COUNT` is reached. Using multiple language worker processes isn't the same as [scaling](functions-scale.md). Consider using this setting when your workload has a mix of CPU-bound and I/O-bound invocations. This setting applies to all language runtimes, except for .NET running in process (`FUNCTIONS_WORKER_RUNTIME=dotnet`).
> Targeting .NET 8 with the in-process model is not yet enabled for Linux, for apps hosted in App Service Environments, or for apps in sovereign clouds. Updates will be communicated on [this tracking thread on GitHub](https://github.com/Azure/azure-functions-host/issues/9951).
36
+
37
+
Apps using the in-process model can target .NET 8 by following the steps outlined in this section. However, if you choose to exercise this option, you should still begin planning your [migration to the isolated worker model](./migrate-dotnet-to-isolated-model.md) in advance of [support ending for the in-process model on November 10, 2026](https://aka.ms/azure-functions-retirements/in-process-model).
38
+
39
+
Many apps can change the configuration of the function app in Azure without updates to code or redeployment. To run .NET 8 with the in-process model, three configurations are required:
40
+
41
+
- The [application setting](./functions-how-to-use-azure-function-app-settings.md)`FUNCTIONS_WORKER_RUNTIME` must be set with the value "dotnet".
42
+
- The application setting `FUNCTIONS_EXTENSION_VERSION` must be set with the value "~4".
43
+
- The application setting `FUNCTIONS_INPROC_NET8_ENABLED` must be set with the value "1".
44
+
- You must [update the stack configuration](./update-language-versions.md#update-the-stack-configuration) to reference .NET 8.
45
+
46
+
Support for .NET 8 still uses version 4.x of the Functions runtime, and no change to the configured runtime version is required.
47
+
48
+
To update your local project, first make sure you are using the latest versions of local tools. Then ensure that the project references [version 4.4.0 or later of Microsoft.NET.Sdk.Functions](https://www.nuget.org/packages/Microsoft.NET.Sdk.Functions/4.4.0). You can then change your `TargetFramework` to "net8.0". You must also update `local.settings.json` to include both `FUNCTIONS_WORKER_RUNTIME` set to "dotnet" and `FUNCTIONS_INPROC_NET8_ENABLED` set to "1".
49
+
50
+
The following is an example of a minimal `local.settings.json` file with these changes:
| 4.x | GA |**_Recommended runtime version for functions in all languages._** Check out [Supported language versions](#languages). |
17
-
| 1.x | GA ([support ends September 14, 2026](https://aka.ms/azure-functions-retirements/hostv1)) | Supported only for C# apps that must use .NET Framework. This version is in maintenance mode, with enhancements provided only in later versions. **Support will end for version 1.x on September 14, 2026.** We highly recommend you [migrate your apps to version 4.x](migrate-version-1-version-4.md?pivots=programming-language-csharp), which supports .NET Framework 4.8, .NET 6, .NET 7, and .NET 8.|
17
+
| 1.x | GA ([support ends September 14, 2026](https://aka.ms/azure-functions-retirements/hostv1)) | Supported only for C# apps that must use .NET Framework. This version is in maintenance mode, with enhancements provided only in later versions. **Support will end for version 1.x on September 14, 2026.** We highly recommend you [migrate your apps to version 4.x](migrate-version-1-version-4.md?pivots=programming-language-csharp), which supports .NET Framework 4.8, .NET 6, and .NET 8.|
18
18
19
19
> [!IMPORTANT]
20
20
> As of December 13, 2022, function apps running on versions 2.x and 3.x of the Azure Functions runtime have reached the end of extended support. For more information, see [Retired versions](#retired-versions).
@@ -131,7 +131,7 @@ In Visual Studio, you select the runtime version when you create a project. Azur
131
131
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
132
132
```
133
133
134
-
You can choose `net8.0`, `net6.0`, or `net48` as the target framework if you are using the [isolated worker model](dotnet-isolated-process-guide.md). If you are using the [in-process model](./functions-dotnet-class-library.md), you can only choose `net6.0`, and you must include the `Microsoft.NET.Sdk.Functions` extension set to at least `4.0.0`.
134
+
You can choose `net8.0`, `net6.0`, or `net48` as the target framework if you are using the [isolated worker model](dotnet-isolated-process-guide.md). If you are using the [in-process model](./functions-dotnet-class-library.md), you can choose `net8.0` or `net6.0`, and you must include the `Microsoft.NET.Sdk.Functions` extension set to at least `4.4.0`.
135
135
136
136
.NET 7 was previously supported on the isolated worker model but reached the end of official support on [May 14, 2024][dotnet-policy].
Copy file name to clipboardExpand all lines: articles/azure-functions/migrate-version-1-version-4.md
+14-10Lines changed: 14 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -86,7 +86,7 @@ On version 1.x of the Functions runtime, your C# function app targets .NET Frame
86
86
>
87
87
> Although you can choose to instead use the in-process model, this is not recommended if it can be avoided. [Support will end for the in-process model on November 10, 2026](https://aka.ms/azure-functions-retirements/in-process-model), so you'll need to move to the isolated worker model before then. Doing so while migrating to version 4.x will decrease the total effort required, and the isolated worker model will give your app [additional benefits](./dotnet-isolated-in-process-differences.md), including the ability to more easily target future versions of .NET. If you are moving to the isolated worker model, the [.NET Upgrade Assistant] can also handle many of the necessary code changes for you.
88
88
89
-
This guide doesn't present specific examples for .NET 6 on the isolated worker model. If you need to target that version, you can adapt the .NET 8 isolated worker model examples.
89
+
This guide doesn't present specific examples for .NET 6. If you need to target that version, you can adapt the .NET 8 examples.
90
90
91
91
::: zone-end
92
92
@@ -167,7 +167,7 @@ Use one of the following procedures to update this XML file to run in Functions
A program.cs file isn't required when running in-process.
254
254
@@ -272,7 +272,7 @@ The `host.json` file only controls logging from the Functions host runtime, and
272
272
273
273
The `host.json` file only controls logging from the Functions host runtime, and in the isolated worker model, some of these logs come from your application directly, giving you more control. See [Managing log levels in the isolated worker model](./dotnet-isolated-process-guide.md#managing-log-levels) for details on how to filter these logs.
@@ -300,18 +300,22 @@ When you migrate to version 4.x, make sure that your local.settings.json file ha
300
300
> [!NOTE]
301
301
> When migrating from running in-process to running in an isolated worker process, you need to change the `FUNCTIONS_WORKER_RUNTIME` value to "dotnet-isolated".
> When choosing to target .NET 8 using the in-process model, you need to set the `FUNCTIONS_WORKER_RUNTIME` value to "dotnet" and set the `FUNCTIONS_INPROC_NET8_ENABLED` value to "1".
318
+
315
319
---
316
320
317
321
### Class name changes
@@ -337,7 +341,7 @@ Some key classes changed names between version 1.x and version 4.x. These change
337
341
|`HttpRequestMessage`|`HttpRequestData`|
338
342
|`HttpResponseMessage`|`HttpResponseData`|
339
343
340
-
# [.NET 6 (in-process model)](#tab/net6-in-proc)
344
+
# [.NET 8 (in-process model)](#tab/net8-in-proc)
341
345
342
346
| Version 1.x | .NET 6 (in-process) |
343
347
| --- | --- |
@@ -360,7 +364,7 @@ This section highlights other code changes to consider as you work through the m
Make sure to check [Behavior changes after version 1.x](#behavior-changes-after-version-1x) for additional changes you might need to make to your project.
0 commit comments