Eseguire la migrazione delle app dalla versione 1.x alla versione 4.x di Funzioni di Azure

Questo articolo illustra il processo di migrazione sicura di un'app per le funzioni da eseguire nella versione 4.x del runtime di Funzioni. Poiché le istruzioni di migrazione del progetto dipendono dal linguaggio, accertarsi di scegliere il linguaggio di sviluppo dal selettore, come riportato in cima all’articolo.

Se si esegue la versione 1.x del runtime nell'hub di Azure Stack, vedere prima Considerazioni per l'hub di Azure Stack.

Identificare le app per le funzioni di cui eseguire la migrazione

Usare lo script PowerShell seguente per generare un elenco di app per le funzioni nella sottoscrizione attualmente destinate alla versione 1.x:

$Subscription = '<YOUR SUBSCRIPTION ID>' 

Set-AzContext -Subscription $Subscription | Out-Null

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"] -like '*1*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

Scegliere la versione di .NET di destinazione

Nella versione 1.x del runtime di Funzioni, l'app per le funzioni C# è destinata a .NET Framework.

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 specificare tale versione, è possibile adattare gli esempi .NET 8 per il modello di lavoro isolato.

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 alla versione 4.x del runtime di Funzioni, è necessario eseguire le attività seguenti:

1. Esaminare l'elenco delle modifiche del comportamento dopo la versione 1.x. Anche la migrazione dalla versione 1.x alla versione 4.x può influire sulle associazioni.
2. Completare i passaggi descritti in Eseguire la migrazione di un progetto locale per eseguire la migrazione di un progetto locale alla versione 4.x.
3. Dopo la migrazione del progetto, testare l’app in locale usando la versione 4.x di Azure Functions Core Tools.
4. Aggiornare l'app per le funzioni in Azure alla nuova versione. Se è necessario ridurre al minimo il tempo di inattività, considerare l’uso di uno slot di staging per testare e verificare l’app migrata in Azure nella nuova versione del runtime. È possibile, quindi, distribuire l'app con le impostazioni della versione aggiornata nello slot di produzione. Per altre informazioni, vedere Aggiornamento tramite slot.
5. Pubblicare il progetto migrato nell'app per le funzioni aggiornata.

Quando si usa Visual Studio per pubblicare un progetto versione 4.x in un'app per le funzioni esistente con una versione precedente, viene chiesto di consentire a Visual Studio di aggiornare l'app per le funzioni alla versione 4.x durante la distribuzione. Questo aggiornamento usa lo stesso processo definito in Aggiornamento senza slot.

Eseguire la migrazione di un progetto locale

Le sezioni seguenti descrivono gli aggiornamenti che è necessario apportare ai file di progetto C# per poterli eseguire in una delle versioni supportate di .NET in Funzioni versione 4.x. Gli aggiornamenti visualizzati sono quelli comuni alla maggior parte dei progetti. Il codice del progetto potrebbe richiedere aggiornamenti non menzionati in questo articolo, specialmente quando si usano pacchetti NuGet personalizzati.

La migrazione di un'app per le funzioni C# dalla versione 1.x alla versione 4.x del runtime di Funzioni richiede di apportare modifiche al codice del progetto. Molte di queste modifiche sono il risultato di modifiche apportate al linguaggio C# e alle API .NET.

Scegliere la scheda corrispondente alla versione di destinazione di .NET e al modello di processo desiderato (processo di lavoro In-Process o isolato).

File di progetto

L'esempio seguente è un file di progetto .csproj eseguito nella versione 1.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v1</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
  </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 in Funzioni versione 4.x:

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

<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.4.0" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Modifiche ai pacchetti e agli spazi dei nomi

In base al modello a cui si esegue la migrazione, potrebbe essere necessario aggiornare o modificare i pacchetti a cui si fa riferimento all'applicazione. Quando si adottano i pacchetti di destinazione, è necessario aggiornare lo spazio dei nomi delle istruzioni using e alcuni tipi a cui si fa riferimento. È possibile visualizzare l'effetto di queste modifiche dello spazio dei nomi nelle istruzioni using negli esempi di modelli di trigger HTTP più avanti in questo articolo.

