Condividi tramite

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

  • Articolo

Funzioni di Azure versione 4.x è altamente compatibile con le versioni precedenti alla versione 3.x. La maggior parte delle app deve eseguire la migrazione sicura a 4.x senza richiedere modifiche significative al codice. Per altre informazioni sulle versioni del runtime di Funzioni, vedere Panoramica delle versioni del runtime per Funzioni di Azure.

Importante

A partire dal 13 dicembre 2022, le app per le funzioni in esecuzione nelle versioni 2.x e 3.x del runtime di Funzioni di Azure hanno raggiunto la fine del supporto “Extended”. Per altre informazioni, vedere Versioni ritirata.

Questo articolo illustra il processo di migrazione sicura dell'app per le funzioni da eseguire nella versione 4.x del runtime di Funzioni. Poiché le istruzioni di migrazione del progetto dipendono dal linguaggio, assicurarsi di scegliere il linguaggio di sviluppo dal selettore nella parte superiore dell'articolo.

Identificare le app per le funzioni di cui eseguire la migrazione

Usare lo script di PowerShell seguente per generare un elenco di app per le funzioni nella sottoscrizione che attualmente sono destinate alle versioni 2.x o 3.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 '*3*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

Scegliere la versione di .NET di destinazione

Nella versione 3.x del runtime di Funzioni, l'app per le funzioni C# è destinata a .NET Core 3.1 usando il modello in-process o .NET 5 usando il modello di lavoro isolato.

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:

Versione di .NET Tipo di rilascio Criteri di supporto ufficiali di .NET Modello di processo di Funzioni1,2
.NET 8 LTS (fine del supporto 10 novembre 2026) Modello di lavoro isolato,
Modello In-Process2,3
.NET 6 LTS (fine del supporto 12 novembre 2024) Modello di lavoro isolato,
Modello In-Process2
.NET Framework 4.8 Vedere i criteri Modello di lavoro isolato

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

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

3 La scelta di .NET 8 con il modello In-Process non è ancora abilitata per Linux, per le app ospitate in ambienti del servizio app o per le app nei cloud sovrani. Gli aggiornamenti verranno comunicati in questo thread di monitoraggio in GitHub.

Suggerimento

È consigliabile eseguire l'aggiornamento a .NET 8 nel modello di lavoro isolato. .NET 8 è la versione completamente rilasciata con la finestra di supporto più lunga da .NET.

Anche se si può scegliere di usare il modello In-Process, tale scelta è sconsigliata se può essere evitata. Il supporto per il modello In-Process terminerà il 10 novembre 2026, quindi sarà necessario passare al modello di lavoro isolato prima di tale data. In tal modo, durante la migrazione alla versione 4.x si ridurrà il lavoro totale richiesto e il modello di lavoro isolato offrirà all'app ulteriori vantaggi, inclusa la possibilità di scegliere più facilmente le versioni future di .NET. Se si passa al modello di lavoro isolato, Assistente aggiornamento .NET può anche gestire molte modifiche necessarie al codice.

Questa guida non presenta esempi specifici per .NET 6. Se è necessario scegliere tale versione, è 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 alla versione 4.x del runtime di Funzioni, è necessario eseguire le attività seguenti:

  1. Esaminare l'elenco delle modifiche di rilievo tra 3.x e 4.x.
  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. Eseguire il validator di pre-aggiornamento nell'app ospitata in Azure e risolvere eventuali problemi identificati.
  5. 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.
  6. 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 istruzioni di aggiornamento dipendono dalla lingua. Se la lingua non è visualizzata, selezionarla dal selettore nella parte superiore dell'articolo.

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

Suggerimento

Se si passa a una versione LTS o STS di .NET usando il modello di lavoro isolato, è possibile usare l’Assistente aggiornamento .NET per apportare automaticamente molte delle modifiche indicate nelle sezioni seguenti.

File di progetto

L'esempio seguente è un file di progetto .csproj che usa .NET Core 3.1 nella versione 3.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.13" />
  </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:

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.

Nel file di progetto XML .csproj è necessario apportare le modifiche seguenti:

  1. Impostare il valore di PropertyGroup.Da TargetFramework a net8.0.

  2. Impostare il valore di PropertyGroup.Da AzureFunctionsVersion a v4.

  3. Aggiungere l'elemento OutputType seguente a PropertyGroup:

    <OutputType>Exe</OutputType>

  4. Nel ItemGroup.PackageReference elenco, sostituire il riferimento al pacchetto a Microsoft.NET.Sdk.Functions con i riferimenti seguenti:

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

    Prendere nota di eventuali riferimenti ad altri pacchetti negli spazi dei nomi Microsoft.Azure.WebJobs.*. Questi pacchetti verranno sostituiti in un passaggio successivo.

  5. Aggiungere il nuovo ItemGroup seguente:

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

Dopo aver apportato queste modifiche, il progetto aggiornato sarà simile all'esempio seguente:

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

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.

Se non è stato ancora fatto, aggiornare il progetto per fare riferimento alle versioni stabili più recenti di:

A seconda dei trigger e dei binding usati 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:

