Migrer des applications .NET du modèle In-process vers le modèle de travail isolé

  • Article

Important

Le support prendra fin pour le modèle en cours le 10 novembre 2026.. Nous vous recommandons fortement de migrer vos applications vers le modèle de travailleur isolé en suivant les instructions de cet article.

Cet article vous guide tout au long du processus de migration sécurisée de votre application de fonction .NET du modèle In-process vers le modèle de travail isolé. Pour en savoir plus sur les différences de haut niveau entre ces modèles, consultez la comparaison des modes d’exécution.

Ce guide suppose que votre application s’exécute sur la version 4.x du runtime Functions. Si ce n’est pas le cas, suivez plutôt les guides pour mettre à niveau la version de votre hôte :

Ces guides de migration de la version de l’hôte vous aideront également à migrer vers le modèle de travail isolé à mesure que vous les utiliserez.

Identifier les applications de fonction à migrer

Utilisez le script Azure PowerShell suivant pour générer une liste d’applications de fonction dans votre abonnement qui utilisent actuellement le modèle In-process.

Le script utilise l’abonnement qu’Azure PowerShell est actuellement configuré pour utiliser. Vous pouvez modifier l’abonnement en exécutant Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' et en remplaçant <YOUR SUBSCRIPTION ID> par l’ID de l’abonnement que vous souhaitez évaluer.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

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

$AppInfo

Choisissez votre version cible de .NET

Sur la version 4.x du runtime Functions, votre application de fonction .NET cible .NET 6 lors de l’utilisation du modèle In-process.

Lorsque vous migrez votre application de fonction, vous avez la possibilité de choisir la version cible de .NET. Vous pouvez mettre à jour votre projet C# vers l’une des versions suivantes de .NET, qui sont prises en charge par Functions version 4.x :

Version de .NET Type de version de la politique de prise en charge officielle .NET Modèle de processus Functions1,3
.NET 82 LTS Modèle de worker isolé
.NET 7 STS (fin de la prise en charge le 14 mai 2024) Modèle de worker isolé
.NET 6 LTS (fin de la prise en charge le 12 novembre 2024) Modèle de worker isolé,
Modèle in-process3
.NET Framework 4.8 Consulter la stratégie Modèle de worker isolé

1 Le modèle de worker isolé prend en charge les versions LTS (Long Term Support) et STS (Standard Term Support) de .NET, ainsi que .NET Framework. Le modèle in-process ne prend en charge que les versions LTS de .NET. Pour une comparaison complète des caractéristiques et des fonctionnalités entre les deux modèles, consultez Différences entre les processus .NET in-process et les processus de travail isolés Azure Functions.

2 .NET 8 n’est pas encore pris en charge sur le modèle In-process, bien qu’il soit disponible sur le modèle Worker isolé. Pour plus d’informations sur les plans .NET 8, y compris les options futures du modèle In-process, consultez le billet de mise à jour de la feuille de route Azure Functions.

3 La prise en charge prend fin pour le modèle in-process le 10 novembre 2026. Pour plus d’informations, lisez cette annonce relative à la prise en charge. Pour continuer à bénéficier d’une prise en charge complète, vous devez migrer vos applications vers le modèle Worker isolé.

Conseil

Nous vous recommandons de mettre à niveau vers .NET 8 sur le modèle Worker isolé. Cela fournit un chemin de migration rapide à la version entièrement publiée avec la fenêtre de support la plus longue de .NET.

Ce guide ne présente pas d’exemples spécifiques pour .NET 7 ni .NET 6. Si vous devez cibler ces versions, vous pouvez adapter les exemples de .NET 8.

Préparation de la migration

Si ce n’est pas déjà fait, identifiez la liste des applications qui doivent être migrées dans votre abonnement Azure actuel à l’aide d’Azure PowerShell.

Avant de migrer une application vers le modèle Worker isolé, vous devez lire attentivement le contenu de ce guide et vous familiariser avec les caractéristiques du modèle Worker isolé et les différences entre les deux modèles.

Pour migrer l’application, vous allez :

  1. Suivre les étapes décrites dans la section Migrer votre projet local pour migrer votre projet local vers le modèle Worker isolé.
  2. Après avoir migré votre projet, testez entièrement l’application localement à l’aide de la version 4.x d’Azure Functions Core Tools.
  3. Mettre à jour votre application de fonction dans Azure vers le modèle isolé.

