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. È consigliabile 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 confronto tra la modalità di esecuzione.

Questa guida presuppone che l'app sia in esecuzione nella versione 4.x del runtime di Funzioni. In caso contrario, è 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 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 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. 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 specificare come destinazione queste versioni, è possibile adattare gli esempi di .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 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 del progetto locale per eseguire la migrazione del progetto locale al modello di lavoro isolato.
  2. Dopo la migrazione del progetto, testare completamente l'app in locale usando la versione 4.x di Funzioni di Azure Core Tools.
  3. Aggiornare l'app per le funzioni in Azure al modello isolato.

Eseguire la migrazione del 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 e, se l'app usa invece script C# (.csx file), è necessario eseguire la conversione nel modello di progetto prima di continuare.

Suggerimento

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

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

File di progetto

L'esempio seguente è un .csproj file di progetto 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 il file XML da eseguire nel modello di lavoro isolato:

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>

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 è 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 un Program.cs file 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 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.

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)
  • Come 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 aggiuntivo ILogger 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 ILogger metodo, 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 private readonly ILogger<MyFunction> _logger; proprietà, 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 nel frammento di MyFunction codice precedente con il nome della classe della funzione.

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

  4. Rimuovere il ILogger parametro 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 verranno risolti:

  1. Rimuovere eventuali using Microsoft.Azure.WebJobs; istruzioni.

  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 Binding supportati . 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 CosmosDB di associazione di input nel modello in-process, questo sarà CosmosDBInputora .
    • Le associazioni di output richiedono in genere l'aggiunta di "Output" al nome. Ad esempio, se è stato usato l'attributo di Queue associazione di output nel modello in-process, questo sarà QueueOutputora .

  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 [Blob(...)] attributo che include una Access proprietà. Nel modello di lavoro isolato l'attributo di output del BLOB sarà [BlobOutput(...)]. L'associazione non richiede più la Access proprietà , in modo che il parametro possa essere rimosso. Quindi [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] sarebbe diventato [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

  5. Spostare le associazioni di output dall'elenco dei parametri della funzione. Se si dispone di un solo binding di output, è possibile applicarlo 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 Più associazioni di output.

  6. Consultare la documentazione di riferimento di ogni associazione per i tipi a cui è possibile eseguire 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 IAsyncCollector<T>oggetto , è 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 IBinder parametro, 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.

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 dall'esecuzione in-process all'esecuzione in un processo di lavoro isolato, è necessario modificare il FUNCTIONS_WORKER_RUNTIME valore in "dotnet-isolated". Assicurarsi che il file local.settings.json abbia almeno gli elementi seguenti:

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

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

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.

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.

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.

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 l'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 i tempi di inattività, è consigliabile usare 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 di qualsiasi altra app che richiede la migrazione.

Passaggi successivi

Altre informazioni sul modello di lavoro isolato