Migrer des applications d’Azure Functions version 3.x vers la version 4.x

  • Article

Azure Functions version 4.x offre une compatibilité descendante forte avec la version 3.x. La plupart des applications doivent être mises à niveau sans problème vers la version 4.x sans modification importante du code. Pour plus d’informations sur les versions du runtime Functions, consultez Vue d’ensemble des versions du runtime Azure Functions.

Important

À compter du 13 décembre 2022, les applications de fonction s’exécutant sur les versions 2.x et 3.x du runtime Azure Functions ont atteint la fin de vie (EOL) du support étendu.

Après l’échéance, les applications de fonction peuvent être créées et déployées à partir de votre pipeline DevOps CI/CD, et toutes les applications existantes continuent de s’exécuter sans changements cassants. Toutefois, vos applications ne sont pas éligibles aux nouvelles fonctionnalités, aux correctifs de sécurité et à l’optimisation des performances. Vous obtiendrez le support du service associé après la mise à niveau vers la version 4.x.

La fin de la prise en charge de ces versions du runtime est due à la fin de la prise en charge de .NET Core 3.1, qui est requis par celles-ci. Cette exigence concerne toutes les langues prises en charge par Azure Functions.

Nous vous recommandons vivement de migrer vos applications de fonction vers la version 4.x du runtime Functions en suivant cet article.

La version 1.x d’Azure Functions reste prise en charge pour les applications de fonction C# qui ont besoin de .NET Framework. La prise en charge de la préversion est désormais disponible dans Azure Functions 4.x pour exécuter les fonctions C# sur .NET Framework 4.8.

Cet article vous guide tout au long du processus de migration, de manière sécurisée, de votre application de fonction pour qu’elle s’exécute sur la version 4.x du runtime Functions. Étant donné que les instructions de mise à niveau du projet dépendent du langage, veillez à choisir votre langage de développement à l’aide du sélecteur en haut de l’article.

Choisir votre version de .NET cible

Sur la version 3.x du runtime Functions, votre application de fonction C# cible .NET Core 3.1. Lorsque vous migrez votre application de fonction vers la version 4.x, vous avez la possibilité de choisir la version cible de .NET. Vous pouvez mettre à niveau votre projet C# vers l’une des versions suivantes de .NET, qui peuvent toutes s’exécuter sur Functions version 4.x :

Version de .NET Modèle de processus*
.NET 7 Processus de travail isolé
.NET 6 Processus de travail isolé
.NET 6 In-process

*L’exécution in-process est prise en charge uniquement pour les versions de support à long terme (LTS) de .NET. Les versions STS (Standard Terms Support) et .NET Framework sont prises en charge par le processus Worker isolé des fonctions .NET Azure.

Conseil

Sur la version 3.x du runtime Functions, si vous utilisez .NET 5, nous vous recommandons de mettre à niveau vers .NET 7. Si vous utilisez .NET Core 3.1, nous vous recommandons d’effectuer une mise à niveau vers .NET 6 (in-process) pour un chemin de mise à niveau rapide.

Si vous souhaitez passer à une version de support à long terme (LTS) de .NET, nous vous recommandons de mettre à niveau vers .NET 6.

Migrez vers le modèle Worker isolé .NET pour obtenir tous les avantages fournis par le processus Worker isolé .NET d’Azure Functions. Pour plus d’informations sur les avantages des processus Worker isolés .NET, consultez Amélioration du processus Worker isolé .NET. Pour plus d’informations sur la prise en charge des versions de .NET, consultez Versions prises en charge.

La mise à niveau de .NET Core 3.1 vers .NET 6 exécuté in-process ne nécessite que des mises à jour minimales de votre projet et pratiquement aucune mise à jour du code. Le passage au modèle de processus Worker isolé vous oblige à apporter des modifications à votre code, mais offre la flexibilité de pouvoir facilement s’exécuter sur n’importe quelle version ultérieure de .NET. Pour obtenir une comparaison des fonctionnalités des deux modèles de processus, consultez .NET Azure Functions : Différences entre l’exécution in-process et les processus Worker isolés.

Préparation de la migration

Avant de mettre à niveau votre application vers la version 4.x du runtime Functions, vous devez effectuer les tâches suivantes :

Exécuter le validateur de pré-mise à niveau

