Migrer des applications C# du modèle in-process vers le modèle worker isolé

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, vous devez utiliser les guides suivants pour mettre à niveau votre version de l’hôte. Ces guides de migration de version hôte vous aident également à migrer vers le modèle d'ouvrier isolé au fur et à mesure de leur utilisation.

• Migrer des applications d’Azure Functions version 2.x et 3.x vers la version 4.x
• Migrer des applications d’Azure Functions version 1.x vers la version 4.x

En cas de prise en charge, cet article tire parti de l’intégration ASP.NET Core dans le modèle worker isolé, ce qui améliore les performances et fournit un modèle de programmation familier lorsque votre application utilise des déclencheurs HTTP.

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 configuré actuellement 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 ou .NET 8 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 :

¹ 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, jusqu’à .NET 8. 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.

² Le support du modèle In-process prendra fin 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 de travailleur isolé.

³ .NET 9 avait précédemment une date de fin de support attendue du 12 mai 2026. Pendant la fenêtre de service .NET 9, l’équipe .NET a étendu la prise en charge des versions STS à 24 mois, à compter de .NET 9. Pour plus d’informations, consultez le billet de blog.

Ce guide ne présente pas d’exemples spécifiques pour .NET 10 (préversion) ou .NET 9. Si vous devez cibler l’une de ces versions, vous pouvez adapter les exemples .NET 8.

Préparation de la migration

Avant de migrer une application vers le modèle Worker isolé, vous devez examiner attentivement le contenu de ce guide. Vous devez également vous familiariser avec les fonctionnalités du modèle Worker isolé et avec les différences entre les deux modèles.

Pour migrer l’application :

1. Migrez votre projet local vers le modèle Worker isolé en suivant les étapes décrites dans Migrer votre projet local.
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.

Tout d’abord, convertissez le fichier projet et mettez à jour vos dépendances. En le faisant, vous constatez des erreurs de compilation pour le projet. Dans les étapes suivantes, vous allez apporter les modifications correspondantes pour supprimer ces erreurs.

Fichier projet

L’exemple suivant est un fichier projet .csproj qui utilise .NET 8 sur la version 4.x :

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.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é :

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

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
      <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.16.4" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
      <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>
    <Folder Include="Properties\" />
  </ItemGroup>
</Project>

La modification de l’infrastructure cible de votre projet peut également nécessiter la modification de certaines parties de votre chaîne d’outils, en dehors du code du projet. Par exemple, dans VS Code, vous devrez peut-être mettre à jour le azureFunctions.deploySubpath paramètre d’extension via les paramètres utilisateur ou le fichier .vscode/settings.jsonde votre projet. Recherchez les dépendances sur la version de l’infrastructure qui peuvent exister en dehors du code de votre projet, dans le cadre des étapes de génération ou d’un pipeline CI/CD.

Références de paquets

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 :

• Microsoft.Azure.Functions.Worker
• Microsoft.Azure.Functions.Worker.Sdk

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 :

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.

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.

Fichier Program.cs

Lors de la migration pour s’exécuter dans un processus de travail 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();

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

namespace Company.FunctionApp
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

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

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

Les exemples de Program.cs par défaut décrits précédemment incluent la configuration d’Application Insights. Dans votre Program.cs, vous devez également configurer tout filtrage de journal qui doit s’appliquer aux journaux provenant du code de 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 pouvez voir des différences dans les niveaux de journal présents pour différentes catégories dans vos données de télémétrie.

Bien que vous puissiez inscrire des sources de configuration personnalisées en tant que partie du HostBuilder, celles-ci s’appliquent uniquement au code dans votre projet. La plateforme a également besoin d'une configuration de déclencheur et de liaison, et celles-ci doivent être fournies via les paramètres de l’application, les références Key Vault ou les références App Configuration.

Après avoir déplacé tout élément du FunctionsStartup existant vers le fichier Program.cs, vous pouvez supprimer l’attribut FunctionsStartup et la classe à laquelle il a été appliqué.

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 guide dans chacune de ces étapes.

Attributs de fonction

L’attribut Function du modèle Worker isolé remplace l’attribut FunctionName. 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 facultatif ILogger pour votre fonction, ou vous pouvez utiliser l’injection de dépendances pour obtenir un ILogger<T>. Si votre application utilisait déjà l’injection de dépendances, les mêmes mécanismes fonctionnent dans le modèle Worker isolé.

Cependant, pour les fonctions qui s’appuyaient sur le paramètre de méthode ILogger, vous devez apporter une modification. Nous vous recommandons d’utiliser l’injection de dépendances pour obtenir une 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 précédent 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 pouvez maintenant corriger :

1. Supprimez les déclarations 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.
   • Les liaisons d’entrée ont généralement besoin que Input soit ajouté à leur nom. Par exemple, si vous utilisiez l’attribut de liaison d’entrée CosmosDB dans le modèle in-process, cet attribut serait maintenant CosmosDBInput.
   • Les liaisons de sortie doivent généralement Output ajoutées à leur nom. Par exemple, si vous utilisiez l’attribut de liaison de sortie Queue dans le modèle in-process, cet attribut 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 d'un travailleur isolé, l’attribut de sortie du blob serait [BlobOutput(...)]. La liaison n'exige plus la propriété Access, donc ce paramètre 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 utilisé uniquement lors de l’exécution locale. Pour en savoir plus, consultez Fichier de paramètres locaux.

