Eseguire la migrazione di app C# dal modello in-process al modello di lavoro isolato

Questo articolo illustra il processo di migrazione sicura dell'app per le funzioni .NET dal modello di lavoro in-process al modello di lavoro isolato. Per informazioni sulle differenze generali tra questi modelli, vedere il confronto tra la modalità di esecuzione.

Questa guida presuppone che l'app sia in esecuzione nella versione 4.x del runtime di Funzioni. In caso contrario, utilizza le guide seguenti per aggiornare la versione dell'host. Queste guide alla migrazione delle versioni host consentono anche di eseguire la migrazione al modello di lavoro isolato durante l'utilizzo.

• Migrare le app da Funzioni di Azure versione 2.x e 3.x alla versione 4.x
• Migrare le app da Funzioni di Azure versione 1.x alla versione 4.x

Se supportato, questo articolo sfrutta ASP.NET Core integrazione nel modello di lavoro isolato, che migliora le prestazioni e fornisce un modello di programmazione familiare quando l'app usa trigger HTTP.

Identificare le app per le funzioni di cui eseguire la migrazione

Utilizzare il seguente script di Azure PowerShell per generare un elenco di funzioni app nella propria sottoscrizione che attualmente utilizzano il modello in-process.

Lo script usa la sottoscrizione che Azure PowerShell è attualmente configurata per utilizzare. Puoi cambiare l'abbonamento prima eseguendo Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' e sostituendolo <YOUR SUBSCRIPTION ID> con l'ID dell'abbonamento che vuoi valutare.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

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

$AppInfo

Scegliere la versione di .NET di destinazione

Quando si migra al modello worker isolato, scegli il target in base al fatto che la tua app di funzioni e le sue dipendenze possano funzionare su .NET (precedentemente .NET Core):

• Se la tua app e le sue dipendenze possono funzionare su .NET, punta a .NET 10.
• Se la tua app dipende da librerie o API disponibili solo in .NET Framework, punta a .NET Framework 4.8.

Preparare la migrazione

Prima di migrare un'app al modello del lavoratore isolato, esamina attentamente il contenuto di questa guida. Inoltre, familiarizza con le caratteristiche del modello del lavoratore isolato e le differenze tra i due modelli.

Per eseguire la migrazione dell'applicazione:

1. Eseguire la migrazione di un progetto locale al modello di lavoro isolato seguendo la procedura descritta in Eseguire la migrazione di un progetto locale.
2. Dopo aver migrato il tuo progetto, testa completamente l'app localmente utilizzando la versione 4.x degli Funzioni di Azure Core Tools.
3. Aggiornare l'app per le funzioni in Azure al modello isolato.

Eseguire la migrazione di un progetto locale

Questa sezione illustra le varie modifiche che devi apportare al tuo progetto locale per passare al modello del lavoratore isolato. Alcuni passaggi cambiano in base alla versione di destinazione di .NET. Usare le schede per selezionare le istruzioni corrispondenti alla versione desiderata.

Per prima cosa, converte il file di progetto e aggiorna le dipendenze. Man mano che lo fai, vengono visualizzati errori di build per il progetto. Nei passaggi successivi verranno apportate le modifiche corrispondenti per rimuovere questi errori.

File di progetto

Il seguente esempio mostra un file di progetto .csproj che utilizza .NET 8 sulla versione 4.x:

<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>

Utilizzare una delle procedure seguenti per aggiornare questo file XML da eseguire nel modello di lavoro isolato:

<Project Sdk="Azure.Functions.Sdk/1.0.0">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <RootNamespace>My.Namespace</RootNamespace>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.52.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.1.0" />
    <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>

<Project Sdk="Azure.Functions.Sdk/1.0.0">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
    <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>
    <Folder Include="Properties\" />
  </ItemGroup>
</Project>

La modifica del framework di destinazione del progetto potrebbe richiedere anche modifiche a parti della toolchain, esternamente al codice del progetto. Ad esempio, in VS Code potrebbe essere necessario aggiornare l'impostazione dell'estensione azureFunctions.deploySubpath tramite le impostazioni utente o il file vscode/ del progettosettings.json . Verificare la presenza di eventuali dipendenze dalla versione del framework che potrebbero esistere al di fuori del codice del progetto, come parte dei passaggi di compilazione o di una pipeline CI/CD.