Azure Functions fournit un validateur de pré-mise à niveau pour vous aider à identifier les problèmes potentiels lors de la migration de votre application de fonction vers la version 4.x. Pour exécuter le validateur de pré-mise à niveau :

  1. Sur le portail Azure, accédez à votre application de fonction.

  2. Ouvrez la page Diagnostiquer et résoudre les problèmes.

  3. Dans Diagnostics de l’application de fonction, commencez à taper Functions 4.x Pre-Upgrade Validator, puis choisissez-le dans la liste.

  4. Une fois la validation terminée, passez en revue les recommandations et résolvez les problèmes dans votre application. Si vous devez apporter des modifications à votre application, veillez à valider les modifications par rapport à la version 4.x du runtime Functions, soit localement à l’aide d’Azure Functions Core Tools v4, soit à l’aide d’un emplacement de préproduction.

Identifier les applications de fonction à mettre à niveau

Utilisez le script PowerShell suivant pour générer une liste d’applications de fonction dans votre abonnement qui ciblent actuellement les versions 2.x ou 3.x :

$Subscription = '<YOUR SUBSCRIPTION ID>' 
 
Set-AzContext -Subscription $Subscription | Out-Null

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"] -like '*3*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

Mettre à jour votre projet local

Les instructions de mise à niveau dépendent du langage. Si vous ne voyez pas votre langage, sélectionnez-le à l’aide du sélecteur en haut de l’article.

Choisissez l’onglet qui correspond à votre version cible de .NET et au modèle de processus souhaité (in-process ou processus Worker isolé).

Fichier .csproj

Voici un exemple de fichier projet .csproj qui utilise .NET Core 3.1 sur la version 3.x :

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.13" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Appliquez l’une des procédures suivantes pour mettre à jour ce fichier XML afin qu’il s’exécute dans Functions version 4.x :

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

  1. Changez la valeur de PropertyGroup.TargetFramework en net6.0.

  2. Changez la valeur de PropertyGroup.AzureFunctionsVersion en v4.

  3. Remplacez la liste ItemGroup.PackageReference existante par le ItemGroup suivant :

    <ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
</ItemGroup>

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


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

Fichier program.cs

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

Un fichier program.cs n’est pas nécessaire lors de l’exécution in-process.

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 de l’exécution in-process vers l’exécution dans un processus Worker isolé, vous devez modifier la valeur FUNCTIONS_WORKER_RUNTIME, comme dans l’exemple suivant :

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet"
    }
}

Modifications de l’espace de noms

Les fonctions C# qui s’exécutent dans un processus Worker isolé utilisent des bibliothèques dans un espace de noms différent de celles utilisées lors de l’exécution in-process. Les bibliothèques in-process se trouvent généralement dans l’espace de noms Microsoft.Azure.WebJobs.*. Les applications de fonction à processus Worker isolé utilisent des bibliothèques dans l’espace de noms Microsoft.Azure.Functions.Worker.*. Vous pouvez voir l’effet de ces modifications d’espace de noms sur les instructions using dans les exemples de modèles de déclencheur HTTP qui suivent.

Modifications de nom de classe

Certaines classes clés changent de noms en raison de différences entre les API in-process et de processus Worker isolé.

Le tableau suivant indique les classes .NET clés utilisées par Functions qui sont susceptibles de changer lors de la migration à partir d’in-process :

.NET Core 3.1 .NET 6 (in-process) .NET 6 (isolé) .NET 7
FunctionName (attribut) FunctionName (attribut) Function (attribut) Function (attribut)
HttpRequest HttpRequest HttpRequestData HttpRequestData
OkObjectResult OkObjectResult HttpResponseData HttpResponseData

Il peut également y avoir des différences de nom de classe dans les liaisons. Pour plus d’informations, consultez les articles de référence relatifs aux liaisons en question.

Modèle de déclencheur HTTP

Les différences entre in-process et processus Worker isolé sont visibles dans les fonctions déclenchées par HTTP. Le modèle de déclencheur HTTP pour la version 3.x (in-process) ressemble à l’exemple suivant :

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;

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

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            string responseMessage = string.IsNullOrEmpty(name)
                ? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
                : $"Hello, {name}. This HTTP triggered function executed successfully.";

            return new OkObjectResult(responseMessage);
        }
    }
}

Le modèle de déclencheur HTTP pour la version migrée ressemble à l’exemple suivant :