Le associazioni di Hub di notifica e App per dispositivi mobili sono supportate solo nella versione 1.x del runtime. Quando si esegue l'aggiornamento alla versione 4.x del runtime, è necessario rimuovere queste associazioni preferendo l’uso diretto di questi servizi tramite i relativi SDK.

File program.cs

Nella maggior parte dei casi, la migrazione richiede l’aggiunta del file di program.cs seguente al progetto:

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

File host.json

Le impostazioni nel file host.json si applicano a livello di app per le funzioni, sia in locale che in Azure. Nella versione 1.x, il file host.json è vuoto o contiene alcune impostazioni applicabili a tutte le funzioni nell'app per le funzioni. Per altre informazioni, vedere Host.json v1. Se il file host.json include valori di impostazione, esaminare il formato host.json v2 per rilevare eventuali modifiche.

Per l'esecuzione nella versione 4.x, è necessario aggiungere "version": "2.0" al file di host.json. È preferibile anche considerare l’aggiunta di logging alla configurazione, come negli esempi seguenti:

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            },
            "enableLiveMetricsFilters": true
        }
    }
}

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            },
            "enableLiveMetricsFilters": true
        }
    }
}

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            },
            "enableLiveMetricsFilters": true
        }
    }
}

File local.settings.json

Il file local.settings.json è utilizzato solo con l'esecuzione in locale. Per informazioni, vedere File di impostazioni locali. Nella versione 1.x, il file local.settings.json include solo due valori obbligatori:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "AzureWebJobsDashboard": "AzureWebJobsStorageConnectionStringValue"
    }
}

Quando si esegue la migrazione alla versione 4.x, assicurarsi che il file local.settings.json includa almeno gli elementi seguenti:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet",
        "FUNCTIONS_INPROC_NET8_ENABLED": "1"
    }
}

Modifiche del nome classe

Alcune classi chiave cambiano i nomi tra la versione 1.x e la versione 4.x. Queste modifiche sono il risultato di modifiche delle API .NET o delle differenze tra processo di lavoro In-Process e isolato. La tabella seguente indica le classi .NET chiave usate da Funzioni che potrebbero cambiare durante la migrazione:

Potrebbero verificarsi differenze tra i nomi classe anche nelle associazioni. Per altre informazioni, vedere gli articoli di riferimento per le associazioni specifiche.

Altre modifiche al codice

Modello di trigger HTTP

La maggior parte delle modifiche al codice tra la versione 1.x e la versione 4.x è visibile nelle funzioni attivate da HTTP. Il modello di trigger HTTP per la versione 1.x è simile all’esempio seguente:

using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static async Task<HttpResponseMessage> 
            Run([HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post", 
            Route = null)]HttpRequestMessage req, TraceWriter log)
        {
            log.Info("C# HTTP trigger function processed a request.");

            // parse query parameter
            string name = req.GetQueryNameValuePairs()
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            if (name == null)
            {
                // Get request body
                dynamic data = await req.Content.ReadAsAsync<object>();
                name = data?.name;
            }

            return name == null
                ? req.CreateResponse(HttpStatusCode.BadRequest, 
                    "Please pass a name on the query string or in the request body")
                : req.CreateResponse(HttpStatusCode.OK, "Hello " + name);
        }
    }
}

Nella versione 4.x, il modello di trigger HTTP è 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;
        }
    }
}

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;

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

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            string responseMessage = string.IsNullOrEmpty(name)
                ? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
                : $"Hello, {name}. This HTTP triggered function executed successfully.";

            return new OkObjectResult(responseMessage);
        }
    }
}

Per aggiornare un progetto a Funzioni di Azure 4.x:

1. Aggiornare l'installazione locale di Azure Functions Core Tools alla versione 4.x.

2. Passare a una delle Versioni di Node.js supportate nella versione 4.x.

3. Aggiungere gli elementi version e extensionBundle al file host.json, in modo l’aspetto sia simile all'esempio seguente:

   {
       "version": "2.0",
       "extensionBundle": {
           "id": "Microsoft.Azure.Functions.ExtensionBundle",
           "version": "[3.3.0, 4.0.0)"
       }
   }
   

   L'elemento extensionBundle è necessario perché dopo la versione 1.x, le associazioni vengono mantenute come pacchetti esterni. Per altre informazioni, vedere Bundle di estensioni.

