Condividi tramite

Eseguire la migrazione di app .NET dal modello in-process al modello di lavoro isolato

  • Articolo

Importante

Il supporto terminerà per il modello in-process il 10 novembre 2026. È preferibile eseguire la migrazione delle app al modello di lavoro isolato seguendo le istruzioni riportate in questo articolo.

Questo articolo illustra il processo di migrazione sicura dell'app per le funzioni .NET dal modello in-process al modello di lavoro isolato. Per informazioni sulle differenze generali tra questi modelli, vedere il confronto tra la modalità di esecuzione.

Questa guida presuppone che l'app sia in esecuzione nella versione 4.x del runtime di Funzioni. Altrimenti, è consigliabile seguire le guide per aggiornare la versione host:

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

Identificare le app per le funzioni di cui eseguire la migrazione

Usare lo script di Azure PowerShell seguente per generare un elenco di app per le funzioni nella sottoscrizione che attualmente usano il modello in-process.

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

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.Runtime -eq 'dotnet')
     {
          $AppInfo.Add($App.Name, $App.Runtime)
     }
}

$AppInfo

Scegliere la versione di .NET di destinazione

Nella versione 4.x del runtime di Funzioni, l'app per le funzioni .NET è destinata a .NET 6 quando si usa il modello in-process.

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

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 come destinazione con il modello in-process non è ancora abilitata per Linux o per app in 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. In questo modo viene fornito un percorso di migrazione rapido alla versione completamente rilasciata con la finestra di supporto più lunga di .NET.

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

Preparare la migrazione

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

Prima di eseguire la migrazione di un'app al modello di lavoro isolato, è necessario esaminare attentamente il contenuto di questa guida e acquisire familiarità con le funzionalità del modello di lavoro isolato e le differenze tra i due modelli.

Per eseguire la migrazione dell'applicazione, è necessario:

  1. Completare i passaggi descritti in Eseguire la migrazione di un progetto locale per eseguire la migrazione di un progetto locale al modello di lavoro isolato.
  2. Dopo la migrazione del progetto, testare l'app in locale usando la versione 4.x di Azure Functions Core Tools.
  3. Aggiornare l'app per le funzioni in Azure al modello isolato.

Eseguire la migrazione di un progetto locale

La sezione descrive le varie modifiche che è necessario apportare al progetto locale per spostarlo nel modello di lavoro isolato. Alcuni passaggi cambiano in base alla versione di destinazione di .NET. Usare le schede per selezionare le istruzioni corrispondenti alla versione desiderata. Questi passaggi presuppongono un progetto C# locale; se l'app, invece, usa script C# (file .csx), è necessaria la conversione al modello di progetto prima di continuare.

Suggerimento

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

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

File di progetto

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

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Utilizzare una delle procedure seguenti per aggiornare questo file XML da eseguire nel modello di lavoro isolato:

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>

La modifica del framework di destinazione del progetto potrebbe richiedere anche modifiche a parti della toolchain, esternamente al codice del progetto. Ad esempio, in VS Code potrebbe essere necessario aggiornare l'impostazione dell'estensione azureFunctions.deploySubpath tramite le impostazioni utente o il file .vscode/settings.json del progetto. Verificare la presenza di eventuali dipendenze dalla versione del framework che possono esistere al di fuori del codice del progetto, come parte dei passaggi di compilazione o di una pipeline CI/CD.

Riferimenti ai pacchetti

Quando si esegue la migrazione al modello di lavoro isolato, è necessario modificare i pacchetti a cui fa riferimento l'applicazione.

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

A seconda dei trigger e delle associazioni usate dall'app, l'app potrebbe dover fare riferimento a un set diverso di pacchetti. La tabella seguente illustra le sostituzioni per alcune delle estensioni più usate:

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.Queues 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.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
Associazioni 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 un file Program.cs al progetto con il contenuto seguente:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

Questo esempio include l'integrazione di ASP.NET 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 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.

Modifiche alla firma della funzione

Alcuni tipi di chiave cambiano tra il modello in-process e il modello di lavoro isolato. Molti di questi sono correlati agli attributi, ai parametri e ai tipi restituiti che costituiscono la firma della funzione. Per ognuna delle funzioni, è necessario apportare modifiche a:

  • Attributo della funzione (che imposta anche il nome della funzione)
  • Modo in cui la funzione ottiene un ILogger/ILogger<T>
  • Attributi e parametri di trigger e associazione

