Eseguire la migrazione di app .NET 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. Altrimenti, è consigliabile seguire le guide per aggiornare la versione host:

• 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

Queste guide alla migrazione delle versioni host consentono anche di eseguire la migrazione al modello di lavoro isolato durante l'utilizzo.

Identificare le app per le funzioni di cui eseguire la migrazione

Usare lo script di Azure PowerShell seguente per generare un elenco di app per le funzioni nella sottoscrizione che attualmente usano 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 Funzioni, l'app per le funzioni .NET è destinata a .NET 6 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.

³ Vedere Anteprima delle versioni di .NET in Modello di lavoro isolato per informazioni dettagliate su supporto, restrizioni correnti e istruzioni per l'uso della versione di anteprima.

Questa guida non presenta esempi specifici per .NET 9 (anteprima) o .NET 6. Se è necessario scegliere queste versioni, è possibile adattare gli esempi di .NET 8.

Preparare la migrazione

Se non è stato ancora fatto, identificare l'elenco di app che richiedono la migrazione nella propria sottoscrizione di Azure corrente tramite Azure PowerShell.

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, è necessario:

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. Questi passaggi presuppongono un progetto C# locale; se l'app, invece, usa script C# (file .csx), è necessaria la conversione al modello di progetto prima di continuare.

In primo luogo, convertire il file di progetto e aggiornare le dipendenze. Così facendo, verranno visualizzati gli errori di compilazione del progetto. Nei passaggi successivi verranno apportate le modifiche corrispondenti per rimuovere questi errori.

File di progetto

L'esempio seguente è un file di progetto .csproj che usa .NET 6 nella versione 4.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.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/settings.json del progetto. Verificare la presenza di eventuali dipendenze dalla versione del framework che possono 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 pacchetti, 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 sostituirà qualunque file con l'attributo FunctionsStartup, che generalmente è un file Startup.cs. Nei punti in cui il codice FunctionsStartup fa riferimento a IFunctionsHostBuilder.Services, invece, è possibile aggiungere istruzioni all'interno del metodo .ConfigureServices() di HostBuilder in Program.cs. Per altre informazioni sull'uso di Program.cs, vedere Avvio e configurazione nella guida al modello di lavoro isolato.

Gli esempi di Program.cs predefiniti precedenti includono la configurazione dell'integrazione di Application Insights per il modello di lavoro isolato. In Program.cs è necessario configurare anche tutti i filtri di log che devono essere applicati ai log provenienti dal codice nel progetto. Nel modello di lavoro isolato il file host.json controlla solo gli eventi emessi dal runtime dell'host di Funzioni. Se non si configurano regole di filtro in Program.cs, è possibile che vengano visualizzate differenze nei livelli di log presenti per varie categorie nei dati di telemetria.

Anche se è possibile registrare origini di configurazione personalizzate come parte di HostBuilder, tenere presente che si applicano in modo analogo solo al codice nel progetto. La configurazione dei trigger e delle associazioni è necessaria anche per la piattaforma e deve essere effettuata tramite le funzionalità di impostazioni dell'applicazione, riferimenti a Key Vault o riferimenti alla Configurazione app.

Dopo aver spostato tutti gli elementi da qualunque FunctionsStartup esistente nel file Program.cs, è possibile eliminare l'attributo FunctionsStartup e la classe a cui è stato applicato.

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 trigger 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 ILogger facoltativo 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 verranno risolti:

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 richiedono in genere l'aggiunta di "Output" al 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. Consultare la documentazione di riferimento di ogni associazione per i tipi a cui è consentita l'associazione. 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 local.settings.json è utilizzato solo con 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 contenga almeno gli elementi seguenti:

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

Il valore disponibile 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 è contenuta in questo file dal progetto di modello in-process, può essere necessario apportare modifiche aggiuntive nel file Program.cs. Il file host.json controlla solo la registrazione dal runtime dell'host di Funzioni e nel modello di lavoro isolato alcuni di questi log provengono direttamente dall'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 è preferibile valutare se sono pertinenti 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 queste istruzioni.

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. host.json consente di configurare regole per la registrazione dell'host, ma per controllare i log provenienti dal codice è necessario configurare regole di filtro come parte di 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. Creare uno slot di distribuzione se non è già disponibile. È 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 imposta come destinazione anche una versione diversa di .NET come parte dell'aggiornamento, è necessario modificare anche la configurazione dello stack. Per effettuare questa operazione, vedere le istruzioni per aggiornare la configurazione dello stack per il modello di lavoro isolato. Sarà necessario usare le stesse istruzioni per eventuali aggiornamenti futuri delle versioni di .NET apportati.

   Se si dispone di un provisioning automatizzato dell'infrastruttura, ad esempio una pipeline CI/CD, assicurarsi che le automazioni vengano aggiornate anche per mantenere FUNCTIONS_WORKER_RUNTIME impostato su dotnet-isolated e per impostare come destinazione la 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 un'operazione di scambio di slot. Ciò applica le modifiche apportate nello slot di staging (non di produzione) allo slot di produzione. Uno scambio di slot viene eseguito come singolo aggiornamento, che evita che lo stato di errore provvisorio venga introdotto nell'ambiente di produzione.

6. Verificare che l'applicazione funzioni come previsto nello slot 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 qualsiasi altra app che richiede la migrazione.

Passaggi successivi