共用方式為


將 C# 應用程式從內部進程模型遷移至獨立工作者模型

重要

進程內模型的支援將於 2026 年 11 月 10 日結束。 強烈建議您參考本文中的指示,將您的應用程式遷移至隔離工作者模型。

本文將引導您安全地將 .NET 函數應用程式從進程內模型遷移到隔離工作者模型。 若要了解這些模型之間的高階差異,請參閱執行模式比較

本指南假設您的應用程式是在 Functions 執行階段 4.x 版上執行。 如果沒有,您應該使用下列指南來升級主機版本。 這些主機版本移轉指南也會協助您在處理隔離背景工作角色模型時,移轉至隔離的背景工作角色模型。

在支援的情況下,本文會利用隔離式背景工作角色模型中的 ASP.NET Core 整合,這可以提高效能並在應用程式使用 HTTP 觸發程序時提供熟悉的程式設計模型。

識別要移轉的函數應用程式

使用下列 Azure PowerShell 指令碼,以在您的訂用帳戶中產生目前使用內含式模型的函數應用程式清單。

腳本會使用 Azure PowerShell 目前設定為使用的訂用帳戶。 您可以先執行 Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>',並以您想要評估的訂用帳戶識別碼取代 <YOUR SUBSCRIPTION ID>,以變更訂用帳戶。

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.Runtime -eq 'dotnet')
     {
          $AppInfo.Add($App.Name, $App.Runtime)
     }
}

$AppInfo

選擇您的目標 .NET 版本

在 Functions 執行時間 4.x 版上,當您使用進程內模型時,.NET 函式應用程式會以 .NET 6 或 .NET 8 為目標。

當移轉函數應用程式時,您有機會選擇 .NET 的目標版本。 您可以將 C# 專案更新為下列其中一個 Functions 4.x 版可支援的 .NET 版本:

.NET 版本 .NET 官方支援原則版本類型 Functions 處理序模型1、2
.NET 9 STS (終止支援 2026 年 5 月 12 日) 隔離式背景工作角色模型
.NET 8 LTS (2026 年 11 月 10 日終止支援) 隔離式工作者模型
進程模型2
.NET Framework 4.8 請參閱原則 隔離式背景工作角色模型

1 隔離式背景工作角色模型支援 .NET 的長期支援 (LTS) 和標準期限支援 (STS) 版本,以及 .NET Framework。 同處理序模型僅支援 .NET 的 LTS 版本,結尾為 .NET 8。 如需兩個模型之間的完整特性和功能比較,請參閱內部工作程序和隔離工作程序 .NET Azure Functions 之間的差異

2 內含式模型的支援會於 2026 年 11 月 10 日結束。 如需詳細資訊,請參閱此支援公告。 如需持續獲得完整支援,您應將應用程式移轉至隔離式工作者模型。

秘訣

建議您在隔離的工作者模型上升級至 .NET 8。 這提供了快速升級到 .NET 所提供的支援時間範圍最長的完整發行版本的途徑。

本指南未提供 .NET 9 的特定範例。 如果您需要以該版本為目標,可以調整 .NET 8 範例。

為移轉做準備

在將應用程式移轉至隔離工作模型之前,您應該徹底檢閱本指南的內容。 您也應該自行熟悉隔離工作者模型的功能,以及兩者模型之間的差異

若要移轉應用程式:

  1. 遵循移轉本機專案中的步驟,將本機專案移轉至隔離的背景工作模型。
  2. 移轉專案之後,請使用 4.x 版的 Azure Functions Core Tools,在本機完整測試應用程式。
  3. 將 Azure 中的函數應用程式更新到隔離模型

移轉本機專案

本節概述您需要對本機專案進行的各種變更,以將其移至隔離的背景工作角色模型。 某些步驟會根據您的目標 .NET 版本而變更。 使用索引標籤來選取符合所需版本的指示。

秘訣

如果您要移至 .NET 的 LTS 或 STS 版本,可以使用 .NET 升級小幫手 來自動進行下列各節所述的許多變更。

首先,轉換專案檔並更新相依性。 如您所做,您會發現專案的建置錯誤。 在後續步驟中,您將進行對應的變更,以移除這些錯誤。

專案檔