La parte restante di questa sezione illustra ognuno di questi passaggi.

Attributi di funzioni

L'attributo FunctionName viene sostituito dall'attributo Function nel modello di lavoro isolato. Il nuovo attributo ha la stessa firma e l'unica differenza è nel nome. È quindi possibile eseguire semplicemente una sostituzione di stringhe nel progetto.

Registrazione

Nel modello in-process è possibile includere un parametro ILogger aggiuntivo per la funzione oppure usare l'inserimento delle dipendenze per ottenere un oggetto ILogger<T>. Se si usa già l'inserimento delle dipendenze, gli stessi meccanismi funzionano nel modello di lavoro isolato.

Tuttavia, per qualsiasi funzione basata sul parametro del metodo ILogger, sarà necessario apportare una modifica. È consigliabile usare l'inserimento delle dipendenze per ottenere un oggetto ILogger<T>. Per eseguire la migrazione del meccanismo di registrazione della funzione, seguire questa procedura:

  1. Nella classe della funzione aggiungere una proprietà private readonly ILogger<MyFunction> _logger;, sostituendo MyFunction con il nome della classe della funzione.

  2. Creare un costruttore per la classe di funzione che accetta ILogger<T> come parametro:

    public MyFunction(ILogger<MyFunction> logger) {
    _logger = logger;
}

    Sostituire entrambe le istanze di MyFunction nel frammento di codice precedente con il nome della classe della funzione.

  3. Per le operazioni di registrazione nel codice della funzione, sostituire i riferimenti al parametro ILogger con _logger.

  4. Rimuovere il parametro ILogger dalla firma della funzione.

Per altre informazioni, vedere Registrazione nel modello di lavoro isolato.

Modifiche al trigger e all'associazione

Quando sono stati modificati i riferimenti al pacchetto in un passaggio precedente, sono stati introdotti errori per i trigger e le associazioni che ora verranno risolti:

  1. Rimuovere tutte le istruzioni using Microsoft.Azure.WebJobs;.

  2. Aggiungere un'istruzione using Microsoft.Azure.Functions.Worker;.

  3. Per ogni attributo di associazione, modificare il nome dell'attributo come specificato nella relativa documentazione di riferimento, disponibile nell'indice Associazioni supportate. In generale, i nomi degli attributi cambiano nel modo seguente:

    • I trigger rimangono in genere denominati allo stesso modo. Ad esempio, QueueTrigger è il nome dell'attributo per entrambi i modelli.
    • Le associazioni di input richiedono in genere l'aggiunta di "Input" al nome. Ad esempio, se è stato usato l'attributo di associazione di input CosmosDB nel modello in-process, questo sarà CosmosDBInput.
    • Le associazioni di output richiedono in genere l'aggiunta di "Output" al nome. Ad esempio, se è stato usato l'attributo di associazione di output Queue nel modello in-process, questo sarà QueueOutput.

  4. Aggiornare i parametri dell'attributo in modo che riflettano la versione del modello di lavoro isolato, come specificato nella documentazione di riferimento dell'associazione.

    Nel modello in-process, ad esempio, un'associazione di output BLOB è rappresentata da un attributo [Blob(...)] che include una proprietà Access. Nel modello di lavoro isolato l'attributo di output BLOB sarà [BlobOutput(...)]. L'associazione non richiede più la proprietà Access, quindi il parametro può essere rimosso. Perciò [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] diventerà [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

  5. Spostare le associazioni di output dall'elenco dei parametri della funzione. Se si dispone di una sola associazione di output, è possibile applicarla al tipo restituito della funzione. Se sono presenti più output, creare una nuova classe con proprietà per ogni output e applicare gli attributi a tali proprietà. Per altre informazioni, vedere Associazioni di output multipli.

  6. Consultare la documentazione di riferimento di ogni associazione per i tipi a cui è consentita l'associazione. In alcuni casi, potrebbe essere necessario modificare il tipo. Per le associazioni di output, se la versione del modello in-process ha usato un oggetto IAsyncCollector<T>, è possibile sostituirla con l'associazione a una matrice del tipo di destinazione: T[]. È anche possibile sostituire l'associazione di output con un oggetto client per il servizio rappresentato, come tipo di associazione per un'associazione di input, se disponibile, o inserendo manualmente un client.

  7. Se la funzione include un parametro IBinder, rimuoverlo. Sostituire la funzionalità con un oggetto client per il servizio rappresentato, come tipo di associazione per un'associazione di input, se disponibile, o inserendo manualmente un client.

  8. Aggiornare il codice della funzione in modo che funzioni con qualsiasi nuovo tipo.