Identique à la version 3.x (in-process).

Pour mettre à jour votre projet vers Azure Functions 4.x :

  1. Mettez à jour votre installation locale de Azure Functions Core Tools vers la version 4.x.

  2. Mettez à jour le bundle d’extensions Azure Functions de votre application vers la version 2.x ou ultérieure. Pour plus d'informations, consultez Modifications importantes.

  1. Si nécessaire, passez à l’une des versions java prises en charge sur la version 4.x.

  2. Mettez à jour le fichier POM.xml de l’application en affectant la valeur ~4 au paramètre FUNCTIONS_EXTENSION_VERSION, comme dans l’exemple suivant :

    <configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~4</value>
        </property>
    </appSettings>
</configuration>
  1. Si nécessaire, passez à l’une des versions Node.js prises en charge sur la version 4.x.
  1. Profitez de cette opportunité pour effectuer une mise à niveau vers PowerShell 7.2, est recommandée. Pour plus d’informations, consultez Versions de PowerShell.
  1. Si vous utilisez Python 3.6, passez à l’une des versions prises en charge.

Mettre à niveau votre application de fonction dans Azure

Vous devez mettre à niveau le runtime de l’hôte d’application de fonction dans Azure vers la version 4.x avant de publier votre projet migré. La version du runtime utilisée par l’hôte Functions est contrôlée par le paramètre d’application FUNCTIONS_EXTENSION_VERSION, mais dans certains cas d’autres paramètres doivent également être mis à jour. Les modifications de code et les modifications apportées aux paramètres d’application nécessitent le redémarrage de votre application de fonction.

Le moyen le plus simple de procéder consiste à mettre à niveau sans emplacements, puis à republier votre projet d’application. Vous pouvez également réduire le temps d’arrêt dans votre application et simplifier la restauration en effectuant une mise à niveau à l’aide d’emplacements.

Mettre à niveau sans emplacements

Le moyen le plus simple de mettre à niveau vers la version v4.x consiste à définir le paramètre d’application FUNCTIONS_EXTENSION_VERSION sur ~4 sur votre application de fonction dans Azure. Vous devez suivre une procédure différente sur un site avec des emplacements.

az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

Pendant la mise à niveau, vous devez également définir un autre paramètre, qui diffère entre Windows et Linux.

Lors de l’exécution sur Windows, vous devez également activer .NET 6.0, qui est requis par la version 4.x du runtime.

az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

.NET 6 est nécessaire pour les applications de fonction dans n’importe quel langage s’exécutant sur Windows.

Dans cet exemple, remplacez <APP_NAME> par le nom de votre application de fonction, et <RESOURCE_GROUP_NAME> par le nom du groupe de ressources.

Vous pouvez maintenant republier votre projet d’application qui a été migré pour s’exécuter sur la version 4.x.

Mettre à niveau à l’aide d’emplacements

L’utilisation d’emplacements de déploiement est un bon moyen de mettre à niveau votre application de fonction vers le runtime v4.x à partir d’une version précédente. À l’aide d’un emplacement de préproduction, vous pouvez exécuter votre application sur la nouvelle version du runtime dans l’emplacement de préproduction et basculer vers la production après vérification. Les emplacements permettent également de réduire les temps d’arrêt pendant la mise à niveau. Si vous devez réduire au maximum les temps d’arrêt, suivez les étapes de mise à niveau minimale des temps d’arrêt.

Une fois que vous avez vérifié votre application dans l’emplacement mis à niveau, vous pouvez basculer l’application et les nouveaux paramètres de version en production. Cet échange nécessite un paramètre WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 dans l’emplacement de production. La façon dont vous ajoutez ce paramètre affecte la quantité de temps d’arrêt nécessaire pour la mise à niveau.

Mise à niveau standard

Si votre application de fonction avec emplacement peut gérer le temps d’arrêt d’un redémarrage complet, vous pouvez mettre à jour le paramètre WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS directement dans l’emplacement de production. Étant donné que la modification de ce paramètre directement dans l’emplacement de production entraîne un redémarrage qui a un impact sur la disponibilité, envisagez de procéder à cette modification au moment de la réduction du trafic. Vous pouvez ensuite échanger dans la version mise à niveau à partir de l’emplacement intermédiaire.