下列範例是 .csproj 項目檔,在 4.x 版上使用 .NET 8:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

使用下列其中一個方法來更新此 XML 檔案,以在隔離工作者模型中執行:

這些步驟假設本機 C# 專案;如果您的應用程式改用 C# 腳稿 (.csx 檔案),您應該 先轉換成專案模型 ,然後再繼續。

.csproj XML 項目檔中需要下列變更:

  1. 設定 PropertyGroup 的值。TargetFrameworknet8.0

  2. 設定 PropertyGroup 的值。AzureFunctionsVersionv4

  3. 將下列 OutputType 元素新增至 PropertyGroup

    <OutputType>Exe</OutputType>
    
  4. ItemGroup 中。在 PackageReference 清單中,將 Microsoft.NET.Sdk.Functions 的套件參考取代為下列參考:

      <FrameworkReference Include="Microsoft.AspNetCore.App" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
      <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    

    記下 Microsoft.Azure.WebJobs.* 命名空間中其他套件的任何參考。 您將在稍後的步驟中替換這些套件。

  5. 新增下列新的 ItemGroup

    <ItemGroup>
      <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
    </ItemGroup>
    

進行這些變更之後,更新的專案看起來應該像下列範例:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    <!-- Other packages may also be in this list -->
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

在專案程式碼之外,變更專案的目標架構可能需要變更工具鏈的元件。 例如,在 VS Code 中,您可能需要透過使用者設定或專案的 .vscode/settings.json 檔案來更新azureFunctions.deploySubpath延伸模組設定。 在建置步驟或 CI/CD 管道中,檢查可能存在於專案程式碼外之架構版本的任何相依性。

套件參考

移轉至隔離的背景工作角色模型時,您需要變更應用程式參考的套件。

如果您尚未這麼做,請更新專案以參考最新穩定版本的:

根據應用程式所使用的觸發程序和繫結,您的應用程式可能需要參考一組不同的套件。 下表顯示一些最常用延伸模組的取代項目:

狀況 套件參考的變更
計時器觸發程序
Microsoft.Azure.Functions.Worker.Extensions.Timer
儲存體繫結 Replace
Microsoft.Azure.WebJobs.Extensions.Storage
取代為
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Microsoft.Azure.Functions.Worker.Extensions.Tables
Blob 繫結 將參考取代為
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
佇列繫結 將參考取代為
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
資料表繫結 將參考取代為
Microsoft.Azure.WebJobs.Extensions.Tables
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB 繫結 將參考取代為
Microsoft.Azure.WebJobs.Extensions.CosmosDB
和/或
Microsoft.Azure.WebJobs.Extensions.DocumentDB
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
服務匯流排繫結 將參考取代為
Microsoft.Azure.WebJobs.Extensions.ServiceBus
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
事件中樞繫結 將參考取代為
Microsoft.Azure.WebJobs.Extensions.EventHubs
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
事件方格繫結 將參考取代為
Microsoft.Azure.WebJobs.Extensions.EventGrid
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR Service 繫結 將參考取代為
Microsoft.Azure.WebJobs.Extensions.SignalRService
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Durable Functions 將參考取代為
Microsoft.Azure.WebJobs.Extensions.DurableTask
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions
(SQL 儲存體提供者)
將參考取代為
Microsoft.DurableTask.SqlServer.AzureFunctions
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions
(Netherite 儲存體提供者)
將參考取代為
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid 繫結 將參考取代為
Microsoft.Azure.WebJobs.Extensions.SendGrid
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Kafka 繫結 將參考取代為
Microsoft.Azure.WebJobs.Extensions.Kafka
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.Kafka
RabbitMQ 繫結 將參考取代為
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
最新版本的
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
相依性插入
和啟動設定
移除對下列項目的參考:
Microsoft.Azure.Functions.Extensions
(隔離型工作者模型預設會提供這項功能。)

如需查看需要考慮的完整延伸模組清單,請參閱支援的繫結,並參閱每個延伸模組的文件,以獲取隔離處理程序模型的完整安裝說明。 對於您要以其作為目標的任何套件,請務必安裝其最新穩定版本。

秘訣