Scenario Modifiche ai riferimenti ai pacchetti
Trigger timer Aggiunta
Microsoft.Azure.Functions.Worker.Extensions.Timer
Associazioni di archiviazione Sostituzione
Microsoft.Azure.WebJobs.Extensions.Storage
con
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queuese
Microsoft.Azure.Functions.Worker.Extensions.Tables
Associazioni di BLOB Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Associazioni di code Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Associazioni di tabelle Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.Tables
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.Tables
Associazioni di Cosmos DB Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.CosmosDB
e/o
Microsoft.Azure.WebJobs.Extensions.DocumentDB
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Associazioni di bus di servizio Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.ServiceBus
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Associazioni di Hub eventi Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.EventHubs
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Associazioni di Griglia di eventi Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.EventGrid
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Associazioni del Servizio SignalR Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.SignalRService
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Funzioni durevoli Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.DurableTask
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Funzioni durevoli
(provider di archiviazione SQL)		 Sostituire i riferimenti a
Microsoft.DurableTask.SqlServer.AzureFunctions
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Funzioni durevoli
(Provider di archiviazione Netherite)		 Sostituire i riferimenti a
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Associazioni SendGrid Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.SendGrid
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Associazioni Kafka Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.Kafka
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Binding RabbitMQ Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Inserimento delle dipendenze
e configurazione di avvio		 Rimuovere i riferimenti a
Microsoft.Azure.Functions.Extensions
(Il modello di lavoro isolato fornisce questa funzionalità per impostazione predefinita).

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.

Suggerimento

Eventuali modifiche alle versioni delle estensioni durante questo processo potrebbero richiedere anche l'aggiornamento del file host.json. Assicurarsi di leggere la documentazione di ogni estensione usata. Ad esempio, l'estensione del bus di servizio presenta modifiche di rilievo nella struttura tra le versioni 4.x e 5.x. Per altre informazioni, vedere Associazioni del bus di servizio di Azure per Funzioni di Azure.

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.

Suggerimento

L'app potrebbe anche dipendere da tipi Azure SDK, come parte dei trigger e delle associazioni o come dipendenza autonoma. È consigliabile sfruttare questa opportunità per aggiornare anche questi elementi. Le versioni più recenti delle estensioni di Funzioni funzionano con le versioni più recenti di Azure SDK per .NET, per le quali quasi tutti i pacchetti sono il modulo Azure.*.

File program.cs

Quando si esegue la migrazione per l'esecuzione in un processo di lavoro isolato, è necessario aggiungere il 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();

Questo esempio include l’integrazione di ASP.NETCore per migliorare le prestazioni e fornire un modello di programmazione familiare quando l'app usa trigger HTTP. Se non si intende usare trigger HTTP, è possibile sostituire la chiamata a ConfigureFunctionsWebApplication con una chiamata a ConfigureFunctionsWorkerDefaults. In tal caso, è possibile rimuovere il riferimento a Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore dal file di progetto. Tuttavia, per ottenere prestazioni ottimali anche per le funzioni con altri tipi di trigger, è preferibile mantenere FrameworkReference con ASP.NET Core.

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.

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

Nota

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

File host.json

Non sono necessarie modifiche al file host.json. Tuttavia, se la configurazione di Application Insights 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.

Modifiche del nome della classe

Alcune classi chiave modificano i nomi tra le versioni. Queste modifiche sono il risultato di una modifica delle API .NET o delle differenze tra processo in-process e processo di lavoro isolato. La tabella seguente indica le classi .NET chiave usate da Funzioni che potrebbero cambiare durante la migrazione:

.NET Core 3.1 .NET 5 .NET 8
FunctionName (attributo) Function (attributo) Function (attributo)
ILogger ILogger ILogger, ILogger<T>
HttpRequest HttpRequestData HttpRequestData, HttpRequest (usando l’integrazione ASP.NET Core)
IActionResult HttpResponseData HttpResponseData, IActionResult (usando l’integrazione ASP.NET Core)
FunctionsStartup (attributo) Usa invece Program.cs Usa invece Program.cs

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

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. Assicurarsi di controllare Modifiche di rilievo tra 3.x e 4.x per eventuali modifiche aggiuntive che potrebbe essere necessario apportare al progetto.

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.

Modello di trigger HTTP

Le differenze tra processo in-process e processo di lavoro isolato possono essere visualizzate nelle funzioni attivate da HTTP. Il modello di trigger HTTP per la versione 3.x (in-process) è simile all'esempio seguente:

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

Il modello di trigger HTTP per la versione migrata è 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"]}!");
        }
    }
}

Per aggiornare il progetto in Funzioni di Azure 4.x:

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

  2. Aggiornare il bundle estensioni di Funzioni di Azure alla versione 2.x o successiva. Per altre informazioni, vedere Modifiche di interruzione.

  1. Se necessario, passare a una delle versioni Java supportate nella versione 4.x.

  2. Aggiornare il file dell'app POM.xml per modificare l'impostazione di FUNCTIONS_EXTENSION_VERSION su ~4, come nell'esempio seguente:

    <configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~4</value>
        </property>
    </appSettings>