4. Aggiornare il file local.settings.json in modo che contenga almeno gli elementi seguenti:

   {
       "IsEncrypted": false,
       "Values": {
           "AzureWebJobsStorage": "UseDevelopmentStorage=true",
           "FUNCTIONS_WORKER_RUNTIME": "node"
       }
   }
   

   L'impostazione AzureWebJobsStorage può essere l'emulatore di archiviazione Azurite o un account di archiviazione di Azure effettivo. Per altre informazioni, vedere Emulatore di archiviazione locale.

Aggiornare un'app per le funzioni in Azure

È necessario aggiornare il runtime dell'host dell'app per le funzioni in Azure alla versione 4.x prima di pubblicare il progetto migrato. La versione di runtime usata dall'host funzioni è controllata dall'impostazione dell'applicazione FUNCTIONS_EXTENSION_VERSION, ma in alcuni casi è necessario aggiornare anche altre impostazioni. Sia le modifiche al codice che le modifiche apportate alle impostazioni dell'applicazione richiedono il riavvio dell'app per le funzioni.

Il modo più semplice consiste nell’aggiornamento senza slot e nella ripubblicazione del progetto dell'app. È anche possibile ridurre al minimo il tempo di inattività nell'app e semplificare il rollback mediante l’aggiornamento tramite slot.

Aggiornare senza slot

Il modo più semplice per eseguire l'aggiornamento a v4.x consiste nel configurare l'impostazione dell'applicazione FUNCTIONS_EXTENSION_VERSION su ~4 nell'app per le funzioni in Azure. È necessario seguire una procedura diversa in un sito con slot.

az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

Update-AzFunctionAppSetting -AppSetting @{"FUNCTIONS_EXTENSION_VERSION" = "~4"} -Name <APP_NAME> -ResourceGroupName <RESOURCE_GROUP_NAME> -Force

È necessario anche configurare un'altra impostazione, che varia tra Windows e Linux.

az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

Set-AzWebApp -NetFrameworkVersion v6.0 -Name <APP_NAME> -ResourceGroupName <RESOURCE_GROUP_NAME>

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "DOTNET|6.0"

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Java|11"

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Node|16"

az functionapp config set --name <APP_NAME> --resource-group <RESOURCE_GROUP_NAME> --linux-fx-version "Python|3.9"

In questo esempio, sostituire <APP_NAME> e <RESOURCE_GROUP_NAME> rispettivamente con il nome dell'app per le funzioni e il nome del gruppo di risorse.

A questo punto, è possibile ripubblicare il progetto dell'app di cui è stata eseguita la migrazione per l'esecuzione nella versione 4.x.

Aggiornamento tramite slot

L'uso di slot di distribuzione rappresenta una scelta efficace per aggiornare l'app per le funzioni al runtime v4.x da una versione precedente. Usando uno slot di staging, è possibile eseguire l'app nella nuova versione del runtime nello slot di staging e passare alla produzione dopo la verifica. Gli slot consentono anche di ridurre al minimo i tempi di inattività durante l'aggiornamento. Se è necessario ridurre al minimo i tempi di inattività, seguire la procedura descritta in Aggiornamento con il minimo tempo di inattività.

Dopo aver verificato l'app nello slot aggiornato, è possibile scambiare l'app e le nuove impostazioni della versione nell'ambiente di produzione. Questo scambio richiede l'impostazione WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 nello slot di produzione. La modalità con cui viene aggiunta questa impostazione influisce sul tempo di inattività necessario per l'aggiornamento.

Aggiornamento standard

Se l'app per le funzioni abilitata per slot può gestire il tempo di inattività di un riavvio completo, è possibile aggiornare l'impostazione WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS direttamente nello slot di produzione. Poiché la modifica di questa impostazione direttamente nello slot di produzione causa un riavvio che influisce sulla disponibilità, considerare l'esecuzione di questa modifica in periodi di traffico ridotto. A questo punto, è possibile scambiare la versione aggiornata dallo slot di staging.

Il cmdlet PowerShell Update-AzFunctionAppSetting attualmente non supporta gli slot. È necessario usare l'interfaccia della riga di comando di Azure o il portale di Azure.

1. Usare il comando seguente per impostare WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 nello slot di produzione:

   az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> 
   

   In questo esempio, sostituire <APP_NAME> e <RESOURCE_GROUP_NAME> rispettivamente con il nome dell'app per le funzioni e il nome del gruppo di risorse. Questo comando causa il riavvio dell'app in esecuzione nello slot di produzione.

