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
The `functionTimeout` property in the [host.json](functions-host-json.md#functiontimeout) project file sets the timeout duration for functions in a function app. This property applies specifically to function executions. After the trigger starts function execution, the function needs to return or respond within the timeout duration. When an execution exceeds this duration, a timeout error occurs and the language worker process restarts. For C# apps running in-process, the host process itself restarts. To avoid timeouts and subsequent process restarts, it's important to [write robust functions](functions-best-practices.md#write-robust-functions). For more information, see [Improve Azure Functions performance and reliability](performance-reliability.md#make-sure-background-tasks-complete).
70
+
71
+
The following table shows the default and maximum values (in minutes) for specific plans:
1. Regardless of the function app timeout setting, 230 seconds is the maximum amount of time that an HTTP triggered function can take to respond to a request. This limit exists because of the [default idle timeout of Azure Load Balancer](../app-service/faq-availability-performance-application-issues.yml#why-does-my-request-time-out-after-230-seconds). For longer processing times, consider using the [Durable Functions async pattern](durable-functions/durable-functions-http-features.md#async-operation-tracking) or [defer the actual work and return an immediate response](performance-reliability.md#avoid-long-running-functions).
82
+
2. There's no maximum execution timeout duration enforced. However, the grace period given to a function execution is 60 minutes [during scale in](event-driven-scaling.md#scale-in-behaviors) for the Flex Consumption and Premium plans, and a grace period of 10 minutes is given during platform updates.
83
+
3. Requires the App Service plan be set to [Always On](/azure/azure-functions/dedicated-plan#always-on). A grace period of 10 minutes is given during platform updates.
84
+
4. The default timeout for version 1.x of the Functions host runtime is _unbounded_.
85
+
5. When the [minimum number of replicas](../container-apps/scale-app.md#scale-definition) is set to zero, the default timeout depends on the specific triggers used in the app.
86
+
87
+
These values assume that the Azure Functions host process starts and runs correctly. There's a maximum timeout of 60 seconds for the language-specific worker process to also start. The worker process startup timeout isn't currently configurable.
description: Learn how Azure Functions supports multiple versions of the runtime, and understand the differences between them and how to choose the one that's right for you.
<aname="top"></a>Azure Functions currently supports two versions of the runtime host. The following table details the currently supported runtime versions, their support level, and when they should be used:
12
+
::: zone pivot="programming-language-csharp"
13
+
Azure Functions currently supports two versions of the runtime host. The following table details the currently supported runtime versions, their support level, and when to use them:
13
14
14
15
| Version | Support level | Description |
15
16
| --- | --- | --- |
16
17
| 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 8, .NET 9, and .NET 10 Preview.|
18
+
| 1.x | GA<sup>*</sup>| Supported only for C# apps that must use .NET Framework. This version is in maintenance mode, with enhancements provided only in later versions. **Support ends for version 1.x on September 14, 2026.**[Migrate your apps to version 4.x](migrate-version-1-version-4.md?pivots=programming-language-csharp). For more information, see [supported language versions](#languages). |
18
19
20
+
<sup>*</sup> Support ends September 14, 2026. For more information, see [the version 1.x support announcement](https://aka.ms/azure-functions-retirements/hostv1).
21
+
::: zone-end
22
+
::: zone pivot="programming-language-java,programming-language-javascript,programming-language-typescript,programming-language-powershell,programming-language-python"
23
+
Azure Functions currently supports only version 4.x of the runtime host.
24
+
25
+
::: zone-end
19
26
> [!IMPORTANT]
20
27
> Versions 2.x and 3.x of the Azure Functions runtime are no longer supported. For more information, see [Retired versions](#retired-versions).
21
28
22
-
This article details some of the differences between supported versions, how you can create each version, and how to change the version on which your functions run.
29
+
[Migrate apps from Azure Functions version 3.x to version 4.x](migrate-version-3-version-4.md).
All functions in a function app must share the same language. You choose the language of functions in your function app when you create the app. The language of your function app is maintained in the [FUNCTIONS\_WORKER\_RUNTIME](functions-app-settings.md#functions_worker_runtime) setting, and can't be changed when there are existing functions.
37
+
All functions in a function app must share the same language. Choose the language of functions in your function app when you create the app. The language of your function app is maintained in the [FUNCTIONS\_WORKER\_RUNTIME](functions-app-settings.md#functions_worker_runtime) setting, and can't be changed when there are existing functions.
For information about the language versions of previously supported versions of the Functions runtime, see [Retired runtime versions](language-support-policy.md#language-support-related-resources).
41
+
For information about language versions of previously supported Functions runtime versions, see [Retired runtime versions](language-support-policy.md#language-support-related-resources).
35
42
36
43
## <aname="creating-1x-apps"></a>Run on a specific version
37
44
38
-
The version of the Functions runtime used by published apps in Azure is dictated by the [`FUNCTIONS_EXTENSION_VERSION`](functions-app-settings.md#functions_extension_version) application setting. In some cases and for certain languages, other settings can apply.
45
+
The [`FUNCTIONS_EXTENSION_VERSION`](functions-app-settings.md#functions_extension_version) application setting determines the version of the Functions runtime that published apps use in Azure. In some cases and for certain languages, other settings might apply.
39
46
40
-
By default, function apps created in the Azure portal, by the Azure CLI, or from Visual Studio tools are set to version 4.x. You can modify this version if needed. You can only downgrade the runtime version to 1.x after you create your function app but before you add any functions. Updating to a later major version is allowed even with apps that have existing functions.
47
+
By default, function apps created in the Azure portal, by the Azure CLI, or from Visual Studio tools are set to version 4.x. You can modify this version if needed. You can only downgrade the runtime version to 1.x after you create your function app but before you add any functions. You can update to a later major version even with apps that have existing functions.
The following major runtime version values are used:
@@ -54,6 +61,7 @@ The following major runtime version values are used:
54
61
55
62
>[!IMPORTANT]
56
63
> Don't arbitrarily change this app setting, because other app setting changes and changes to your function code might be required. For existing function apps, follow the [migration instructions](#migrate-existing-function-apps).
64
+
::: zone-end
57
65
58
66
### Pin to a specific minor version
59
67
@@ -66,9 +74,9 @@ Older minor versions are periodically removed from Functions. For the latest new
66
74
::: zone pivot="programming-language-csharp"
67
75
There's technically not a correlation between binding extension versions and the Functions runtime version. However, starting with version 4.x, the Functions runtime enforces a minimum version for all trigger and binding extensions.
68
76
69
-
If you receive a warning about a package not meeting a minimum required version, you should update that NuGet package to the minimum version as you normally would. The minimum version requirements for extensions used in Functions v4.x can be found in [the linked configuration file](https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script/extensionrequirements.json).
77
+
If you receive a warning about a package not meeting a minimum required version, you should update that NuGet package to the minimum version as you normally would. Find the minimum version requirements for extensions used in Functions v4.x in [the linked configuration file](https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script/extensionrequirements.json).
70
78
71
-
For C# script, update the extension bundle reference in the *host.json* as follows:
79
+
For C# script, update the extension bundle reference in the *host.json*:
72
80
73
81
```json
74
82
{
@@ -82,7 +90,7 @@ For C# script, update the extension bundle reference in the *host.json* as follo
82
90
83
91
::: zone-end
84
92
::: zone pivot="programming-language-java,programming-language-javascript,programming-language-typescript,programming-language-powershell,programming-language-python"
85
-
There's technically not a correlation between extension bundle versions and the Functions runtime version. However, starting with version 4.x the Functions runtime enforces a minimum version for extension bundles.
93
+
There's technically not a correlation between extension bundle versions and the Functions runtime version. However, starting with version 4.x, the Functions runtime enforces a minimum version for extension bundles.
86
94
87
95
If you receive a warning about your extension bundle version not meeting a minimum required version, update your existing extension bundle reference in the *host.json* as follows:
88
96
@@ -103,28 +111,28 @@ To learn more about extension bundles, see [Extension bundles](extension-bundles
These versions of the Functions runtime reached the end of extended support on December 13, 2022.
114
+
These versions of the Functions runtime reached end of extended support on December 13, 2022.
107
115
108
116
| Version | Current support level | Previous support level |
109
117
| --- | --- | --- |
110
118
| 3.x | Out of support | GA |
111
119
| 2.x | Out of support | GA |
112
120
113
-
As soon as possible, you should migrate your apps to version 4.x to obtain full support. For a complete set of language-specific migration instructions, see [Migrate apps to Azure Functions version 4.x](migrate-version-3-version-4.md).
114
-
115
-
Apps using versions 2.x and 3.x can still be created and deployed from your CI/CD DevOps pipeline, and all existing apps continue to run without breaking changes. However, your apps aren't eligible for new features, security patches, and performance optimizations. You can only get related service support after you upgrade your apps to version 4.x.
121
+
Migrate your apps to version 4.x as soon as possible to get full support. For a complete set of language-specific migration instructions, see [Migrate apps to Azure Functions version 4.x](migrate-version-3-version-4.md).
116
122
117
-
Versions 2.x and 3.x are no longer supported due to the end of support for .NET Core 3.1, which was a core dependency. This requirement affects all [languages supported by Azure Functions](supported-languages.md).
123
+
Apps using versions 2.x and 3.x can still be created and deployed from your CI/CD DevOps pipeline, and all existing apps continue to run without breaking changes. But your apps aren't eligible for new features, security patches, and performance optimizations. You can only get related service support after you upgrade your apps to version 4.x.
118
124
125
+
Versions 2.x and 3.x are no longer supported because .NET Core 3.1, a core dependency, reached end of support. This requirement affects all [languages supported by Azure Functions](supported-languages.md).
126
+
::: zone pivot="programming-language-csharp"
119
127
## Locally developed application versions
120
128
121
-
You can make the following updates to function apps to locally change the targeted versions.
129
+
Make the following updates to function apps to locally change the targeted versions.
122
130
123
131
### Visual Studio runtime versions
124
132
125
133
In Visual Studio, you select the runtime version when you create a project. Azure Functions tools for Visual Studio supports the two major runtime versions. The correct version is used when debugging and publishing based on project settings. The version settings are defined in the *.csproj* file in the following properties:
126
134
127
-
# [Version 4.x](#tab/v4)
135
+
####[Version 4.x](#tab/v4)
128
136
129
137
```xml
130
138
<TargetFramework>net8.0</TargetFramework>
@@ -134,11 +142,12 @@ In Visual Studio, you select the runtime version when you create a project. Azur
134
142
If you're using the [isolated worker model](dotnet-isolated-process-guide.md), you can choose, `net9.0`, `net8.0`, or `net48` as the target framework. You can also choose to use [preview support](./dotnet-isolated-process-guide.md#preview-net-versions) for `net10.0`. If you're 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`. .NET 10 isn't supported by the in-process model; if you are on the in-process model and wish to use .NET 10, [migrate your app to the isolated worker model](./migrate-dotnet-to-isolated-model.md).
135
143
136
144
.NET 6 was previously supported on the isolated worker model and the in-process model, but it reached the end of official support on [November 12, 2024][dotnet-policy].
145
+
137
146
.NET 7 was previously supported on the isolated worker model but reached the end of official support on [May 14, 2024][dotnet-policy].
@@ -151,22 +160,7 @@ If you're using the [isolated worker model](dotnet-isolated-process-guide.md), y
151
160
[Azure Functions Core Tools](functions-run-local.md) is used for command-line development and also by the [Azure Functions extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurefunctions) for Visual Studio Code. For more information, see [Install the Azure Functions Core Tools](functions-run-local.md#install-the-azure-functions-core-tools).
152
161
153
162
For Visual Studio Code development, you might also need to update the user setting for the `azureFunctions.projectRuntime` to match the version of the tools installed. This setting also updates the templates and languages used during function app creation.
154
-
155
-
## Bindings
156
-
157
-
Starting with version 2.x, the runtime uses a new [binding extensibility model](https://github.com/Azure/azure-webjobs-sdk-extensions/wiki/Binding-Extensions-Overview) that offers these advantages:
158
-
159
-
* Support for non-Microsoft binding extensions.
160
-
161
-
* Decoupling of runtime and bindings. This change allows binding extensions to be versioned and released independently. You can, for example, opt to upgrade to a version of an extension that relies on a newer version of an underlying SDK.
162
-
163
-
* A lighter execution environment, where only the bindings in use are known and loaded by the runtime.
164
-
165
-
Except for HTTP and timer triggers, all bindings must be explicitly added to the function app project, or registered in the portal. For more information, see [Azure Functions binding expression patterns](./functions-bindings-expressions-patterns.md).
Copy file name to clipboardExpand all lines: articles/azure-functions/migrate-version-1-version-4.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -554,7 +554,7 @@ This section details changes made after version 1.x in both trigger and binding
554
554
555
555
Starting with version 2.x, you must install the extensions for specific triggers and bindings used by the functions in your app. The only exception for this HTTP and timer triggers, which don't require an extension. For more information, see [Register and install binding extensions](functions-bindings-register.md).
556
556
557
-
There are also a few changes in the *function.json* or attributes of the function between versions. For example, the Event Hubs `path` property is now `eventHubName`. See the [existing binding table](functions-versions.md#bindings) for links to documentation for each binding.
557
+
There are also a few changes in the *function.json* or attributes of the function between versions. For example, the Event Hubs `path` property is now `eventHubName`. See the [existing binding table](functions-triggers-bindings.md#supported-bindings) for links to documentation for each binding.
0 commit comments