L’applet de commande PowerShell Update-AzFunctionAppSetting ne prend pas actuellement en charge les emplacements. Vous devez utiliser Azure CLI ou le portail Azure.

  1. Utilisez la commande suivante pour définir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 dans l’emplacement de production :

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME>

    Dans cet exemple, remplacez <APP_NAME> par le nom de votre application de fonction, et <RESOURCE_GROUP_NAME> par le nom du groupe de ressources. Cette commande entraîne le redémarrage de l’application dans l’emplacement de production.

  2. Utilisez la commande suivante pour définir également WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS dans l’emplacement de préproduction :

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  3. Utilisez la commande suivante pour modifier FUNCTIONS_EXTENSION_VERSION et mettre à niveau l’emplacement de préproduction vers la nouvelle version du runtime :

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  4. La version 4.x du runtime Functions nécessite .NET 6 dans Windows. Sur Linux, les applications .NET doivent également être mises à niveau vers .NET 6. Utilisez la commande suivante pour que le runtime puisse s’exécuter sur .NET 6 :

    Lors de l’exécution sur Windows, vous devez également activer .NET 6.0, qui est requis par la version 4.x du runtime.

    az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

    .NET 6 est nécessaire pour les applications de fonction dans n’importe quel langage s’exécutant sur Windows.

    Dans cet exemple, remplacez <APP_NAME> par le nom de votre application de fonction, et <RESOURCE_GROUP_NAME> par le nom du groupe de ressources.

  5. Si votre projet de code nécessite des mises à jour à exécuter sur la version 4.x, déployez ces mises à jour sur l’emplacement de préproduction maintenant.

  6. Vérifiez que votre application de fonction s’exécute correctement dans l’environnement intermédiaire mis à niveau avant d’effectuer l’échange.

  7. Utilisez la commande suivante pour échanger l’emplacement de préproduction mis à niveau en production :

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

Mise à niveau avec un minimum de temps d’arrêt

Pour réduire le temps d’arrêt dans votre application de production, vous pouvez échanger le paramètre WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS de l’emplacement de préproduction en production. Après cela, vous pouvez échanger dans la version mise à niveau à partir d’un emplacement de préproduction préparé.

  1. Utilisez la commande suivante pour définir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 dans l’emplacement de préproduction :

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  2. Utilisez les commandes suivantes pour permuter l’emplacement avec le nouveau paramètre en production, et en même temps restaurer le paramètre de version dans l’emplacement de préproduction.

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

    Vous pouvez rencontrer des erreurs à partir de l’emplacement de préproduction pendant le délai entre l’échange et la version du runtime restaurée dans l’emplacement de préproduction. Cette erreur peut se produire, car avoir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 uniquement en préproduction pendant un échange supprime le paramètre FUNCTIONS_EXTENSION_VERSION dans l’emplacement de préproduction. Sans le paramètre de version, votre emplacement est dans un état incorrect. La mise à jour de la version dans l’emplacement de préproduction juste après l’échange doit remettre l’emplacement dans un état correct et vous pouvez restaurer vos modifications si nécessaire. Toutefois, toute restauration de l’échange vous oblige également à supprimer WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 directement de l’emplacement de production avant le retour de l’échange pour éviter les mêmes erreurs de production que celles observées en préproduction. Cette modification dans le paramètre de production entraîne alors un redémarrage.

  3. Utilisez la commande suivante pour à nouveau définir WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 dans l’emplacement de préproduction :

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

    À ce stade, WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 est défini dans les deux emplacements.

  4. Utilisez la commande suivante pour modifier FUNCTIONS_EXTENSION_VERSION et mettre à niveau l’emplacement de préproduction vers la nouvelle version du runtime :

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  5. La version 4.x du runtime Functions nécessite .NET 6 dans Windows. Sur Linux, les applications .NET doivent également être mises à niveau vers .NET 6. Utilisez la commande suivante pour que le runtime puisse s’exécuter sur .NET 6 :

    Lors de l’exécution sur Windows, vous devez également activer .NET 6.0, qui est requis par la version 4.x du runtime.

    az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

    .NET 6 est nécessaire pour les applications de fonction dans n’importe quel langage s’exécutant sur Windows.

    Dans cet exemple, remplacez <APP_NAME> par le nom de votre application de fonction, et <RESOURCE_GROUP_NAME> par le nom du groupe de ressources.

  6. Si votre projet de code nécessite des mises à jour à exécuter sur la version 4.x, déployez ces mises à jour sur l’emplacement de préproduction maintenant.

  7. Vérifiez que votre application de fonction s’exécute correctement dans l’environnement intermédiaire mis à niveau avant d’effectuer l’échange.

  8. Utilisez la commande suivante pour permuter l’emplacement de préproduction mis à niveau et préparé en production :

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