Migrer votre projet local

La section décrit les différentes modifications que vous devez apporter à votre projet local pour le déplacer vers le modèle de travail isolé. Certaines des étapes changent en fonction de votre version cible de .NET. Utilisez les onglets pour sélectionner les instructions qui correspondent à la version souhaitée. Ces étapes supposent un projet C# local, et si votre application utilise plutôt un script C# (fichiers .csx), vous devez convertir en modèle de projet avant de continuer.

Conseil

Si vous passez à une version LTS ou STS de .NET, vous pouvez utiliser l’Assistant Mise à niveau .NET utilisé pour apporter automatiquement bon nombre des modifications mentionnées dans les sections suivantes.

Tout d’abord, vous allez convertir le fichier projet et mettre à jour vos dépendances. Ainsi, vous verrez des erreurs de génération pour le projet. Dans les étapes suivantes, vous allez apporter les modifications correspondantes pour supprimer ces erreurs.

Fichier projet

L’exemple qui suit est un fichier projet .csproj qui utilise .NET 6 sur la version 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>

Appliquez l’une des procédures suivantes pour mettre à jour ce fichier XML afin qu’il s’exécute dans le modèle de travail isolé :

Ces étapes supposent un projet C# local, et si votre application utilise plutôt un script C# (fichiers .csx), vous devez convertir en modèle de projet avant de continuer.

Les modifications suivantes sont requises dans le fichier projet XML .csproj :

  1. Définissez la valeur de PropertyGroup.TargetFramework en net8.0.

  2. Définissez la valeur de PropertyGroup.AzureFunctionsVersion en v4.

  3. Ajoutez l’élément OutputType suivant au PropertyGroup :

    <OutputType>Exe</OutputType>

  4. Dans la liste ItemGroup.PackageReference, remplacez la référence de package par Microsoft.NET.Sdk.Functions avec les références suivantes :

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

    Notez toute référence à d’autres packages dans les espaces de noms Microsoft.Azure.WebJobs.*. Vous remplacerez ces packages dans une étape ultérieure.

  5. Ajoutez le nouveau ItemGroup suivant :

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

Une fois ces modifications effectuées, votre projet mis à jour doit ressembler à l’exemple suivant :

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

Références de package

Lors de la migration vers le modèle de travail isolé, vous devez modifier les packages référencés par votre application.

Si ce n’est déjà fait, mettez à jour votre projet pour référencer les dernières versions stables de :

En fonction des déclencheurs et des liaisons que votre application utilise, elle pourrait avoir besoin de référencer un ensemble de packages différent. Le tableau suivant présente des remplacements à certaines des extensions les plus couramment utilisées :

Scénario Modifications apportées aux références de package
Déclencheur de minuteur Ajouter
Microsoft.Azure.Functions.Worker.Extensions.Timer
Liaisons de stockage Replace
Microsoft.Azure.WebJobs.Extensions.Storage
par
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues et
Microsoft.Azure.Functions.Worker.Extensions.Tables
liaisons SSL Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Liaisons de la file d’attente Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Liaisons de tableau Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.Tables
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.Tables
Liaisons Cosmos DB Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.CosmosDB
et/ou
Microsoft.Azure.WebJobs.Extensions.DocumentDB
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Liaisons Service Bus Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.ServiceBus
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Liaisons Event Hubs Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.EventHubs
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Liaisons Event Grid Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.EventGrid
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Liaisons SignalR Service Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.SignalRService
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Fonctions durables Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.DurableTask
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Fonctions durables
(Fournisseur de stockage SQL)		 Remplacez les références à
Microsoft.DurableTask.SqlServer.AzureFunctions
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Fonctions durables
(Fournisseur de stockage Netherite)		 Remplacez les références à
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Liaisons SendGrid Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.SendGrid
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Liaisons Kafka Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.Kafka
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Liaisons RabbitMQ Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Injection de dépendances
et la configuration de démarrage		 Supprimez les références à
Microsoft.Azure.Functions.Extensions
(Le modèle Worker isolé fournit cette fonctionnalité par défaut.)