Lors de la migration de l'exécution en processus à l'exécution dans un processus de travail isolé, vous devez changer la valeur FUNCTIONS_WORKER_RUNTIME en dotnet-isolated. Vérifiez que votre fichier local.settings.json contient au moins les éléments suivants :

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

La valeur dont AzureWebJobsStorage vous avez besoin 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 pour votre fichier host.json . Toutefois, si votre configuration Application Insights se trouve dans ce fichier de votre projet de modèle en cours d'exécution, vous pouvez apporter des modifications supplémentaires dans votre fichier Program.cs. Le fichier host.json contrôle uniquement la journalisation à partir du runtime hôte Functions et, dans le modèle worker isolé, certains de ces journaux proviennent directement de votre application, ce qui vous donne plus de contrôle. Pour plus d’informations sur la façon de filtrer ces journaux, consultez Gestion des niveaux de journal dans le modèle Worker isolé.

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 par toutes les applications, mais vous devez évaluer si elles 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 basculer vers JSON.NET (Newtonsoft.Json), consultez Personnalisation de la sérialisation JSON.

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 devez configurer des règles de filtrage dans votre Program.cs. Pour plus d’informations sur la façon de filtrer ces journaux, consultez Gestion des niveaux de journal dans le modèle Worker isolé.

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

Voici un exemple de déclencheur HTTP pour la version migrée :

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

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
using System.Net;

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

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

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

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString($"Welcome to Azure Functions, {req.Query["name"]}!");

            return response;
        }
    }
}

Mettre à jour votre application de fonction dans Azure

La mise à jour de votre application de fonction vers le modèle isolé implique deux modifications qui doivent être effectuées ensemble, car si vous n’en faites qu’une seule, l’application est dans un état d’erreur. Ces deux modifications entraînent également le redémarrage du processus de l’application. Pour ces raisons, vous devez effectuer la mise à jour en utilisant un emplacement de préproduction. Les slots de staging réduisent les interruptions de votre application et vous permettent de tester et de 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.

Procédez comme suit pour utiliser des emplacements de déploiement afin de mettre à jour votre application de fonctions vers le modèle de travailleur isolé :

1. Si vous ne l’avez pas déjà fait, créez un emplacement de déploiement. Vous pouvez également vous familiariser avec le processus de permutation des emplacements et vérifier que vous pouvez effectuer des mises à jour de l’application existante avec une interruption minimale.

2. Modifiez la configuration de l’emplacement intermédiaire (hors production) pour utiliser le modèle de travailleur isolé en définissant le paramètre d’application FUNCTIONS_WORKER_RUNTIME sur dotnet-isolated. FUNCTIONS_WORKER_RUNTIME ne doit pas être marqué comme paramètre d’emplacement.

   Si vous ciblez également une autre version de .NET dans le cadre de votre mise à jour, vous devez également modifier la configuration de la pile d'exécution. Pour ce faire, consultez Mettre à jour la configuration de la pile. Vous pouvez utiliser les mêmes instructions pour toutes les futures mises à jour de version .NET que vous effectuez.

   Si vous disposez d’un approvisionnement d’infrastructure automatisé, comme un pipeline CI/CD, vérifiez que les automatisations sont également mises à jour pour conserver FUNCTIONS_WORKER_RUNTIME défini sur dotnet-isolated et pour cibler la version correcte de .NET.

3. Publiez votre projet migré sur l’emplacement intermédiaire (hors production) de votre application de fonction.

   Si vous utilisez Visual Studio pour publier un projet de modèle de travailleur isolé sur une application ou un emplacement existant qui utilise un modèle intégré, Visual Studio peut également effectuer l'étape précédente pour vous en même temps. Si vous n’avez pas terminé l’étape précédente, Visual Studio vous invite à mettre à jour l’application de fonction pendant le déploiement. Visual Studio présente cela sous la forme d’une seule opération, mais il s’agit néanmoins toujours de deux opérations distinctes. Vous pouvez toujours voir des erreurs dans vos journaux d’activité à partir de l’emplacement intermédiaire (hors production) pendant l’état intermédiaire.

4. Vérifiez que votre application fonctionne comme prévu dans l’emplacement intermédiaire (hors production).

5. Effectuez une opération d’échange d’emplacement pour appliquer les modifications que vous avez apportées dans votre emplacement intermédiaire (non-production) à l’emplacement de production. Une permutation d’emplacement se produit sous la forme d’une seule mise à jour, ce qui évite d’introduire l’état d’erreur intermédiaire dans votre environnement de production.

6. Vérifiez que votre application fonctionne comme attendu dans l’emplacement de production.

Une fois ces étapes effectuées, la migration est terminée et votre application s’exécute sur le modèle isolé. Félicitations ! Répétez les étapes de ce guide si nécessaire pour toutes les autres applications qui ont besoin de la migration.

Étape suivante