Changements cassants entre la version 3.x et la version 4.x

Voici les principales modifications cassants à prendre en compte avant de mettre à niveau une application 3.x vers la version 4.x, y compris les changements cassants spécifiques à la langue. Pour obtenir une liste complète, consultez les problèmes Azure Functions GitHub étiquetés Breaking Change: Approved (Changement cassant : Approuvé).

Si vous ne voyez pas votre langage de programmation, allez le sélectionner en haut de la page.

Runtime

  • Les proxys Azure Functions sont une fonctionnalité héritée des versions 1.x à 3.x du runtime Azure Functions. La prise en charge des proxys Functions peut être rétablie dans la version 4.x pour vous permettre de mettre à niveau correctement vos applications de fonction vers la dernière version du runtime. Dès que possible, vous devez à la place basculer vers l’intégration de vos applications de fonction avec Gestion des API Azure. Gestion des API vous permet de tirer parti d’un ensemble plus complet de fonctionnalités pour définir, sécuriser, gérer et monétiser vos API basées sur Functions. Pour plus d’informations, consultez Intégration de Gestion des API. Pour savoir comment réactiver la prise en charge des proxys dans Functions version 4.x, consultez Réactiver les proxys dans Functions v4.x.

  • La journalisation vers Stockage Azure à l’aide d’AzureWebJobsDashboard n’est plus prise en charge dans la version 4.x. Vous devez plutôt utiliser Application Insights. (#1923)

  • Azure Functions 4.x applique désormais des exigences de version minimale pour les extensions. Effectuez une mise à niveau vers la version la plus récente des extensions concernées. Pour les langages autres que .NET, effectuez une mise à niveau vers la version 2.x ou ultérieure du pack d’extension. (#1987)

  • Les délais d’expiration par défaut et maximaux sont désormais appliqués dans la version 4.x pour les applications de fonction s’exécutant sur Linux dans un plan Consommation. (#1915)

  • Azure Functions 4.x utilise Azure.Identity et Azure.Security.KeyVault.Secrets pour le fournisseur Key Vault et a déconseillé l’utilisation de Microsoft.Azure.KeyVault. Pour plus d’informations sur la configuration des paramètres de l’application de fonction, consultez l’option Key Vault dans les référentiels de secrets. (#2048)

  • Les applications de fonction qui partagent des comptes de stockage ne démarrent plus lorsque leurs identifiants d’hôte sont les mêmes. Pour plus d’informations, consultez Considérations relatives à l’ID d’hôte. (#2049)

  • Azure Functions 4.x prend en charge les applications in-process et isolées .NET 6.

  • InvalidHostServicesException est désormais une erreur irrécupérable. (#2045)

  • EnableEnhancedScopes est activé par défaut. (#1954)

  • Supprimer HttpClient en tant que serveur inscrit. (#1911)

  • Utilisez le chargeur de classe unique dans Java 11. (#1997)

  • Arrêtez le chargement des fichiers JAR de Worker dans Java 8. (#1991)

  • Les versions 10 et 12 de Node.js ne sont pas prises en charge dans Azure Functions 4.x. (#1999)

  • La sérialisation de sortie dans les applications Node.js a été mise à jour pour résoudre les incohérences précédentes. (#2007)

  • Le nombre de Threads par défaut a été mis à jour. Les fonctions qui ne sont pas thread-safe ou qui présentent une utilisation élevée de la mémoire peuvent être affectées. (#1962)

  • Python 3.6 n’est pas pris en charge dans Azure Functions 4.x. (#1999)

  • Le transfert de mémoire partagée est activé par défaut. (#1973)

  • Le nombre de Threads par défaut a été mis à jour. Les fonctions qui ne sont pas thread-safe ou qui présentent une utilisation élevée de la mémoire peuvent être affectées. (#1962)

Étapes suivantes

En savoir plus sur les versions de Functions