</configuration>
  1. Se necessario, passare a una delle versioni di Node.js supportate nella versione 4.x.
  1. È consigliabile eseguire l'aggiornamento a PowerShell 7.2. Per altre informazioni, vedere versioni di PowerShell.
  1. Se si usa Python 3.6, passare a una delle versioni supportate.

Eseguire il validator di pre-aggiornamento

Funzioni di Azure fornisce uno strumento di convalida di pre-aggiornamento per identificare potenziali problemi durante la migrazione dell'app per le funzioni alla versione 4.x. Per eseguire il validator di pre-aggiornamento:

  1. Nel portale di Azure passare all'app per le funzioni.

  2. Aprire la pagina Diagnostica e risolvi i problemi.

  3. In Diagnostica app per le funzioni iniziare a digitare Functions 4.x Pre-Upgrade Validator e quindi sceglierlo dall'elenco.

  4. Al termine della convalida, esaminare le raccomandazioni e risolvere eventuali problemi nell'app. Se è necessario apportare modifiche all'app, assicurarsi di convalidare le modifiche rispetto alla versione 4.x del runtime di Funzioni, in locale usando Azure Functions Core Tools v4 oppure usando uno slot di staging.

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>

È necessario anche configurare un'altra impostazione, che varia tra Windows e 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.

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:

    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:

    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

Modifiche di rilievo tra 3.x e 4.x

Di seguito sono riportate le principali modifiche di rilievo da tenere presenti prima di aggiornare un'app 3.x alla versione 4.x, incluse le modifiche di rilievo specifiche della lingua. Per un elenco completo, vedere Problemi di GitHub di Funzioni di Azure con etichetta Modifica di rilievo: approvata.

Se il linguaggio di programmazione non è visualizzato, selezionarlo nella parte superiore della pagina.

esecuzione

  • I proxy di Funzioni di Azure sono una funzionalità legacy per le versioni da 1.x a 3.x del runtime di Funzioni di Azure. Il supporto per i proxy di Funzioni può essere riabilitato nella versione 4.x in modo da poter aggiornare correttamente le app per le funzioni alla versione di runtime più recente. Non appena possibile, è consigliabile passare all'integrazione delle app per le funzioni con Gestione API di Azure. Gestione API consente di sfruttare un set di funzionalità più completo per definire, proteggere, gestire e monetizzare le API basate su Funzioni. Per altre informazioni, vedere Integrazione di Gestione API. Per informazioni su come riabilitare il supporto dei proxy in Funzioni versione 4.x, vedere Riabilitare i proxy in Funzioni v4.x.

  • L'accesso ad Archiviazione di Azure con AzureWebJobsDashboard non è più supportato nella versione 4.x. È invece consigliabile usare Application Insights. (#1923)

  • Funzioni di Azure 4.x applica ora requisiti di versione minimi per le estensioni. Eseguire l'aggiornamento alla versione più recente delle estensioni interessate. Per non-.NET lingue, eseguire l'aggiornamento al bundle di estensioni versione 2.x o successiva. (#1987)

  • I timeout predefiniti e massimi vengono ora applicati nella versione 4.x per le app per le funzioni in esecuzione in Linux in un piano a consumo. (#1915)

  • Funzioni di Azure 4.x usa Azure.Identity e Azure.Security.KeyVault.Secrets per il provider di Key Vault e ha deprecato l'uso di Microsoft.Azure.KeyVault. Per altre informazioni su come configurare le impostazioni dell'app per le funzioni, vedere l'opzione Key Vault in Repository segreti. (#2048)

  • Le app per le funzioni che condividono gli account di archiviazione ora non si avviano quando gli ID host sono gli stessi. Per altre informazioni, vedere Considerazioni sull'ID host. (#2049)

  • Funzioni di Azure 4.x supporta le app in-process e isolate di .NET 6.

  • InvalidHostServicesException è ora un errore irreversibile. (#2045)

  • EnableEnhancedScopes è abilitato per impostazione predefinita. (#1954)

  • Rimuovere HttpClient come servizio registrato. (#1911)

  • Usare un caricatore a classe singola in Java 11. (#1997)

  • Arrestare il caricamento dei file JAR del ruolo di lavoro in Java 8. (#1991)

  • Node.js versioni 10 e 12 non sono supportate in Funzioni di Azure 4.x. (#1999)

  • La serializzazione dell'output nelle app di Node.js è stata aggiornata per risolvere le incoerenze precedenti. (#2007)

  • Il numero di thread predefinito è stato aggiornato. Le funzioni che non sono thread-safe o che hanno un utilizzo elevato della memoria potrebbero essere interessate. (#1962)

  • Python 3.6 non è supportato in Funzioni di Azure 4.x. (#1999)

  • Il trasferimento di memoria condivisa è abilitato per impostazione predefinita. (#1973)

  • Il numero di thread predefinito è stato aggiornato. Le funzioni che non sono thread-safe o che hanno un utilizzo elevato della memoria potrebbero essere interessate. (#1962)

Passaggi successivi

Altre informazioni su Funzioni di Azure.