Consultez les Liaisons prises en charge pour la liste complète des extensions à prendre en compte, et référez-vous à la documentation de chaque extension pour obtenir des instructions d’installation complètes du modèle de processus isolé. Veillez à installer la dernière version stable de tous les packages que vous ciblez.

Conseil

Toutes les modifications apportées aux versions d’extension pendant ce processus peuvent aussi vous obliger à mettre à jour votre fichier host.json. Veillez à lire la documentation de chaque extension que vous utilisez. Par exemple, l’extension Service Bus a des changements cassants dans la structure entre les versions 4.x et 5.x. Pour plus d’informations, consultez la section Liaisons Azure Service Bus pour Azure Functions.

Votre application de modèle Worker isolé ne doit pas référencer de packages dans l’espace de noms Microsoft.Azure.WebJobs.* ni Microsoft.Azure.Functions.Extensions. S’il reste des références à ces derniers, elles doivent être supprimées.

Conseil

Votre application peut également dépendre des types de kits de développement logiciel (SDK) Azure, soit dans le cadre de vos déclencheurs et liaisons, soit en tant que dépendance autonome. Vous devez également en profiter pour les mettre à jour. Les dernières versions des extensions Functions fonctionnent avec les dernières versions du kit de développement logiciel (SDK) Azure pour .NET, presque tous les packages dont la forme est Azure.*.

Fichier Program.cs

Lors de la migration pour une exécution dans un processus Worker isolé, vous devez ajouter un fichier Program.cs à votre projet avec le contenu suivant :

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

Cet exemple inclut l'intégration d'ASP.NET Core pour améliorer les performances et fournir un modèle de programmation familier lorsque votre application utilise des déclencheurs HTTP. Si vous n’avez pas l’intention d’utiliser des déclencheurs HTTP, vous pouvez remplacer l’appel à ConfigureFunctionsWebApplication par un appel à ConfigureFunctionsWorkerDefaults. Dans ce cas, vous pouvez supprimer la référence à Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore de votre fichier projet. Toutefois, pour des performances optimales, même pour les fonctions avec d’autres types de déclencheurs, vous devez conserver ASP.NET Core comme FrameworkReference.

Le fichier Program.cs remplace n’importe quel fichier qui a l’attribut FunctionsStartup, qui est généralement un fichier Startup.cs. Dans les endroits où votre code FunctionsStartup référence IFunctionsHostBuilder.Services, vous pouvez à la place ajouter des instructions dans la méthode .ConfigureServices() de HostBuilder dans votre Program.cs. Pour en savoir plus sur l’utilisation de Program.cs, consultez Démarrage et configuration dans le guide de modèle Worker isolé.

Les exemples Program.cs par défaut ci-dessus incluent la configuration de l’intégration d’Application Insights pour le modèle Worker isolé. Dans votre Program.cs, vous devez également configurer tout filtrage des journaux qui doit s’appliquer aux journaux provenant du code dans votre projet. Dans le modèle Worker isolé, le fichier host.json contrôle uniquement les événements émis par le runtime hôte Functions. Si vous ne configurez pas de règles de filtrage dans Program.cs, vous constaterez peut-être des différences dans les niveaux de journalisation présents pour les différentes catégories de votre télémétrie.

Bien que vous puissiez enregistrer des sources de configuration personnalisées dans le cadre du HostBuilder, notez que celles-ci s’appliquent également uniquement au code de votre projet. La configuration des déclencheurs et des liaisons est également requise par la plateforme, et elle doit être fournie via les paramètres d’application, les références Key Vault ou les fonctionnalités de références App Configuration.

Une fois que vous avez déplacé tous les éléments FunctionsStartup existants vers le fichier Program.cs, vous pouvez supprimer l’attribut FunctionsStartup et la classe à laquelle elle a été appliquée.

Modifications de signature de fonction

Certains types clés changent entre le modèle In-process et le modèle Worker isolé. La plupart d’entre eux concernent les attributs, les paramètres et les types de retour qui composent la signature de fonction. Pour chacune de vos fonctions, vous devez apporter des modifications à :

  • Attribut de fonction (qui définit également le nom de la fonction)
  • Comment la fonction obtient un ILogger/ILogger<T>
  • Attributs et paramètres de déclencheur et de liaison

Le reste de cette section vous guidera dans chacune de ces étapes.