此程序期間對延伸模組版本所做的任何變更,也可能需要您更新 host.json 檔案。 請務必閱讀您使用的每個延伸模組的文件。 例如,Service Bus 擴充功能在 4.x 和 5.x 版之間的結構有重大變更。 如需詳細資訊,請參閱 Azure Functions 的 Azure 服務匯流排綁定

隔離式工作者模型應用程式不應引用 Microsoft.Azure.WebJobs.* 命名空間或 Microsoft.Azure.Functions.Extensions 的任何套件。 如果您有任何對這些項目的其餘參考,則應該移除這些參考。

秘訣

您的應用程式可能會依賴於 Azure SDK 類型,無論是作為觸發器和繫結的一部分,或是作為單獨的相依性。 您也應該利用這個機會來更新這些項目。 最新版的 Functions 延伸模組會與適用於 .NET 的 Azure SDK 最新版本搭配運作,其幾乎所有套件的格式都是 Azure.*

program.cs 檔案

移轉以在隔離式背景工作處理序中執行時,您必須使用下列內容來將 Program.cs 檔案新增至您的專案中:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

此範例包含 ASP.NET Core 整合,以改善效能,並在您的應用程式使用 HTTP 觸發程序時提供熟悉的程式設計模型。 如果您不打算使用 HTTP 觸發程式,可以將 ConfigureFunctionsWebApplication 的呼叫替換為 ConfigureFunctionsWorkerDefaults 的呼叫。 如果這樣做,您可以從專案檔中移除對 Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore 的參考。 不過,為了獲得最佳效能,甚至是其他觸發程序類型的函式,您也應該保留對 ASP.NET Core 的 FrameworkReference

Program.cs檔案會取代具有 FunctionsStartup 屬性的任何檔案,通常是Startup.cs檔案。 在程式FunctionsStartup代碼會參考IFunctionsHostBuilder.Services的位置,您可以改為在Program.csHostBuilder方法中新增.ConfigureServices()語句。 若要深入瞭解如何使用 Program.cs,請參閱隔離的背景工作模型指南中的 啟動和 設定。

先前描述的預設 Program.cs 範例包括 Application Insights 的設定。 在您的 Program.cs中,您也必須設定應該套用至專案中程式代碼所產生記錄的任何記錄篩選。 在隔離的工作者模型中,host.json 檔案僅控制由 Function 主機執行環境所觸發的事件。 如果您未在 Program.cs 中設定篩選規則,您可能會看到遙測中各種類別的記錄層級差異。

雖然您可以將自定義組態來源註冊為HostBuilder的一部分,但這些同樣僅適用於您專案中的程式碼。 平臺也需要觸發程式和系結組態,這應該透過 應用程式設定Key Vault 參考應用程式組態參考 功能來提供。

將所有專案從任何現有的 FunctionsStartup 檔案移至 Program.cs 檔案之後,您可以刪除 FunctionsStartup 屬性及其套用的類別。

函式簽章變更

一些主要類型會在內含式模型與隔離的背景工作角色模型之間變更。 其中許多都與組成函式簽章的屬性、參數和傳回型別有關。 針對每一個功能,您必須對下列項目進行修改:

  • 函式屬性,也會設定函式的名稱
  • 函式如何取得 ILogger/ILogger<T>
  • 觸發程序與繫結屬性和參數

本節的其餘部分會引導您完成每個步驟。

函數屬性

隔離工作者模型中的 Function 屬性會取代 FunctionName 屬性。 新的屬性具有相同的簽章,唯一的差異在於名稱。 因此,您可以在整個專案中執行字串替換。

記錄

在內含式模型中,您可以為您的函式包含選用的 ILogger 參數,或使用相依性插入來取得 ILogger<T>。 如果您的應用程式已經使用依賴注入,則相同的機制也可以在隔離工作者模型中運作。

不過,對於仰賴 ILogger 方法參數的任何 Functions,您必須進行變更。 建議您使用相依性插入來取得 ILogger<T>。 使用下列步驟來遷移函式的記錄機制:

  1. 在您的函式類別中,新增 private readonly ILogger<MyFunction> _logger; 屬性,並將 MyFunction 取代為函式類別的名稱。

  2. 為您的函式類別建立建構函式,其接受 ILogger<T> 做為參數:

    public MyFunction(ILogger<MyFunction> logger) {
        _logger = logger;
    }
    

    將上述程式碼片段中的這兩個 MyFunction 執行個體取代為函式類別的名稱。

  3. 若要記錄函式程式碼中的作業,請將 ILogger 參數的參考取代為 _logger

  4. 從函式簽章中移除 ILogger 參數。