Riferimenti ai pacchetti

Quando si migra al modello di worker isolato, cambia i pacchetti a cui fa riferimento la tua applicazione.

Se non l'hai già fatto, aggiorna il tuo progetto per utilizzare le ultime versioni stabili di:

• Microsoft.Azure. Functions.Worker
• Azure. Functions.Sdk come SDK del progetto

A seconda dei trigger e delle associazioni usate dall'app, l'app potrebbe dover fare riferimento a un set diverso di pacchetti. La tabella seguente illustra le sostituzioni per alcune delle estensioni più usate:

Per un elenco completo delle estensioni da considerare, vedere Associazioni supportate e consultare la documentazione di ogni estensione per le istruzioni complete sull'installazione per il modello di processo isolato. Accertarsi di installare la versione stabile più recente di ogni pacchetto di destinazione.

L'applicazione del modello di lavoro isolato non deve fare riferimento ad alcun pacchetto negli spazi dei nomi Microsoft.Azure.WebJobs.* o Microsoft.Azure.Functions.Extensions. Se esistono riferimenti rimanenti a questi, devono essere rimossi.

File program.cs

Quando migri per eseguire un processo worker isolato, aggiungi un file Program.cs al tuo progetto con i seguenti contenuti:

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();

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

namespace Company.FunctionApp
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

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

Il file Program.cs sostituisce qualsiasi file con l'attributo FunctionsStartup , che in genere è un file Startup.cs . Nelle posizioni in cui il FunctionsStartup codice fa riferimento a IFunctionsHostBuilder.Services, è invece possibile aggiungere istruzioni nel .ConfigureServices() metodo del HostBuilder nella Program.cs. Per altre informazioni sull'uso di Program.cs, vedere Start-up and configuration (Avvio e configurazione ) nella guida al modello di lavoro isolato.

Gli esempi predefiniti Program.cs descritti in precedenza configurano Application Insights utilizzando l'SDK Application Insights. Per la configurazione Application Insights basata su OpenTelemetry descritta nella guida al modello di lavoratori isolati, vedi Application Insights. Nel Program.cs è necessario configurare anche qualsiasi filtro di log che deve essere applicato ai log provenienti dal codice nel progetto. Nel modello di lavoro isolato il filehost.json controlla solo gli eventi generati dal runtime dell'host di Funzioni. Se non si configurano le regole di filtro in Program.cs, è possibile che vengano visualizzate differenze nei livelli di log presenti per varie categorie nei dati di telemetria.

Sebbene sia possibile registrare origini di configurazione personalizzate come parte di HostBuilder, queste si applicano in modo analogo solo al codice nel progetto. La piattaforma richiede anche la configurazione di trigger e binding, che deve essere fornita attraverso le impostazioni dell'applicazione, riferimenti di Key Vault, o riferimenti di App Configuration.

Dopo aver spostato tutti gli elementi da qualsiasi file esistente FunctionsStartup al file Program.cs , è possibile eliminare l'attributo FunctionsStartup e la classe a cui è stata applicata.

Modifiche alla firma della funzione

Alcuni tipi di chiave cambiano tra il modello in-process e il modello di lavoro isolato. Molti di questi cambiamenti riguardano gli attributi, i parametri e i tipi di ritorno che compongono la firma della funzione. Per ciascuna delle tue funzioni, apporta modifiche a:

• Attributo della funzione, che imposta anche il nome della funzione
• Modo in cui la funzione ottiene un ILogger/ILogger<T>
• Attributi e parametri di attivazione e associazione

Nella parte restante di questa sezione vengono illustrati ciascuno di questi passaggi.

Attributi di funzioni

L'attributo Function nel modello di lavoro isolato viene sostituito dall'attributo FunctionName. Il nuovo attributo ha la stessa firma e l'unica differenza è nel nome. Puoi quindi eseguire una sostituzione delle corde su tutto il progetto.

Registrazione

Nel modello in-process è possibile includere un parametro facoltativo ILogger per la funzione oppure usare l'inserimento delle dipendenze per ottenere un oggetto ILogger<T>. Se l’app usa già l'inserimento delle dipendenze, gli stessi meccanismi funzionano nel modello di lavoro isolato.