Attributs de fonction

L’attribut FunctionName est remplacé par l’attribut Function dans le modèle Worker isolé. Le nouvel attribut a la même signature et la seule différence est dans le nom. Vous pouvez donc simplement effectuer un remplacement de chaîne dans votre projet.

Journalisation

Dans le modèle in-process, vous pouvez inclure un paramètre ILogger supplémentaire à votre fonction, ou vous pouvez utiliser l’injection de dépendances pour obtenir un ILogger<T>. Si vous utilisiez déjà l’injection de dépendances, les mêmes mécanismes fonctionnent dans le modèle Worker isolé.

Toutefois, pour toutes les fonctions qui s’appuient sur le paramètre de méthode ILogger, vous devez apporter une modification. Il est recommandé d’utiliser l’injection de dépendances pour obtenir un ILogger<T>. Procédez comme suit pour migrer le mécanisme de journalisation de la fonction :

  1. Dans votre classe de fonction, ajoutez une propriété private readonly ILogger<MyFunction> _logger;, en remplaçant MyFunction par le nom de votre classe de fonction.

  2. Créez un constructeur pour votre classe de fonction qui prend ILogger<T> en tant que paramètre :

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

    Remplacez les deux instances de MyFunction dans l’extrait de code ci-dessus par le nom de votre classe de fonction.

  3. Pour les opérations de journalisation dans votre code de fonction, remplacez les références au paramètre ILogger par _logger.

  4. Supprimez le paramètre ILogger de la signature de votre fonction.

Pour plus d’informations, consultez Journalisation dans le modèle Worker isolé.

Changements de déclencheur et de liaison

