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 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, è consigliabile usare le guide seguenti per aggiornare la versione host. Queste guide alla migrazione delle versioni host consentono anche di eseguire la migrazione al modello di lavoro isolato durante l'utilizzo.

• Eseguire la migrazione delle app dalla versione 2.x e 3.x alla versione 4.x di Funzioni di Azure
• Eseguire la migrazione delle app dalla versione 1.x alla versione 4.x di Funzioni di Azure

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

Identificare le app per le funzioni di cui eseguire la migrazione

Usare il seguente script di Azure PowerShell per generare un elenco di app di funzioni nel tuo abbonamento che attualmente utilizzano il modello in-process.

Lo script usa la sottoscrizione attualmente configurata per l'uso di Azure PowerShell. È possibile modificare la sottoscrizione eseguendo prima Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' e sostituendo <YOUR SUBSCRIPTION ID> con l'ID della sottoscrizione da 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

Nella versione 4.x del runtime di Functions, l'app per le funzioni .NET è configurata per .NET 6 o .NET 8 quando si usa il modello in-process.

Quando si esegue la migrazione dell'app per le funzioni, è possibile scegliere la versione di destinazione di .NET. È possibile aggiornare il progetto C# a una delle versioni seguenti di .NET supportate da Funzioni versione 4.x:

¹ Il modello di lavoro isolato supporta le versioni LTS (Long Term Support) e STS (Standard Term Support) di .NET, nonché .NET Framework. Il modello In-Process supporta solo i rilasci LTS di .NET che terminano con .NET 8. Per un confronto completo delle caratteristiche e delle funzionalità tra i due modelli, vedere Differenze tra il processo di lavoro In-Process e isolato per Funzioni di Azure .NET.

² Il supporto per il modello In-Process terminerà il 10 novembre 2026. Per altre informazioni, vedere questo annuncio relativo al supporto. Per la prosecuzione del supporto completo, eseguire la migrazione delle app al modello di lavoro isolato.

Questa guida non presenta esempi specifici per .NET 9. Se è necessario scegliere tale versione, è possibile adattare gli esempi di .NET 8.

Preparare la migrazione

Prima di eseguire la migrazione di un'app al modello di lavoro isolato, è necessario esaminare attentamente il contenuto di questa guida. È anche consigliabile acquisire familiarità con le funzionalità del modello di lavoro isolato e le differenze di 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 la migrazione del progetto, testare l'app in locale usando la versione 4.x di Azure Functions Core Tools.
3. Aggiornare l'app per le funzioni in Azure al modello isolato.

Eseguire la migrazione di un progetto locale

La sezione descrive le varie modifiche che è necessario apportare al progetto locale per spostarlo nel modello di lavoro 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

L'esempio seguente è un file di progetto con estensione csproj che usa .NET 8 nella 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="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>

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
      <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
      <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 esegue la migrazione al modello di lavoro isolato, è necessario modificare i pacchetti a cui fa riferimento l'applicazione.

Se non è stato ancora fatto, aggiornare il progetto in modo che faccia riferimento alle versioni stabili più recenti di:

• Microsoft.Azure.Functions.Worker
• Microsoft.Azure.Functions.Worker.Sdk

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 si esegue la migrazione per l'esecuzione in un processo di lavoro isolato, è necessario aggiungere un file Program.cs al progetto con il contenuto seguente:

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 di Program.cs predefiniti descritti in precedenza includono la configurazione di 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, e questa deve essere fornita tramite le impostazioni dell'applicazione, i riferimenti a Key Vault o le funzionalità di riferimento alla configurazione app.

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 sono correlati agli attributi, ai parametri e ai tipi restituiti che costituiscono la firma della funzione. Per ognuna delle funzioni, è necessario apportare 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. È quindi possibile eseguire semplicemente una sostituzione di stringhe nel 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. È consigliabile usare l'inserimento delle dipendenze per ottenere un oggetto 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(...)]. L'associazione non richiede più la proprietà Access, quindi il parametro può essere rimosso. Perciò [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] diventerà [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

5. Spostare le associazioni di output dall'elenco dei parametri della funzione. Se si dispone di una sola associazione di output, è possibile applicarla al tipo restituito 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 le associazioni di output, se la versione del modello in-process ha usato un oggetto IAsyncCollector<T>, è possibile sostituirla con l'associazione a una matrice del tipo di destinazione: 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.

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. Assicurarsi che il file local.settings.json abbia almeno gli elementi seguenti:

{
    "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 modifiche aggiuntive nel file Program.cs . Il filehost.json controlla solo la registrazione dall'host del runtime di Funzioni e, nel modello di lavoro isolato, alcuni di questi log provengono direttamente dalla tua applicazione, offrendo un maggiore 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 Personalizzazione della serializzazione JSON.

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.

Migrazioni di funzioni di esempio

Esempio di trigger HTTP

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

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

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

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = 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 un'app per le funzioni in Azure

L'aggiornamento dell'app per le funzioni al modello isolato comporta due modifiche che devono essere completate insieme, perché se ne completa una sola, si verifica uno stato di errore nell’app. Entrambe queste modifiche causano anche il riavvio del processo dell'app. Per questi motivi, è consigliabile eseguire l'aggiornamento usando uno slot di staging. Gli slot di staging aiutano a ridurre al minimo il tempo di inattività e permettono di testare e verificare il codice migrato con la configurazione aggiornata in Azure. È quindi possibile distribuire l'app completamente migrata nello slot di produzione tramite un'operazione di scambio.

Usare la procedura seguente per usare gli slot di distribuzione per aggiornare l'app per le funzioni al modello di lavoro isolato:

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. FUNCTIONS_WORKER_RUNTIME non deve essere contrassegnato come impostazione slot.

   Se si usa anche una versione diversa di .NET come parte dell'aggiornamento, è necessario modificare anche la configurazione dello stack. A tale scopo, vedere Aggiornare la configurazione dello stack. È possibile usare le stesse istruzioni per tutti gli aggiornamenti futuri delle versioni di .NET apportati.

   Se disponi di un'infrastruttura automatizzata per il provisioning, come ad esempio una pipeline CI/CD, assicurati che le automazioni siano aggiornate anche per mantenere FUNCTIONS_WORKER_RUNTIME configurato su dotnet-isolated e per mirare 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 in uno slot esistente che usa il modello in-process, è possibile che il passaggio precedente venga completato contemporaneamente. Se il passaggio precedente non è stato completato, Visual Studio richiede di aggiornare l'app per le funzioni durante la distribuzione. Visual Studio presenta questa operazione come singola operazione benché siano ancora 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