2. Usare il comando seguente per impostare anche WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS nello slot di staging:

   az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
   

3. Usare il comando seguente per modificare FUNCTIONS_EXTENSION_VERSION e aggiornare lo slot di staging alla nuova versione del runtime:

   az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
   

4. La versione 4.x del runtime di Funzioni richiede .NET 6 in Windows. In Linux, le app .NET devono anche eseguire l'aggiornamento a .NET 6. Usare il comando seguente in modo che il runtime possa essere eseguito in .NET 6:

   • Windows
   • Linux

   Con l’esecuzione in Windows, è necessario anche abilitare .NET 6.0, richiesto dalla versione 4.x del runtime.

   az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
   

   .NET 6 è necessario per le app per le funzioni in qualunque linguaggio in esecuzione in Windows.

   In questo esempio, sostituire <APP_NAME> e <RESOURCE_GROUP_NAME> rispettivamente con il nome dell'app per le funzioni e il nome del gruppo di risorse.

5. Se il progetto del codice richiede aggiornamenti per l'esecuzione nella versione 4.x, distribuire ora tali aggiornamenti nello slot di staging.

6. Accertarsi che l'app per le funzioni venga eseguita correttamente nell'ambiente di staging aggiornato prima dello scambio.

7. Usare il comando seguente per scambiare lo slot di staging aggiornato in produzione:

   az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
   

Aggiornamento con il minimo tempo di inattività

Per ridurre al minimo il tempo di inattività nell'app di produzione, è possibile scambiare l'impostazione WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS dallo slot di staging in produzione. Successivamente, è possibile scambiare la versione aggiornata da uno slot di staging preriscaldato.

1. Usare il comando seguente per impostare WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 nello slot di staging:

   az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
   

2. Usare i comandi seguenti per scambiare lo slot con la nuova impostazione nell'ambiente di produzione e ripristinare contemporaneamente l'impostazione della versione nello slot di staging.

   az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
   az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
   

   È possibile che vengano visualizzati errori nello slot di staging durante il periodo di tempo tra lo scambio e la versione del runtime da ripristinare in staging. Questo errore può verificarsi perché la presenza di WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 solo in staging durante uno scambio rimuove l'impostazione FUNCTIONS_EXTENSION_VERSION in staging. Senza l'impostazione della versione, lo slot è in uno stato non valido. L'aggiornamento della versione nello slot di staging subito dopo lo scambio dovrebbe riportare lo slot in uno stato valido e chiamare il rollback delle modifiche, se necessario. Tuttavia, qualunque rollback dello scambio richiede anche la rimozione diretta di WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 dalla produzione prima dello scambio, per evitare che gli errori in staging si ripresentino in produzione. Questa modifica nell'impostazione di produzione causa un riavvio.

3. Usare il comando seguente per impostare nuovamente WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 nello slot di staging:

   az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
   

   A questo punto, entrambi gli slot hanno WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 impostato.

4. Usare il comando seguente per modificare FUNCTIONS_EXTENSION_VERSION e aggiornare lo slot di staging alla nuova versione del runtime:

   az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
   

5. La versione 4.x del runtime di Funzioni richiede .NET 6 in Windows. In Linux, le app .NET devono anche eseguire l'aggiornamento a .NET 6. Usare il comando seguente in modo che il runtime possa essere eseguito in .NET 6:

   • Windows
   • Linux

   Con l’esecuzione in Windows, è necessario anche abilitare .NET 6.0, richiesto dalla versione 4.x del runtime.

   az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
   

   .NET 6 è necessario per le app per le funzioni in qualunque linguaggio in esecuzione in Windows.

   In questo esempio, sostituire <APP_NAME> e <RESOURCE_GROUP_NAME> rispettivamente con il nome dell'app per le funzioni e il nome del gruppo di risorse.

6. Se il progetto del codice richiede aggiornamenti per l'esecuzione nella versione 4.x, distribuire ora tali aggiornamenti nello slot di staging.

7. Accertarsi che l'app per le funzioni venga eseguita correttamente nell'ambiente di staging aggiornato prima dello scambio.

8. Usare il comando seguente per scambiare lo slot di staging aggiornato e preriscaldato in produzione:

   az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production