Lorsque vous avez modifié vos références de package à l’étape précédente, vous avez introduit des erreurs pour vos déclencheurs et liaisons que vous allez maintenant corriger :

  1. Supprimez les instructions using Microsoft.Azure.WebJobs;.

  2. Ajoutez une instruction using Microsoft.Azure.Functions.Worker;.

  3. Pour chaque attribut de liaison, modifiez le nom de l’attribut tel que spécifié dans sa documentation de référence, que vous trouverez dans l’index des Liaison prises en charge. En général, les noms d’attributs changent comme suit :

    • Les déclencheurs restent généralement nommés de la même façon. Par exemple, QueueTrigger est le nom de l’attribut pour les deux modèles.
    • Il est généralement nécessaire que « Input » soit ajouté au nom des liaisons d’entrée. Par exemple, si vous avez utilisé l’attribut de liaison d’entrée CosmosDB dans le modèle in-process, ce serait maintenant CosmosDBInput.
    • Il est généralement nécessaire que « Output » soit ajouté au nom des liaisons de sortie. Par exemple, si vous avez utilisé l’attribut de liaison de sortie Queue dans le modèle in-process, ce serait maintenant QueueOutput.

  4. Mettez à jour les paramètres d’attribut pour refléter la version du modèle Worker isolé, comme spécifié dans la documentation de référence de la liaison.

    Par exemple, dans le modèle in-process, une liaison de sortie d’objet blob est représentée par un attribut [Blob(...)] qui inclut une propriété Access. Dans le modèle Worker isolé, l’attribut de sortie d’objet blob serait [BlobOutput(...)]. La liaison n’exige plus la propriété Access, de sorte qu’il peut être supprimé. Donc [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] deviendrait [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

  5. Déplacez les liaisons de sortie hors de la liste des paramètres de fonction. Si vous n’avez qu’une seule liaison de sortie, vous pouvez l’appliquer au type de retour de la fonction. Si vous avez plusieurs sorties, créez une classe avec des propriétés pour chaque sortie et appliquez les attributs à ces propriétés. Pour plus d’informations, consultez Plusieurs liaisons de sortie.

  6. Consultez la documentation de référence de chaque liaison pour connaître les types auquel elle peut se lier. Dans certains cas, vous devrez peut-être modifier le type. Pour les liaisons de sortie, si la version du modèle in-process a utilisé un IAsyncCollector<T>, vous pouvez la remplacer par la liaison à un tableau du type de cible : T[]. Vous pouvez également envisager de remplacer la liaison de sortie par un objet client pour le service qu’il représente, soit comme type de liaison pour une liaison d’entrée si disponible, soit en injectant un client vous-même.

  7. Si votre fonction inclut un paramètre IBinder, supprimez-le. Remplacez la fonctionnalité par un objet client pour le service qu’elle représente, soit comme type de liaison pour une liaison d’entrée si disponible, soit en injectant un client vous-même.

  8. Mettez à jour le code de fonction pour qu’il fonctionne avec les nouveaux types.

Fichier local.settings.json

Le fichier local.settings.json est uniquement utilisé lors de l’exécution locale. Pour en savoir plus, consultez Fichier de paramètres locaux.

Lors de la migration d’un processus d’exécution In-process vers un processus d’exécution Worker isolé, vous devez passer la valeur FUNCTIONS_WORKER_RUNTIME à « dotnet-isolated ». Assurez-vous que votre fichier local.settings.json comporte au moins les éléments suivants :

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

La valeur que vous avez configurée pour « AzureWebJobsStorage » peut être différente. Vous n’avez pas besoin de modifier sa valeur dans le cadre de la migration.

Fichier host.json

Aucune modification n'est requise à votre dossier host.json. Toutefois, si votre configuration Application Insights dans ce fichier provient de votre projet de modèle in-process, vous souhaiterez peut-être apporter des modifications supplémentaires à votre fichier Program.cs. Le fichier host.json contrôle uniquement la journalisation à partir du runtime de l’hôte Functions, et dans le modèle Worker isolé, certains de ces journaux proviennent directement de votre application, vous donnant plus de contrôle. Voir Gestion des niveaux de journaux dans le modèle de travailleur isolé pour plus de détails sur la façon de filtrer ces journaux.

Autres changements de code

Cette section met en évidence d’autres modifications de code à prendre en compte lors de la migration. Ces modifications ne sont pas nécessaires à toutes les applications, mais vous devez évaluer si certaines sont pertinentes pour vos scénarios.

Sérialisation JSON

Par défaut, le modèle Worker isolé utilise System.Text.Json pour la sérialisation JSON. Pour personnaliser les options de sérialiseur ou passer à JSON.NET (Newtonsoft.Json), consultez ces instructions.

Niveaux de journalisation et filtrage Application Insights

Les journaux peuvent être envoyés à Application Insights à partir du runtime de l’hôte Functions et du code de votre projet. Le host.json vous permet de configurer des règles pour la journalisation de l’hôte, mais pour contrôler les journaux provenant de votre code, vous devrez configurer des règles de filtrage dans le cadre de votre Program.cs. Voir Gestion des niveaux de journaux dans le modèle de travailleur isolé pour plus de détails sur la façon de filtrer ces journaux.

Exemples de migrations de fonction

Exemple de déclencheur HTTP

Un déclencheur HTTP pour le modèle in-process peut ressembler à l’exemple suivant :

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 déclencheur HTTP pour la version migrée peut ressembler à l’exemple suivant :

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"]}!");
        }
    }
}

Mettre à jour votre application de fonction dans Azure

La mise à niveau de votre application de fonction vers le modèle isolé consiste en deux étapes :

  1. Modifiez la configuration de l’application de fonction pour utiliser le modèle isolé en définissant le paramètre d’application FUNCTIONS_WORKER_RUNTIME sur dotnet-isolated. Assurez-vous que toute automatisation de déploiement est mise à jour de la même façon.
  2. Publiez votre projet migré vers l’application de fonction mise à jour.

Lorsque vous utilisez Visual Studio pour publier un projet de modèle Worker isolé sur une application de fonction existante qui utilise le modèle In-process, vous êtes invité à autoriser Visual Studio à mettre à jour l’application de fonction pendant le déploiement. Cela permet d’effectuer les deux étapes à la fois.

Si vous devez réduire les temps d’arrêt, envisagez d’utiliser un emplacement de préproduction pour tester et vérifier votre code migré avec votre configuration mise à jour dans Azure. Vous pouvez ensuite déployer votre application migrée sur l’emplacement de production au moyen d’une opération d’échange.

Une fois ces étapes terminées, votre application a été entièrement migrée vers le modèle isolé. Félicitations ! Répétez les étapes de ce guide si nécessaire pour toute autre application nécessitant une migration.

Étapes suivantes

En savoir plus sur le modèle de travail isolé