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 di runtime di Funzioni, vedere Funzioni di Azure panoramica delle versioni di runtime.

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 versione dei criteri di supporto ufficiale di .NET Modello di processodi Funzioni 1,3
.NET 82 LTS Modello di lavoro isolato
.NET 7 STS (fine del supporto 14 maggio 2024) Modello di lavoro isolato
.NET 6 LTS (fine del supporto 12 novembre 2024) Modello di lavoro isolato,
Modello in-process3
.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 Standard Term Support (STS) di .NET, oltre a .NET Framework. Il modello in-process supporta solo le versioni LTS di .NET. Per un confronto completo di funzionalità e funzionalità tra i due modelli, vedere Differenze tra processi in-process e isolare il processo di lavoro .NET Funzioni di Azure.

2 .NET 8 non è ancora supportato nel modello in-process, anche se è disponibile nel modello di lavoro isolato. Per informazioni sui piani .NET 8, incluse le opzioni future per il modello in-process, vedere il post relativo all'aggiornamento della roadmap Funzioni di Azure.

3 Il supporto termina per il modello in-process il 10 novembre 2026. Per altre informazioni, vedere questo annuncio di supporto. Per un supporto completo continuo, è consigliabile eseguire la migrazione delle app al modello di lavoro isolato.

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 di .NET.

Sebbene sia possibile scegliere di usare invece il modello in-process, questo non è consigliato se può essere evitato. Il supporto terminerà per il modello in-process il 10 novembre 2026, quindi sarà necessario passare al modello di lavoro isolato prima di allora. In questo modo, durante la migrazione alla versione 4.x, si ridurrà il lavoro totale richiesto e il modello di lavoro isolato offrirà all'app vantaggi aggiuntivi, inclusa la possibilità di usare versioni future di .NET con maggiore facilità. Se si passa al modello di lavoro isolato, . NET Upgrade Assistant può anche gestire molte delle modifiche di codice necessarie.

Questa guida non presenta esempi specifici per .NET 7 o .NET 6 nel modello di lavoro isolato. Se è necessario specificare come destinazione queste versioni, è possibile adattare gli esempi di modelli di lavoro isolati .NET 8.

Preparare la migrazione

Se non è già stato fatto, identificare l'elenco di app di cui è necessario eseguire la migrazione nella sottoscrizione di Azure corrente usando 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 del progetto locale per eseguire la migrazione del progetto locale alla versione 4.x.
  3. Dopo la migrazione del progetto, testare completamente l'app in locale usando la versione 4.x di Funzioni di Azure 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 i tempi di inattività, è consigliabile usare uno slot di staging per testare e verificare l'app migrata in Azure nella nuova versione di runtime. È quindi possibile distribuire l'app con le impostazioni di versione aggiornate nello slot di produzione. Per altre informazioni, vedere Aggiornare usando gli 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 in una versione precedente, viene richiesto 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 Update senza slot.

Eseguire la migrazione del 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 .NET Upgrade Assistant per apportare automaticamente molte delle modifiche indicate nelle sezioni seguenti.

File di progetto

L'esempio seguente è un .csproj file di progetto 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 il file XML da eseguire in Funzioni versione 4.x:

Questi passaggi presuppongono un progetto C# locale e, se l'app usa invece script C# (.csx file), è necessario eseguire la conversione nel modello di progetto prima di continuare.

Nel file di .csproj progetto XML sono necessarie 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 seguente OutputType a PropertyGroup:

    <OutputType>Exe</OutputType>

  4. ItemGroupIn .PackageReference list, 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 Microsoft.Azure.WebJobs.* spazi dei nomi. Questi pacchetti verranno sostituiti in un passaggio successivo.

  5. Aggiungere il nuovo elemento ItemGroupseguente:

    <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 sulle using istruzioni negli esempi di modelli di trigger HTTP più avanti in questo articolo.

Se non è già stato 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 Aggiungi
Microsoft.Azure.Functions.Worker.Extensions.Timer
Associazioni di archiviazione Sostituzione
Microsoft.Azure.WebJobs.Extensions.Storage
con
Microsoft.Azure.Functions.Worker.Extensions. Archiviazione. BLOB,
Microsoft.Azure.Functions.Worker.Extensions. Archiviazione. Code e
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. Archiviazione. Blob
Associazioni di code Sostituire i riferimenti a
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
con la versione più recente di
Microsoft.Azure.Functions.Worker.Extensions. Archiviazione. Code
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
configurazione di avvio e avvio		 Rimuovere i riferimenti a
Microsoft.Azure.Functions.Extensions
Il modello di lavoro isolato fornisce questa funzionalità per impostazione predefinita.

Vedere Binding supportati per un elenco completo delle estensioni da considerare e consultare la documentazione di ogni estensione per istruzioni complete sull'installazione per il modello di processo isolato. Assicurarsi di installare la versione stabile più recente di tutti i pacchetti di destinazione.

Suggerimento

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

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

Suggerimento

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

Program.cs file

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 ASP.NET'integrazione core 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 questo 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, è consigliabile mantenere per FrameworkReference ASP.NET Core.

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

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