Tuttavia, per qualsiasi funzione basata sul parametro del metodo ILogger, è necessario apportare una modifica. Usa l'iniezione di dipendenza per ottenere un ILogger<T>. Per eseguire la migrazione del meccanismo di registrazione della funzione, seguire questa procedura:

1. Nella classe della funzione aggiungere una proprietà private readonly ILogger<MyFunction> _logger;, sostituendo MyFunction con il nome della classe della funzione.

2. Creare un costruttore per la classe di funzione che accetta ILogger<T> come parametro:

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

   Sostituire entrambe le istanze di MyFunction nel frammento di codice precedente con il nome della classe della funzione.

3. Per le operazioni di registrazione nel codice della funzione, sostituire i riferimenti al parametro ILogger con _logger.

4. Rimuovere il parametro ILogger dalla firma della funzione.

Per altre informazioni, vedere Registrazione nel modello di lavoro isolato.

Modifiche al trigger e all'associazione

Quando sono stati modificati i riferimenti al pacchetto in un passaggio precedente, sono stati introdotti errori per i trigger e le associazioni che è ora possibile correggere:

1. Rimuovere tutte le istruzioni using Microsoft.Azure.WebJobs;.

2. Aggiungere un'istruzione using Microsoft.Azure.Functions.Worker;.

3. Per ogni attributo di associazione, modificare il nome dell'attributo come specificato nella relativa documentazione di riferimento, disponibile nell'indice Associazioni supportate. In generale, i nomi degli attributi cambiano nel modo seguente:

   • I trigger rimangono in genere denominati allo stesso modo. Ad esempio, QueueTrigger è il nome dell'attributo per entrambi i modelli.
   • Le associazioni di input richiedono in genere l'aggiunta di Input al nome. Ad esempio, se è stato usato l'attributo di associazione di input CosmosDB nel modello in-process, l’attributo sarà CosmosDBInput.
   • Le associazioni di output devono in genere avere Output aggiunto al loro nome. Ad esempio, se è stato usato l'attributo di associazione di output Queue nel modello in-process, questo attributo sarà QueueOutput.

