Skip to content

Commit 6922684

Browse files
adding migration guide to isolated
1 parent 52f339d commit 6922684

9 files changed

+254
-18
lines changed

articles/azure-functions/TOC.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -541,6 +541,8 @@
541541
href: legacy-proxies.md
542542
- name: Migrate
543543
items:
544+
- name: Migrate .NET apps to the isolated model
545+
href: migrate-dotnet-to-isolated-model.md
544546
- name: Migrate v3.x to v4.x
545547
href: migrate-version-3-version-4.md
546548
- name: Migrate v1.x to v4.x

articles/azure-functions/dotnet-isolated-in-process-differences.md

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ description: Compares features and functionality differences between running .NE
44
ms.service: azure-functions
55
ms.custom: devx-track-dotnet
66
ms.topic: conceptual
7-
ms.date: 11/07/2022
7+
ms.date: 08/03/2023
88
recommendations: false
99
#Customer intent: As a developer, I need to understand the differences between running in-process and running in an isolated worker process so that I can choose the best process model for my functions.
1010
---
@@ -15,7 +15,7 @@ There are two process models for .NET functions:
1515

1616
[!INCLUDE [functions-dotnet-execution-model](../../includes/functions-dotnet-execution-model.md)]
1717

18-
This article describes the current state of the functional and behavioral differences between the two models.
18+
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][migrate].
1919

2020
## Execution mode comparison table
2121

@@ -56,10 +56,13 @@ Use the following table to compare feature and functional differences between th
5656

5757
## Next steps
5858

59-
To learn more, see:
59+
> [!div class="nextstepaction"]
60+
> [Learn more about the isolated worker model](./dotnet-isolated-process-guide.md)
6061
61-
+ [Develop .NET class library functions](functions-dotnet-class-library.md)
62-
+ [Develop .NET isolated worker process functions](dotnet-isolated-process-guide.md)
62+
> [!div class="nextstepaction"]
63+
> [Migrate to the isolated worker model][migrate]
64+
65+
[migrate]: ./migrate-dotnet-to-isolated-model.md
6366

6467
[ILogger]: /dotnet/api/microsoft.extensions.logging.ilogger
6568
[ILogger<T>]: /dotnet/api/microsoft.extensions.logging.logger-1