若要深入了解,請參閱在隔離的背景工作角色模型中記錄

觸發程序和繫結變更

當您在上一個步驟中變更套件參考時,即引進了觸發程序和繫結的錯誤,您現在可以修正這些錯誤:

  1. 移除任何 using Microsoft.Azure.WebJobs; 陳述式。

  2. 新增 using Microsoft.Azure.Functions.Worker; 陳述式。

  3. 針對每個繫結屬性,按照其參考文件中的指定來變更屬性的名稱,您可以在支援的繫結索引中找到相關文件。 一般而言,屬性名稱會變更,如下所示:

    • 觸發程序通常會維持以相同方式命名。 例如,QueueTrigger 是這兩個模型的屬性名稱。
    • 輸入繫結通常需要將 Input 新增至其名稱。 例如,如果您在內嵌模型中使用了 CosmosDB 輸入繫結屬性,該屬性現在將變為 CosmosDBInput
    • 輸出系結通常需要 Output 新增至其名稱。 例如,如果您在內含式模型中使用 Queue 輸出繫結屬性,此屬性現在會是 QueueOutput
  4. 更新屬性參數以反映隔離的背景工作角色模型版本,如繫結的參考文件中所指定。

    例如,在內含式模型中,Blob 輸出繫結是由包含 Access 屬性 (property) 的 [Blob(...)] 屬性 (attribute) 來表示。 在隔離的背景工作角色模型中,Blob 輸出屬性會是 [BlobOutput(...)]。 繫結不再需要 Access 屬性,因此可以移除該參數。 因此,[Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] 將成為 [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")]

  5. 將輸出繫結移出函式參數清單。 如果您只有一個輸出繫結,您可以將此套用至函式的傳回型別。 如果您有多個輸出,請為每個輸出建立具有屬性 (property) 的新類別,並將屬性 (attribute) 套用至這些屬性 (property)。 若要深入了解,請參閱多個輸出繫結

  6. 請參閱每個繫結的參考文件,以取得其可讓您繫結的目標類型。 在某些情況下,您可能需要變更類型。 針對輸出繫結,如果內含式模型版本使用 IAsyncCollector<T>,則您可以將此取代為繫結至目標類型的陣列:T[]。 您也可以考慮將輸出繫結取代為其所代表服務的用戶端物件,可以是輸入繫結 (若有) 的繫結類型,或自行插入用戶端

  7. 如果您的函式包含 IBinder 參數,請將其移除。 將功能取代為其所代表服務的用戶端物件,可以是輸入繫結 (若有) 的繫結類型,或自行插入用戶端

  8. 更新函式程式碼以相容任何新類型。

local.settings.json 檔案

local.settings.json 檔案只有在本機執行時才會使用。 如需詳細資訊,請參閱本機設定檔

從執行內含式移轉至在隔離式背景工作處理序中執行時,您需要將 FUNCTIONS_WORKER_RUNTIME 值變更為 dotnet-isolated。 請確定 您的local.settings.json 檔案至少有下列元素:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

您所擁有的 AzureWebJobsStorage 值可能不同。 您不需要在移轉過程中變更其值。

host.json 檔案

您的 host.json 檔案不需要變更。 不過,如果您的 Application Insights 組態位於內部處理模型專案的此檔案中,您可能會想要在 Program.cs 檔案中進行其他變更。 host.json 檔案只會控制 Functions 主機運行時的記錄,而在隔離工作者模型中,其中一些記錄會直接來自您的應用程式,讓您有更多控制權。 如需如何篩選這些日誌的詳細資料,請參閱隔離工作者模型中管理日誌層級

其他程式碼變更

本節會醒目提示當您完成移轉時所要考量的其他程式碼變更。 所有應用程式不需要這些變更,但您應該評估是否有任何與案例相關。

JSON 序列化

根據預設,隔離的背景工作模型會使用 System.Text.Json 進行 JSON 串行化。 若要自定義串行化程序選項或切換至 JSON.NET (Newtonsoft.Json),請參閱 自定義 JSON 串行化

Application Insights 記錄層級和篩選

您可以從 Functions 主機執行階段和專案中的程式碼將記錄傳送至 Application Insights。 host.json 可讓您設定主機記錄的規則,但若要控制來自程式代碼的記錄,您必須將篩選規則設定為Program.cs的一部分。 如需篩選這些記錄的詳細方法,請參閱在隔離工作者模型中管理記錄層級

範例函式移轉

HTTP 觸發程序範例

內部處理模型的 HTTP 觸發器可能如下範例所示:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

移轉後版本的 HTTP 觸發程序可能像下列範例:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = logger;
        }

        [Function("HttpTriggerCSharp")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

在 Azure 中更新函數應用程式

將函式應用程式更新至隔離的模型牽涉到兩項應該一起完成的變更,因為如果您只完成一項,應用程式會處於錯誤狀態。 這兩項變更也會導致應用程式程序重新啟動。 基於這些理由,您應該使用暫存槽位來進行更新。 預備位置有助於將應用程式的停機時間降到最低,並可讓您使用 Azure 中更新的組態來測試及驗證已移轉的程式碼。 然後,您可以透過交換作業,將完全遷移的應用程式部署至生產位置。

重要

當應用程式的已部署承載不符合設定的運行時間時,其會 處於錯誤狀態。 在移轉過程中,您會將應用程式置於此狀態,理想情況下只會暫時。 部署插槽有助於減輕這種情況的影響,因為錯誤狀態會在預備(非生產)環境中解決,然後再將變更作為單一更新套用到生產環境。 位置也會防範任何錯誤,並可讓您在達到生產之前偵測任何其他問題。

在此過程中,您可能在記錄中看到來自預備 (非生產) 位置的錯誤。 這是預期的,雖然當您繼續進行步驟時,這些錯誤應會消失。 在執行位置交換作業之前,確認這些錯誤不再出現,並確保您的應用程式如預期般運作。

使用下列步驟,使用部署位置將函式應用程式更新為隔離的背景工作模型:

  1. 如果您尚未建立部署插槽,請建立部署插槽。 您可能也想要熟悉插槽交換過程,並確保自己能夠在以最小的中斷對現有應用程式進行更新。

  2. FUNCTIONS_WORKER_RUNTIME 應用程式設定設為 dotnet-isolated,以將預備 (非生產) 位置的組態變更為使用隔離的背景工作模型。 FUNCTIONS_WORKER_RUNTIME 應該不要標示為「位置設定」

    如果您也以不同版本的 .NET 作為更新的一部分為目標,則也應該變更堆棧組態。 若要這樣做,請參閱 更新堆疊組態。 您可以針對您所做的任何未來 .NET 版本更新使用相同的指示。

    如果您有任何自動化基礎結構佈建,例如 CI/CD 管線,請確定自動化也會更新,讓 FUNCTIONS_WORKER_RUNTIME 設定為 dotnet-isolated,並以正確的 .NET 版本為目標。

  3. 將移轉的專案發佈至函式應用程式的預備 (非生產) 位置。

    如果您使用 Visual Studio 將獨立工作模型專案發佈至使用內含式模型的現有應用程式或插槽,它也可同時為您完成上一個步驟。 如果您未完成上一個步驟,Visual Studio 會提示您在部署期間更新函式應用程式。 Visual Studio 會將此呈現為單一作業,但這些仍是兩個不同的作業。 在臨時狀態期間,您可能會在記錄中看到來自預備 (非生產) 位置的錯誤。

  4. 確認您的應用程式在中繼(非生產)階段如預期般運作。

  5. 執行 插槽交換操作,將您在預備插槽(非生產環境)中所做的變更套用到生產插槽。 插槽交換會以單一更新的形式進行,避免在生產環境中引入臨時錯誤狀態。

  6. 確認您的應用程式在生產環境中如預期般運作。

完成這些步驟後,移轉就會完成,而您的應用程式會在隔離的模型上執行。 恭喜! 視需要 移轉的任何其他應用程式,重複本指南中的步驟。

後續步驟