4. Aggiornare i parametri dell'attributo in modo che riflettano la versione del modello di lavoro isolato, come specificato nella documentazione di riferimento dell'associazione.

   Nel modello in-process, ad esempio, un'associazione di output BLOB è rappresentata da un attributo [Blob(...)] che include una proprietà Access. Nel modello di lavoro isolato l'attributo di output BLOB sarà [BlobOutput(...)]. Il binding non richiede più questa Access proprietà, quindi puoi rimuovere quel parametro. Quindi [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] diventa [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

5. Spostare le associazioni di output dall'elenco dei parametri della funzione. Se hai un solo binding di output, puoi applicare questo binding al tipo di ritorno della funzione. Se sono presenti più output, creare una nuova classe con proprietà per ogni output e applicare gli attributi a tali proprietà. Per altre informazioni, vedere Associazioni di output multipli.

6. Consultate la documentazione di riferimento di ogni associazione per i tipi cui è possibile associarsi. In alcuni casi, potrebbe essere necessario modificare il tipo. Per i binding di output, se la versione del modello in processo ha usato un IAsyncCollector<T>, puoi sostituire questo tipo collegandolo a un array del tipo target: T[]. È anche possibile sostituire l'associazione di output con un oggetto client per il servizio rappresentato, come tipo di associazione per un'associazione di input, se disponibile, o inserendo manualmente un client.

7. Se la funzione include un parametro IBinder, rimuoverlo. Sostituire la funzionalità con un oggetto client per il servizio rappresentato, come tipo di associazione per un'associazione di input, se disponibile, o inserendo manualmente un client.

8. Aggiornare il codice della funzione in modo che funzioni con qualsiasi nuovo tipo.

Eseguire la migrazione a I/O flusso HTTP asincrono

Se una funzione attivata da HTTP utilizza l'integrazione ASP.NET Core, sostituire le letture e scritture sincrone nei flussi di richieste e risposte HTTP con metodi asincroni. Le operazioni sincrone possono fallire con InvalidOperationException: Synchronous operations are disallowed. Ad esempio, sostituisci ReadToEnd con ReadToEndAsync, WriteAsyncWrite con WriteStringAsync, WriteString con , e Flush con FlushAsync.

Quando si attende l’esecuzione di queste operazioni, contrassegna il metodo della funzione come async e racchiudi il tipo restituito in Task<T>. Ad esempio, cambia IActionResult a Task<IActionResult> o MultiResponse in Task<MultiResponse>. ASP.NET Core non consente per impostazione predefinita le operazioni di I/O sincrone di richiesta e risposta perché l'I/O sincrono può causare l'esaurimento del pool di thread. Se una dipendenza o un serializzatore non supporta I/O asincrono, vedi serializzazione JSON con integrazione ASP.NET Core per istruzioni per abilitare l'I/O sincrono (AllowSynchronousIO) come opzione di compatibilità.

File local.settings.json

Il file dilocal.settings.json viene usato solo durante l'esecuzione in locale. Per informazioni, vedere File di impostazioni locali.

Quando si esegue la migrazione dall'esecuzione In-Process all'esecuzione in un processo di lavoro isolato, è necessario modificare il valore FUNCTIONS_WORKER_RUNTIME in dotnet-isolated. Assicurati che il tuo filelocal.settings.json contenga almeno i seguenti elementi:

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

Il valore per AzureWebJobsStorage potrebbe essere diverso. Non è necessario modificarne il valore come parte della migrazione.

File host.json

Non sono necessarie modifiche al file host.json. Tuttavia, se la configurazione di Application Insights si trova in questo file dal progetto di modello in-process, potrebbe essere necessario apportare altre modifiche nel file Program.cs . Il file host.json controlla solo la registrazione del runtime host di Functions. Nel modello del worker isolato, alcuni di questi log provengono direttamente dalla tua applicazione, dandoti più controllo. Per informazioni dettagliate su come filtrare questi log, vedere Gestione dei livelli di log nel modello di lavoro isolato.

Altre modifiche al codice

In questa sezione vengono evidenziate altre modifiche al codice da considerare durante l'esecuzione della migrazione. Queste modifiche non sono necessarie per tutte le applicazioni, ma è consigliabile valutare se sono rilevanti per gli scenari in uso.

Serializzazione JSON

Per impostazione predefinita, il modello di lavoro isolato usa System.Text.Json per la serializzazione JSON. Per personalizzare le opzioni del serializzatore o passare a JSON.NET (Newtonsoft.Json), vedere Customizing JSON serialization.

Poiché il modello in processo utilizzava Newtonsoft.Json, controlla anche gli attributi di serializzazione su qualsiasi tipo a cui le tue funzioni si associano. System.Text.Json ignora attributi come [JsonProperty] e [JsonIgnore] da Newtonsoft.Json. Collega la proprietà interessata al suo valore predefinito senza segnalare errori. O li sostituiscono con i loro equivalenti System.Text.Json , come [JsonPropertyName], oppure configurano Newtonsoft.Json per il livello che gestisce il payload.

Filtri e livelli di log di Application Insights

I log possono essere inviati ad Application Insights sia dal runtime dell'host di Funzioni che dal codice nel progetto. Il host.json consente di configurare regole per la registrazione dell'host, ma per controllare i log provenienti dal codice, è necessario configurare le regole di filtro come parte del Program.cs. Per informazioni dettagliate su come filtrare questi log, vedere Gestione dei livelli di log nel modello di lavoro isolato.

Esempio di migrazione dei trigger HTTP

Il seguente esempio confronta una funzione attivata da HTTP prima e dopo la migrazione al modello worker isolato.

Un trigger HTTP per il modello in-process potrebbe essere simile all'esempio seguente:

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"]}!");
        }
    }
}

Un trigger HTTP per la versione migrata potrebbe essere simile all'esempio seguente:

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

namespace Company.Function
{
    public class HttpTriggerCSharp(ILogger<HttpTriggerCSharp> 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"]}!");
        }
    }
}

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
using System.Net;