File local.settings.json

Il file local.settings.json è utilizzato solo con l'esecuzione in locale. Per informazioni, vedere File di impostazioni locali.

Quando si esegue la migrazione dall'esecuzione In-Process all'esecuzione in un processo di lavoro isolato, è necessario modificare il valore FUNCTIONS_WORKER_RUNTIME in "dotnet-isolated". Assicurarsi che il file local.settings.json contenga almeno gli elementi seguenti:

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

Il valore configurato per "AzureWebJobsStorage" potrebbe essere diverso. Non è necessario modificarne il valore come parte della migrazione.

File host.json

Non sono necessarie modifiche al file host.json. Tuttavia, se la configurazione di Application Insights è contenuta in questo file dal progetto di modello in-process, può essere necessario apportare modifiche aggiuntive nel file Program.cs. Il file host.json controlla solo la registrazione dal runtime dell'host di Funzioni e nel modello di lavoro isolato alcuni di questi log provengono direttamente dall'applicazione, offrendo un maggiore controllo. Per informazioni dettagliate su come filtrare questi log, vedere Gestione dei livelli di log nel modello di lavoro isolato.

Altre modifiche al codice

In questa sezione vengono evidenziate altre modifiche al codice da considerare durante l'esecuzione della migrazione. Queste modifiche non sono necessarie per tutte le applicazioni, ma è preferibile valutare se sono pertinenti per gli scenari in uso.

Serializzazione JSON

Per impostazione predefinita, il modello di lavoro isolato usa System.Text.Json per la serializzazione JSON. Per personalizzare le opzioni del serializzatore o passare a JSON.NET (Newtonsoft.Json), vedere queste istruzioni.

Filtri e livelli di log di Application Insights

I log possono essere inviati ad Application Insights sia dal runtime dell'host di Funzioni che dal codice nel progetto. host.json consente di configurare regole per la registrazione dell'host, ma per controllare i log provenienti dal codice è necessario configurare regole di filtro come parte di Program.cs. Per informazioni dettagliate su come filtrare questi log, vedere Gestione dei livelli di log nel modello di lavoro isolato.

Migrazioni di funzioni di esempio

Esempio di trigger HTTP

Un trigger HTTP per il modello in-process potrebbe essere simile all'esempio seguente:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

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

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Un trigger HTTP per la versione migrata potrebbe essere simile all'esempio seguente:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

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

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = logger;
        }

        [Function("HttpTriggerCSharp")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Aggiornare un'app per le funzioni in Azure

L'aggiornamento dell'app per le funzioni al modello isolato è costituito da due passaggi:

  1. Modificare la configurazione dell'app per le funzioni per usare il modello isolato impostando l'impostazione dell'applicazione FUNCTIONS_WORKER_RUNTIME su dotnet-isolated. Assicurarsi che qualsiasi automazione della distribuzione venga aggiornata in modo analogo.
  2. Pubblicare il progetto migrato nell'app per le funzioni aggiornata.

Quando si usa Visual Studio per pubblicare un progetto di modello di lavoro isolato in un'app per le funzioni esistente che usa il modello in-process, viene richiesto di consentire a Visual Studio di aggiornare l'app per le funzioni durante la distribuzione. Questa operazione esegue entrambi i passaggi contemporaneamente.

Se è necessario ridurre al minimo il tempo di inattività, considerare l'uso di uno slot di staging per testare e verificare il codice migrato con la configurazione aggiornata in Azure. È quindi possibile distribuire l'app completamente migrata nello slot di produzione tramite un'operazione di scambio.

Dopo aver completato questi passaggi, l'app è stata completamente migrata al modello isolato. Complimenti. Ripetere i passaggi di questa guida in base alle esigenze per qualsiasi altra app che richiede la migrazione.

Passaggi successivi

Altre informazioni sul modello di lavoro isolato