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
@@ -23,6 +23,12 @@ Azure Functions version 4.x is highly backwards compatible to version 3.x. Most
23
23
24
24
This article walks you through the process of safely migrating your function app to run on version 4.x of the Functions runtime. Because project upgrade instructions are language dependent, make sure to choose your development language from the selector at the [top of the article](#top).
25
25
26
+
## Identify function apps to upgrade
27
+
28
+
Use the following PowerShell script to generate a list of function apps in your subscription that currently target versions 2.x or 3.x:
@@ -40,33 +46,22 @@ On version 3.x of the Functions runtime, your C# function app targets .NET Core
40
46
41
47
## Prepare for migration
42
48
43
-
Before you upgrade your app to version 4.x of the Functions runtime, you should do the following tasks:
49
+
If you haven't already, identify the list of apps that need to be migrated in your current Azure Subscription by using the [Azure PowerShell](#identify-function-apps-to-upgrade).
44
50
45
-
* Review the list of [breaking changes between 3.x and 4.x](#breaking-changes-between-3x-and-4x).
46
-
*[Run the pre-upgrade validator](#run-the-pre-upgrade-validator).
47
-
* Identify the list of v2&v3 Function Apps in your current Azure Subscription by using the [Azure PowerShell](#identify-function-apps-to-upgrade).
48
-
* When possible, [upgrade your local project environment to version 4.x](#upgrade-your-local-project). Fully test your app locally using version 4.x of the [Azure Functions Core Tools](functions-run-local.md).
49
-
* Upgrade your function app in Azure to the new version. If you need to minimize downtime, consider using a [staging slot](functions-deployment-slots.md) to test and verify your migrated app in Azure on the new runtime version. You can then deploy your app with the updated version settings to the production slot. For more information, see [Migrate using slots](#upgrade-using-slots).
50
-
* Republished your migrated project to the upgraded function app. When you use Visual Studio to publish a version 4.x project to an existing function app at a lower version, you're prompted to let Visual Studio upgrade the function app to version 4.x during deployment. This upgrade uses the same process defined in [Migrate without slots](#upgrade-without-slots).
51
+
Before you upgrade an app to version 4.x of the Functions runtime, you should do the following tasks:
51
52
52
-
## Run the pre-upgrade validator
53
+
1. Review the list of [breaking changes between 3.x and 4.x](#breaking-changes-between-3x-and-4x).
54
+
1. Complete the steps in [Upgrade your local project](#upgrade-your-local-project) to migrate your local project to version 4.x.
55
+
1. After migrating your project, fully test the app locally using version 4.x of the [Azure Functions Core Tools](functions-run-local.md).
56
+
1.[Run the pre-upgrade validator](#run-the-pre-upgrade-validator) on the app hosted in Azure, and resolve any identified issues.
57
+
1. Upgrade your function app in Azure to the new version. If you need to minimize downtime, consider using a [staging slot](functions-deployment-slots.md) to test and verify your migrated app in Azure on the new runtime version. You can then deploy your app with the updated version settings to the production slot. For more information, see [Migrate using slots](#upgrade-using-slots).
58
+
1. Publish your migrated project to the upgraded function app.
53
59
54
-
Azure Functions provides a pre-upgrade validator to help you identify potential issues when migrating your function app to 4.x. To run the pre-upgrade validator:
55
-
56
-
1. In the [Azure portal](https://portal.azure.com), navigate to your function app.
60
+
::: zone pivot="programming-language-csharp"
57
61
58
-
1. Open the **Diagnose and solve problems** page.
59
-
60
-
1. In **Function App Diagnostics**, start typing `Functions 4.x Pre-Upgrade Validator` and then choose it from the list.
62
+
When you use Visual Studio to publish a version 4.x project to an existing function app at a lower version, you're prompted to let Visual Studio upgrade the function app to version 4.x during deployment. This upgrade uses the same process defined in [Migrate without slots](#upgrade-without-slots).
61
63
62
-
1. After validation completes, review the recommendations and address any issues in your app. If you need to make changes to your app, make sure to validate the changes against version 4.x of the Functions runtime, either [locally using Azure Functions Core Tools v4](#upgrade-your-local-project) or by [using a staging slot](#upgrade-using-slots).
63
-
64
-
65
-
## Identify function apps to upgrade
66
-
67
-
Use the following PowerShell script to generate a list of function apps in your subscription that currently target versions 2.x or 3.x:
Based on the model you are migrating to, you may need to upgrade or change the packages your application references. When you adopt the target packages, you may then need to update the namespace of using statements and some types you reference. You can see the effect of these namespace changes on `using` statements in the [HTTP trigger template examples](#http-trigger-template) later in this article.
The local.settings.json file is only used when running locally. For information, see [Local settings file](functions-develop-local.md#local-settings-file). When migrating from running in-process to running in an isolated worker process, you need to change the `FUNCTIONS_WORKER_RUNTIME` value, as in the following example:
171
+
The local.settings.json file is only used when running locally. For information, see [Local settings file](functions-develop-local.md#local-settings-file).
172
+
173
+
When you upgrade to version 4.x, make sure that your local.settings.json file has at least the following elements:
> 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 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 migrating from running in-process to running in an isolated worker process, you need to change the `FUNCTIONS_WORKER_RUNTIME` value to "dotnet-isolated".
199
+
160
200
---
161
201
162
-
### Namespace changes
202
+
### Class name changes
163
203
164
-
C# functions that run in an isolated worker process uses libraries in a different namespace than those libraries used when running in-process. In-process libraries are generally in the namespace `Microsoft.Azure.WebJobs.*`. Isolated worker process function apps use libraries in the namespace `Microsoft.Azure.Functions.Worker.*`. You can see the effect of these namespace changes on `using` statements in the [HTTP trigger template examples](#http-trigger-template) that follow.
204
+
Some key classes changed names between versions. These changes are a result either of changes in .NET APIs or in differences between in-process and isolated worker process. The following table indicates key .NET classes used by Functions that could change when migrating:
165
205
166
-
### Class name changes
206
+
#[.NET 6 (isolated)](#tab/net6-isolated)
167
207
168
-
Some key classes change names as a result of differences between in-process and isolated worker process APIs.
@@ -240,6 +316,18 @@ To update your project to Azure Functions 4.x:
240
316
3. If you're using Python 3.6, move to one of the [supported versions](functions-reference-python.md#python-version).
241
317
::: zone-end
242
318
319
+
### Run the pre-upgrade validator
320
+
321
+
Azure Functions provides a pre-upgrade validator to help you identify potential issues when migrating your function app to 4.x. To run the pre-upgrade validator:
322
+
323
+
1. In the [Azure portal](https://portal.azure.com), navigate to your function app.
324
+
325
+
1. Open the **Diagnose and solve problems** page.
326
+
327
+
1. In **Function App Diagnostics**, start typing `Functions 4.x Pre-Upgrade Validator` and then choose it from the list.
328
+
329
+
1. After validation completes, review the recommendations and address any issues in your app. If you need to make changes to your app, make sure to validate the changes against version 4.x of the Functions runtime, either [locally using Azure Functions Core Tools v4](#upgrade-your-local-project) or by [using a staging slot](#upgrade-using-slots).
Update your project to reference the latest stable version of [Microsoft.NET.Sdk.Functions](https://www.nuget.org/packages/Microsoft.NET.Sdk.Functions).
10
+
11
+
Depending on the triggers and bindings your app uses, your app may need to reference an additional set of packages. See [Supported bindings](../articles/azure-functions/functions-triggers-bindings.md#supported-bindings) for a list of extensions to consider, and consult each extension's documentation for full installation instructions for the in-process process model. Be sure to install the latest stable version of any packages you are targeting.
12
+
13
+
> [!TIP]
14
+
> Your app may also depend on Azure SDK types, either as part of your triggers and bindings or as a standalone dependency. You should take this opportunity to upgrade these as well. The latest versions of the Functions extensions work with the latest versions of the [Azure SDK for .NET](/dotnet/azure/sdk/azure-sdk-for-dotnet), almost all of the packages for which are the form `Azure.*`.
Depending on the triggers and bindings your app uses, your app may need to reference an additional set of packages. See [Supported bindings](../articles/azure-functions/functions-triggers-bindings.md#supported-bindings) for a list of extensions to consider, and consult each extension's documentation for full installation instructions for the isolated process model. The packages for these extensions will all be under the [Microsoft.Azure.Functions.Worker.Extensions](https://www.nuget.org/packages?q=Microsoft.Azure.Functions.Worker.Extensions) prefix. Be sure to install the latest stable version of any packages you are targeting.
14
+
15
+
**Your application should not reference any packages in the `Microsoft.Azure.WebJobs.*` namespaces.** If you have any remaining references to these, they should be removed.
16
+
17
+
> [!TIP]
18
+
> Your app may also depend on Azure SDK types, either as part of your triggers and bindings or as a standalone dependency. You should take this opportunity to upgrade these as well. The latest versions of the Functions extensions work with the latest versions of the [Azure SDK for .NET](/dotnet/azure/sdk/azure-sdk-for-dotnet), almost all of the packages for which are the form `Azure.*`.
0 commit comments