namespace Company.Function
{
    public class HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
    {
        [Function("HttpTriggerCSharp")]
        public HttpResponseData Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequestData req)
        {
            logger.LogInformation("C# HTTP trigger function processed a request.");

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString($"Welcome to Azure Functions, {req.Query["name"]}!");

            return response;
        }
    }
}

Aggiornare l'app per le funzioni in Azure

Dopo aver migrato il progetto locale, aggiorna la configurazione dell'app di funzione e distribuisci il codice migrato per completare il passaggio al modello di worker isolato.

Prima di pubblicare il tuo progetto migrato

Prima di pubblicare il tuo progetto di codice aggiornato, pianifica di completare insieme questi due cambiamenti:

• Cambia l'impostazione dell'applicazione FUNCTIONS_WORKER_RUNTIME in dotnet-isolated.
• Pubblicare il progetto migrato del worker isolato nell'app per le funzioni.

Ogni modifica riavvia l'app. Dopo aver completato la prima modifica, il codice distribuito e il runtime configurato non corrispondono, il che causa un errore di discorrispondenza runtime/payload (AZFD0013) fino a quando non completi la seconda modifica.

Quando possibile, utilizza uno slot di staging durante la migrazione. Uno slot di staging ti offre questi vantaggi:

• Mantiene fuori produzione lo stato di errore temporaneo derivante dal disadattamento tra codice e runtime.
• Ti permette di testare il codice migrato e la configurazione prima di passarli in produzione.

Potresti vedere errori nei log dello slot di staging durante l'esecuzione delle due modifiche. Prima di cambiare lo slot, verifica che gli errori siano cessati e che l'app funzioni come previsto.

Aggiorna la tua app di funzionalità usando slot

Usare i seguenti passaggi per aggiornare l'app per le funzioni al modello del v isolato usando uno slot di gestione temporanea:

1. Crea uno slot di distribuzione se non l'hai già fatto. È anche opportuno acquisire familiarità con il processo di scambio degli slot e assicurarsi di poter apportare aggiornamenti all'applicazione esistente con interruzioni minime.

2. Modificare la configurazione dello slot di staging (non di produzione) per usare il modello di lavoro isolato impostando l'impostazione dell'applicazione FUNCTIONS_WORKER_RUNTIME su dotnet-isolated. Non contrassegnare FUNCTIONS_WORKER_RUNTIME come impostazione dello slot.

   Se stai anche puntando a una versione diversa di .NET come parte del tuo aggiornamento, cambia la configurazione dello stack. A tale scopo, vedere Aggiornare la configurazione dello stack. È possibile usare le stesse istruzioni per qualsiasi aggiornamento della versione .NET futuro apportato.

   Se disponi di processi automatizzati di provisioning dell'infrastruttura, ad esempio una pipeline CI/CD, assicurati che anche le automazioni siano aggiornate per mantenere FUNCTIONS_WORKER_RUNTIME impostato su dotnet-isolated e per puntare alla versione corretta di .NET.

3. Pubblicare il progetto migrato nello slot di staging (non di produzione) dell'app per le funzioni.

   Se si usa Visual Studio per pubblicare un progetto di modello di lavoro isolato in un'app o uno slot esistente che usa il modello in-process, può anche completare il passaggio precedente contemporaneamente. Se il passaggio precedente non è stato completato, Visual Studio richiede di aggiornare l'app per le funzioni durante la distribuzione. Visual Studio presenta questo aggiornamento come un'unica operazione, ma questi aggiornamenti sono comunque due operazioni separate. È comunque possibile che vengano visualizzati errori nei log dallo slot di staging (non di produzione) durante lo stato provvisorio.

4. Verificare che l'applicazione funzioni come previsto nello slot di staging (non di produzione).

5. Eseguire una operazione di scambio dello slot per applicare le modifiche apportate nello slot di staging (non di produzione) allo slot di produzione. Uno scambio di slot avviene tramite un unico aggiornamento, evitando che lo stato di errore temporaneo venga introdotto nell'ambiente di produzione.

6. Assicurati che l'applicazione funzioni come previsto nell'ambiente di produzione.

Al termine di questi passaggi, la migrazione è stata completata e l'app viene eseguita nel modello isolato. Complimenti. Ripetere i passaggi di questa guida in base alle esigenze per tutte le altre app che richiedono la migrazione.

Passaggio successivo