articles/azure-functions/dotnet-isolated-process-guide.md

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,8 @@ If you still need to run your functions in the same process as the host, see [In
2323

2424
For a comprehensive comparison between isolated worker process and in-process .NET Functions, see [Differences between in-process and isolate worker process .NET Azure Functions](dotnet-isolated-in-process-differences.md).
2525

26+
To learn about migration from the in-process model to the isolated worker model, see [Migrate .NET apps from the in-process model to the isolated worker model][migrate].
27+
2628
## Why .NET Functions isolated worker process?
2729

2830
When it was introduced, Azure Functions only supported a tightly integrated mode for .NET functions. In this _in-process_ mode, your [.NET class library functions](functions-dotnet-class-library.md) run in the same process as the host. This mode provides deep integration between the host process and the functions. For example, when running in the same process .NET class library functions can share binding APIs and types. However, this integration also requires a tight coupling between the host process and the .NET function. For example, .NET functions running in-process are required to run on the same version of .NET as the Functions runtime. This means that your in-process functions can only run on version of .NET with Long Term Support (LTS). To enable you to run on non-LTS version of .NET, you can instead choose to run in an isolated worker process. This process isolation lets you develop functions that use current .NET releases not natively supported by the Functions runtime, including .NET Framework. Both isolated worker process and in-process C# class library functions run on LTS versions. To learn more, see [Supported versions][supported-versions].
@@ -478,9 +480,13 @@ Because your isolated worker process app runs outside the Functions runtime, you
478480

479481
## Next steps
480482

481-
+ [Learn more about triggers and bindings](functions-triggers-bindings.md)
482-
+ [Learn more about best practices for Azure Functions](functions-best-practices.md)
483+
> [!div class="nextstepaction"]
484+
> [Learn more about best practices for Azure Functions](functions-best-practices.md)
485+
486+
> [!div class="nextstepaction"]
487+
> [Migrate .NET apps to the isolated worker model][migrate]
483488
489+
[migrate]: ./migrate-dotnet-to-isolated-model.md
484490

485491
[supported-versions]: #supported-versions
486492

Lines changed: 226 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,226 @@
1+
---
2+
title: Migrate .NET function apps from the in-process model to the isolated worker model
3+
description: This article shows you how to upgrade your existing .NET function apps running on the in-process model to the isolated worker model.
4+
ms.service: azure-functions
5+
ms.custom: devx-track-dotnet
6+
ms.topic: how-to
7+
ms.date: 08/2/2023
8+
---
9+
10+
# Migrate .NET apps from the in-process model to the isolated worker model
11+
12+
This article walks you through the process of safely migrating your .NET function app from the [in-process model](./functions-dotnet-class-library.md) to the [isolated worker model][isolated-guide]. To learn about the high-level differences between these models, see the [execution mode comparison](./dotnet-isolated-in-process-differences.md).
13+
14+
This guide assumes that your app is running on version 4.x of the Functions runtime. If not, you should instead follow the guides for upgrading your host version:
15+
16+
- [Migrate apps from Azure Functions version 2.x and 3.x to version 4.x](./migrate-version-3-version-4.md)
17+
- [Migrate apps from Azure Functions version 1.x to version 4.x](./migrate-version-1-version-4.md)
18+
19+
These host version migration guides will also help you migrate to the isolated worker model as you work through them.
20+
21+
## Identify function apps to upgrade
22+
23+
Use the following PowerShell script to generate a list of function apps in your subscription that currently use the in-process model:
24+
25+
```powershell
26+
$Subscription = '<YOUR SUBSCRIPTION ID>'
27+
28+
Set-AzContext -Subscription $Subscription | Out-Null
29+
30+
$FunctionApps = Get-AzFunctionApp
31+
32+
$AppInfo = @{}
33+
34+
foreach ($App in $FunctionApps)
35+
{
36+
if ($App.ApplicationSettings["FUNCTIONS_WORKER_RUNTIME"] -eq 'dotnet')
37+
{
38+
$AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_WORKER_RUNTIME"])
39+
}
40+
}
41+
42+
$AppInfo
43+
```
44+
45+
## Choose your target .NET version
46+
47+
On version 4.x of the Functions runtime, your .NET function app targets .NET 6 when using the in-process model.
48+
49+
[!INCLUDE [functions-dotnet-migrate-v4-versions](../../includes/functions-dotnet-migrate-v4-versions.md)]
50+
51+
> [!TIP]
52+
> **We recommend upgrading to .NET 6 on the isolated worker model.** This provides a quick upgrade path with the longest support window from .NET.
53+
54+
## Prepare for migration
55+
56+
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).
57+
58+
Before you upgrade an app to the isolated worker model, you should thoroughly review the contents of this guide and familiarize yourself with the features of the [isolated worker model][isolated-guide].
59+
60+
To upgrade the application, you will:
61+
62+
1. Complete the steps in [Upgrade your local project](#upgrade-your-local-project) to migrate your local project to the isolated worker model.
63+
1. After migrating your project, fully test the app locally using version 4.x of the [Azure Functions Core Tools](functions-run-local.md).
64+
1. [Upgrade your function app in Azure](#upgrade-your-function-app-in-azure) to the isolated model.
65+
66+
## Upgrade your local project
67+
68+
The section outlines the various changes that you need to make to your local project to move it to the isolated worker model. Some of the steps change based on your target version of .NET. Use the tabs to select the instructions which match your desired version.
69+
70+
> [!TIP]
71+
> The [.NET Upgrade Assistant] can be used to automatically make many of the changes mentioned in the following sections.
72+
73+
### .csproj file
74+
75+
The following example is a .csproj project file that uses .NET 6 on version 4.x:
76+
77+
```xml
78+
<Project Sdk="Microsoft.NET.Sdk">
79+
<PropertyGroup>
80+
<TargetFramework>net6.0</TargetFramework>
81+
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
82+
<RootNamespace>My.Namespace</RootNamespace>
83+
</PropertyGroup>
84+
<ItemGroup>
85+
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
86+
</ItemGroup>
87+
<ItemGroup>
88+
<None Update="host.json">
89+
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
90+
</None>
91+
<None Update="local.settings.json">
92+
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
93+
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
94+
</None>
95+
</ItemGroup>
96+
</Project>
97+
```
98+
99+
Use one of the following procedures to update this XML file to run in the isolated worker model:
100+
101+
# [.NET 6 (isolated)](#tab/net6-isolated)
102+
103+
[!INCLUDE [functions-dotnet-migrate-project-v4-isolated](../../includes/functions-dotnet-migrate-project-v4-isolated.md)]
104+
105+
# [.NET 7](#tab/net7)
106+
107+
[!INCLUDE [functions-dotnet-migrate-project-v4-isolated-2](../../includes/functions-dotnet-migrate-project-v4-isolated-2.md)]
108+
109+
# [.NET Framework 4.8](#tab/v4)
110+
111+
[!INCLUDE [functions-dotnet-migrate-project-v4-isolated-net-framework](../../includes/functions-dotnet-migrate-project-v4-isolated-net-framework.md)]
112+
113+
---
114+
115+
### Package and namespace changes
116+
117+
When migrating to the isolated worker model, you need to change the packages your application references. Then you 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) section later in this article.
118+
119+
[!INCLUDE [functions-dotnet-migrate-packages-v4-isolated](../../includes/functions-dotnet-migrate-packages-v4-isolated.md)]
120+
121+
### Program.cs file
122+
123+
When migrating to run in an isolated worker process, you must add the following program.cs file to your project:
124+
125+
# [.NET 6 (isolated)](#tab/net6-isolated)
126+
127+
:::code language="csharp" source="~/functions-quickstart-templates/Functions.Templates/ProjectTemplate_v4.x/CSharp-Isolated/Program.cs" range="23-29":::
128+
129+
# [.NET 7](#tab/net7)
130+
131+
:::code language="csharp" source="~/functions-quickstart-templates/Functions.Templates/ProjectTemplate_v4.x/CSharp-Isolated/Program.cs" range="23-29":::
132+
133+
# [.NET Framework 4.8](#tab/v4)
134+
135+
:::code language="csharp" source="~/functions-quickstart-templates/Functions.Templates/ProjectTemplate_v4.x/CSharp-Isolated/Program.cs" range="2-20":::
136+
137+
---
138+
139+
### local.settings.json file
140+
141+
The local.settings.json file is only used when running locally. For information, see [Local settings file](functions-develop-local.md#local-settings-file).
142+
143+
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". Make sure that your local.settings.json file has at least the following elements:
144+
145+
:::code language="json" source="~/functions-quickstart-templates/Functions.Templates/ProjectTemplate_v4.x/CSharp-Isolated/local.settings.json":::
146+
147+
### Class name changes
148+
149+
Some key classes change between the in-process model and the isolated worker model. The following table indicates key .NET classes used by Functions that change when migrating:
150+
151+
| In-process model | Isolated worker model|
152+
| --- | --- | --- |
153+
| `FunctionName` (attribute) | `Function` (attribute) |
154+
| `ILogger` | `ILogger`, `ILogger<T>` |
155+
| `HttpRequest` | `HttpRequestData`, `HttpRequest` (using [ASP.NET Core integration])|
156+
| `IActionResult` | `HttpResponseData`, `IActionResult` (using [ASP.NET Core integration])|
157+
| `FunctionsStartup` (attribute) | Uses [`Program.cs`](#programcs-file) instead |
158+
159+
[ASP.NET Core integration]: ./dotnet-isolated-process-guide.md#aspnet-core-integration-preview
160+
161+
There might also be class name differences in bindings. For more information, see the reference articles for the specific bindings.
162+
163+
### HTTP trigger template
164+
165+
The differences between in-process and isolated worker process can be seen in HTTP triggered functions. The HTTP trigger template for the in-process model looks like the following example:
166+
167+
:::code language="csharp" source="~/functions-quickstart-templates/Functions.Templates/Templates/HttpTrigger-CSharp/HttpTriggerCSharp.cs":::
168+
169+
The HTTP trigger template for the migrated version looks like the following example:
170+
171+
# [.NET 6 (isolated)](#tab/net6-isolated)
172+
173+
:::code language="csharp" source="~/functions-quickstart-templates/Functions.Templates/Templates/HttpTrigger-CSharp-Isolated/HttpTriggerCSharp.cs":::
174+
175+
You can also leverage [ASP.NET Core integration] to instead have the function look more like the following example:
176+
177+
```csharp
178+
[Function("HttpFunction")]
179+
public IActionResult Run(
180+
[HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req)
181+
{
182+
return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
183+
}
184+
```
185+
186+
# [.NET 7](#tab/net7)
187+
188+
:::code language="csharp" source="~/functions-quickstart-templates/Functions.Templates/Templates/HttpTrigger-CSharp-Isolated/HttpTriggerCSharp.cs":::
189+
190+
You can also leverage [ASP.NET Core integration] to instead have the function look more like the following example:
191+
192+
```csharp
193+
[Function("HttpFunction")]
194+
public IActionResult Run(
195+
[HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req)
196+
{
197+
return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
198+
}
199+
```
200+
201+
# [.NET Framework 4.8](#tab/v4)
202+
203+
:::code language="csharp" source="~/functions-quickstart-templates/Functions.Templates/Templates/HttpTrigger-CSharp-Isolated/HttpTriggerCSharp.cs":::
204+
205+
---
206+
207+
## Upgrade your function app in Azure
208+
209+
Upgrading your function app to the isolated model consists of two steps:
210+
211+
1. Change the configuration of the function app to use the isolated model by setting the `FUNCTIONS_WORKER_RUNTIME` application setting to "dotnet-isolated". Make sure that any deployment automation is similarly updated.
212+
2. Publish your upgraded project to the upgraded function app.
213+
214+
When you use Visual Studio to publish an isolated worker model project to an existing function app that uses the in-process model, you're prompted to let Visual Studio upgrade the function app during deployment. This accomplishes both steps at once.
215+
216+
If you need to minimize downtime, consider using a [staging slot](functions-deployment-slots.md) to test and verify your upgraded code with your upgraded configuration in Azure. You can then deploy your upgraded app to the production slot through a swap operation.
217+
218+
Once you've completed these steps, your app has been fully migrated to the isolated model. Congratulations! Repeat the steps from this guide as necessary for [any other apps needing migration](#identify-function-apps-to-upgrade).
219+
220+
## Next steps
221+
222+
> [!div class="nextstepaction"]
223+
> [Learn more about the isolated worker model][isolated-guide]
224+
225+
[isolated-guide]: ./dotnet-isolated-process-guide.md
226+
[.NET Upgrade Assistant]: /dotnet/core/porting/upgrade-assistant-overview

includes/functions-dotnet-migrate-project-v4-inproc.md

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -8,9 +8,9 @@ ms.author: glenga
88

99
The following changes are required in the .csproj XML project file:
1010

11-
1. Change the value of `PropertyGroup`.`TargetFramework` to `net6.0`.
11+
1. Set the value of `PropertyGroup`.`TargetFramework` to `net6.0`.
1212

13-
1. Change the value of `PropertyGroup`.`AzureFunctionsVersion` to `v4`.
13+
1. Set the value of `PropertyGroup`.`AzureFunctionsVersion` to `v4`.
1414

1515
1. Replace the existing `ItemGroup`.`PackageReference` list with the following `ItemGroup`:
1616

@@ -19,7 +19,6 @@ The following changes are required in the .csproj XML project file:
1919
After you make these changes, your updated project should look like the following example:
2020

2121
```xml
22-
2322
<Project Sdk="Microsoft.NET.Sdk">
2423
<PropertyGroup>
2524
<TargetFramework>net6.0</TargetFramework>

includes/functions-dotnet-migrate-project-v4-isolated-2.md

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -7,9 +7,9 @@ ms.author: glenga
77
---
88
The following changes are required in the .csproj XML project file:
99

10-
1. Change the value of `PropertyGroup`.`TargetFramework` to `net7.0`.
10+
1. Set the value of `PropertyGroup`.`TargetFramework` to `net7.0`.
1111

12-
1. Change the value of `PropertyGroup`.`AzureFunctionsVersion` to `v4`.
12+
1. Set the value of `PropertyGroup`.`AzureFunctionsVersion` to `v4`.
1313

1414
1. Add the following `OutputType` element to the `PropertyGroup`:
1515

@@ -26,7 +26,6 @@ The following changes are required in the .csproj XML project file:
2626
After you make these changes, your updated project should look like the following example:
2727

2828
```xml
29-
3029
<Project Sdk="Microsoft.NET.Sdk">
3130
<PropertyGroup>
3231
<TargetFramework>net7.0</TargetFramework>

includes/functions-dotnet-migrate-project-v4-isolated-net-framework.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,9 @@ ms.author: mahender
77
---
88
The following changes are required in the .csproj XML project file:
99

10-
1. Change the value of `PropertyGroup`.`AzureFunctionsVersion` to `v4`.
10+
1. Set the value of `PropertyGroup`.`TargetFramework` to `net48`.
11+
12+
1. Set the value of `PropertyGroup`.`AzureFunctionsVersion` to `v4`.
1113

1214
1. Add the following `OutputType` element to the `PropertyGroup`:
1315

includes/functions-dotnet-migrate-project-v4-isolated.md

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -7,9 +7,9 @@ ms.author: glenga
77
---
88
The following changes are required in the .csproj XML project file:
99

10-
1. Change the value of `PropertyGroup`.`TargetFramework` to `net6.0`.
10+
1. Set the value of `PropertyGroup`.`TargetFramework` to `net6.0`.
1111

12-
1. Change the value of `PropertyGroup`.`AzureFunctionsVersion` to `v4`.
12+
1. Set the value of `PropertyGroup`.`AzureFunctionsVersion` to `v4`.
1313

1414
1. Add the following `OutputType` element to the `PropertyGroup`:
1515

@@ -26,7 +26,6 @@ The following changes are required in the .csproj XML project file:
2626
After you make these changes, your updated project should look like the following example:
2727

2828
```xml
29-
3029
<Project Sdk="Microsoft.NET.Sdk">
3130
<PropertyGroup>
3231
<TargetFramework>net6.0</TargetFramework>

includes/functions-dotnet-migrate-v4-versions.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ ms.date: 07/28/2023
66
ms.author: mahender
77
---
88

9-
When you migrate your function app to version 4.x, you have the opportunity to choose the target version of .NET. You can upgrade your C# project to one of the following versions of .NET, all of which can run on Functions version 4.x:
9+
When you migrate your function app, you have the opportunity to choose the target version of .NET. You can upgrade your C# project to one of the following versions of .NET that are supported by Functions version 4.x:
1010

1111
| .NET version | [.NET Official Support Policy] release type | Functions process model<sup>1</sup> |
1212
| --- | --- | --- |

0 commit comments

Comments
 (0)