Sebbene sia possibile registrare origini di configurazione personalizzate come parte di HostBuilder, si noti che si applicano in modo analogo solo al codice nel progetto. La configurazione dei trigger e dell'associazione è necessaria anche per la piattaforma e deve essere fornita tramite le impostazioni dell'applicazione, i riferimenti a Key Vault o Configurazione app funzionalità di riferimento.

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

local.settings.json file

Il file local.settings.json viene usato solo durante 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 abbia 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 FUNCTIONS_WORKER_RUNTIME valore in "dotnet-isolated".

host.json file

Non sono necessarie modifiche al host.json file. Tuttavia, se la configurazione di Application Insights in questo file dal progetto di modello in-process può essere necessario apportare modifiche aggiuntive nel Program.cs file. Il host.json file 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 al 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 di ASP.NET Core)
IActionResult HttpResponseData HttpResponseData, IActionResult (usando l'integrazione di ASP.NET Core)
FunctionsStartup (attributo) Program.cs Usa invece Program.cs Usa invece

Potrebbero verificarsi anche differenze tra i nomi delle classi 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 è consigliabile valutare se sono rilevanti 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.

Livelli e filtri dei 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 le regole per la registrazione dell'host, ma per controllare i log provenienti dal codice, è necessario configurare le 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 a Funzioni di Azure 4.x:

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

  2. Aggiornare il bundle delle estensioni Funzioni di Azure dell'app alla versione 2.x o successiva. Per altre informazioni, vedere Modifiche di rilievo.

  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 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. Nella portale di Azure passare all'app per le funzioni.

  2. Aprire la pagina Diagnostica e risolvere 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 Funzioni di Azure Core Tools v4 o usando uno slot di staging.

Aggiornare l'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'aggiornare senza slot e quindi ripubblicare il progetto dell'app. È anche possibile ridurre al minimo i tempi di inattività nell'app e semplificare il rollback aggiornando gli slot.

Aggiornare senza slot

Il modo più semplice per eseguire l'aggiornamento a v4.x consiste nell'impostare l'impostazione ~4 dell'applicazione su nell'app per le FUNCTIONS_EXTENSION_VERSION 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>

È anche necessario impostare un'altra impostazione, che differisce tra Windows e Linux.

Quando si esegue in Windows, è anche necessario 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 qualsiasi linguaggio in esecuzione in Windows.

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

È ora possibile ripubblicare il progetto dell'app di cui è stata eseguita la migrazione per l'esecuzione nella versione 4.x.

Aggiornare usando gli slot

L'uso degli slot di distribuzione è un buon modo 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 di 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 tempo di inattività minimo.

Dopo aver verificato l'app nello slot aggiornato, puoi 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à di aggiunta di questa impostazione influisce sulla quantità di 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à, prendere in considerazione l'esecuzione di questa modifica al momento della riduzione del traffico. È quindi possibile scambiare la versione aggiornata dallo slot di staging.

Il Update-AzFunctionAppSetting cmdlet di PowerShell 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> con il nome dell'app per le funzioni e <RESOURCE_GROUP_NAME> con il nome del gruppo di risorse. Questo comando causa il riavvio dell'app nello slot di produzione.

  2. Usare il comando seguente per impostare WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS anche 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 di 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:

    Quando si esegue in Windows, è anche necessario 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 qualsiasi linguaggio in esecuzione in Windows.

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

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

  6. Verificare 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 nell'ambiente di produzione:

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

Aggiornamento 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 nell'ambiente di produzione. Successivamente, è possibile scambiare la versione aggiornata da uno slot di staging preavviso.

  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 di runtime da ripristinare durante la gestione temporanea. Questo errore può verificarsi perché la presenza WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 di staging solo durante uno scambio rimuove l'impostazione FUNCTIONS_EXTENSION_VERSION nella gestione temporanea. 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, qualsiasi rollback dello scambio richiede anche la rimozione WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 diretta dall'ambiente di produzione prima dello scambio per evitare gli stessi errori nell'ambiente di produzione visualizzato nella gestione temporanea. Questa modifica nell'impostazione di produzione provocherebbe quindi un riavvio.

  3. Usare di nuovo il comando seguente per impostare WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 di nuovo 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 sono stati WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 impostati.

  4. Usare il comando seguente per modificare FUNCTIONS_EXTENSION_VERSION e aggiornare lo slot di staging alla nuova versione di 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:

    Quando si esegue in Windows, è anche necessario 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 qualsiasi linguaggio in esecuzione in Windows.

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

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

  7. Verificare 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 preavviso nell'ambiente di 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 Funzioni di Azure problemi di GitHub con etichetta Modifica di rilievo: approvata.

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

esecuzione

  • Funzioni di Azure Proxy è 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. Appena possibile, è consigliabile passare all'integrazione delle app per le funzioni con Azure Gestione API. 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 Gestione API. Per informazioni su come riabilitare il supporto dei proxy in Funzioni versione 4.x, vedere Riabilitare i proxy in Funzioni v4.x.

  • La registrazione per Archiviazione di Azure con AzureWebJobsDashboard non è più supportata nella versione 4.x. È invece consigliabile usare Application Insights. (#1923)

  • Funzioni di Azure 4.x applica ora i requisiti minimi di versione 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 vengono avviate 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 sulle versioni di Funzioni