Vue d’ensemble des versions du runtime Azure Functions

Azure Functions prend actuellement en charge plusieurs versions de l’hôte du runtime. Le tableau suivant détaille les versions disponibles, leur niveau de support et le moment où elles doivent être utilisées :

Version Niveau de support Description
4.x GA Version de runtime recommandée pour les fonctions dans tous les langages. Utilisez cette version pour exécuter des fonctions C# sur .NET 6.0 et .NET Framework 4.8.
3.x GA Prend en charge tous les langages. Utilisez cette version pour exécuter des fonctions C# sur .NET Core 3.1 et .NET 5.0.
2.x GA Prise en charge pour les applications héritées des versions 2.x. Cette version est en mode maintenance, et les améliorations ne seront apportées que dans les versions ultérieures.
1.x GA Recommandé uniquement pour les applications C# qui doivent utiliser .NET Framework ; ne prend en charge que le développement dans le portail Azure, le portail Azure Stack Hub ou localement sur les ordinateurs Windows. Cette version est en mode maintenance, et les améliorations ne seront apportées que dans les versions ultérieures.

Cet article détaille certaines des différences entre ces versions, la façon dont vous pouvez créer chaque version, et la manière de changer la version sur laquelle vos fonctions s’exécutent.

Niveaux de prise en charge

Il y a deux niveaux de prise en charge :

  • Disposition générale (GA) : entièrement pris en charge et approuvé pour la production.
  • Préversion : pas encore pris en charge, mais le statut de disponibilité générale est prévu à l’avenir.

Languages

Toutes les fonctions d’une application de fonction doivent partager le même langage. Vous avez choisi le langage des fonctions de votre application de fonction lors de la création de l’application. Le langage de votre application de fonction est conservé dans le paramètre FUNCTIONS_WORKER_RUNTIME et ne doit pas être modifié lorsque des fonctions existent.

Le tableau suivant montre les langages de programmation actuellement pris en charge dans chaque version du runtime.

Langage 1.x 2.x 3.x 4.x
C# GA (.NET Framework 4.8) GA (.NET Core 2.11) Disponibilité générale (.NET Core 3.1)
GA (.NET 5.0)
GA (.NET 6.0)
Préversion (.NET Framework 4.8)
JavaScript GA (Node.js 6) GA (Node.js 10 & 8) GA (Node.js 14, 12, & 10) GA (Node.js 14)
GA (Node.js 16)
F# GA (.NET Framework 4.8) GA (.NET Core 2.11) Disponibilité générale (.NET Core 3.1) GA (.NET 6.0)
Java N/A Disponibilité générale (Java 8) GA (Java 11 & 8) GA (Java 11 & 8)
PowerShell N/A GA (PowerShell Core 6) GA (PowerShell 7.0 & Core 6) Disponibilité générale (PowerShell 7.0)
Préversion (PowerShell 7.2)
Python N/A GA (Python 3.7 & 3.6) GA (Python 3.9, 3.8, 3.7, & 3.6) GA (Python 3.9, 3.8, 3.7)
TypeScript2 N/A GA GA GA

1 Les applications de bibliothèque de classes .NET qui ciblent le runtime version 2.x s’exécutent sur .NET Core 3.1 en mode de compatibilité .NET Core 2.x. Pour plus d’informations, consultez Considérations relatives à Functions v2.x.
2 Prise en charge via la transpilation vers JavaScript.

Pour plus d’informations sur les versions linguistiques prises en charge, consultez l’article du Guide du développeur spécifique à une langue.
Pour plus d’informations sur les modifications prévues sur la prise en charge des langages, consultez la Feuille de route Azure.

Exécuter sur une version spécifique

Par défaut, les applications de fonction créées dans le portail Azure et par l’interface Azure CLI sont configurées pour la version 4.x. Vous pouvez modifier cette version en fonction de vos besoins. Vous pouvez repasser à la version 1.x du runtime seulement après avoir créé votre application de fonction et avant d’ajouter des fonctions. Le déplacement vers une version ultérieure est autorisé même avec des applications qui ont des fonctions existantes. Lorsque votre application dispose de fonctions existantes, faites attention aux changements cassants entre les versions avant de passer à une version ultérieure du runtime. Les sections suivantes détaillent les changements entre les versions :

Avant d’apporter une modification à la version principale du runtime, vous devez d’abord tester votre code en le déployant sur une autre application de fonction qui s’exécute sur la dernière version principale. Ce test permet de vérifier que le code s’exécute correctement après la mise à niveau. Vous pouvez également vérifier votre code localement à l’aide de la version spécifique au runtime d’Azure Functions Core Tools, qui inclut le runtime Functions.

La rétrogradation vers la v2.x n’est pas prise en charge. Lorsque cela est possible, vous devez toujours exécuter vos applications sur la dernière version prise en charge du runtime Functions.

Changement de la version des applications dans Azure

La version du runtime Functions utilisée par les applications publiées dans Azure dépend du paramètre d’application FUNCTIONS_EXTENSION_VERSION. Les valeurs des versions majeures du runtime suivantes sont prises en charge :

Valeur Cible du runtime
~4 4.x
~3 3.x
~2 2.x
~1 1.x

Important

Ne modifiez pas arbitrairement ce paramètre d’application, car d’autres modifications des paramètres de l’application et d’autres modifications du code dans vos fonctions peuvent être nécessaires. Vous devez plutôt modifier ce paramètre dans l’onglet Paramètres du runtime de fonction de la Configuration de l’application de fonction dans le portail Azure lorsque vous êtes prêt à effectuer une mise à niveau de version majeure.

Pour en savoir plus, voir Comment cibler des versions du runtime Azure Functions.

Épinglage sur une version mineure spécifique

Pour résoudre les problèmes liés à l’exécution de votre application de fonction sur la version principale la plus récente, vous devez temporairement épingler votre application à une version mineure spécifique. Cela vous donne le temps de faire le nécessaire pour que votre application s’exécute correctement sur la dernière version majeure. La façon dont vous épinglez l’application à une version mineure n’est pas la même dans Windows et dans Linux. Pour en savoir plus, voir Comment cibler des versions du runtime Azure Functions.

Les versions mineures les plus anciennes sont régulièrement supprimées de Functions. Pour obtenir les dernières informations sur les versions Azure Functions, notamment sur la suppression des versions mineures les plus anciennes, surveillez les annonces Azure App Service.

Épinglage sur la version ~2.0

Les applications de fonction .NET qui sont exécutées sur la version 2.x (~2) sont automatiquement mises à niveau pour s’exécuter sur .NET Core 3.1, qui est une version de .NET Core 3 avec prise en charge à long terme. En exécutant vos fonctions .NET sur .NET Core 3.1, vous pouvez tirer parti des dernières mises à jour de sécurité et améliorations produit.

Les applications de fonction épinglées à ~2.0 continuent de s’exécuter sur .NET Core 2.2, qui ne reçoit plus de mises à jour de sécurité ni aucune autre mise à jour. Pour plus d’informations, consultez Considérations relatives à Functions v2.x.

Versions d’extension minimales

Il n’existe pas techniquement de corrélation entre les versions d’extension de liaison et la version du runtime Functions. Toutefois, à compter de la version 4.x, le runtime Functions applique une version minimale pour toutes les extensions de déclencheur et de liaison.

Si vous recevez un avertissement sur un package qui ne répond pas à une version minimale requise, vous devez mettre à jour ce package NuGet vers la version minimale comme vous le feriez normalement. La configuration minimale requise pour les extensions utilisées dans Functions v4.x est disponible dans ce fichier de configuration.

Pour le script C#, mettez à jour la référence du pack d’extension dans host.json comme suit :

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[2.*, 3.0.0)"
    }
}

Il n’existe pas techniquement de corrélation entre les versions du pack d’extensions et la version du runtime Functions. Toutefois, à compter de la version 4.x, le runtime Functions applique une version minimale pour les packs d’extensions.

Si vous recevez un avertissement disant que la version de votre pack d’extensions n’est pas conforme à la version minimale requise, mettez à jour votre référence de pack d’extensions existante dans host.json comme suit :

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[2.*, 3.0.0)"
    }
}

Pour en savoir plus sur les packs d’extensions, consultez Packs d’extensions.

Migration de 3.x vers 4.x

Azure Functions version 4.x offre une compatibilité descendante forte avec la version 3.x. De nombreuses applications doivent être mises à niveau sans problème vers la version 4.x sans modification importante du code. Veillez à tester entièrement votre application localement à l’aide de la version 4.x d’Azure Functions Core Tools ou dans un emplacement intermédiaire avant de modifier la version majeure dans les applications de production.

Mise à niveau d’une application existante

Lorsque vous développez votre application de fonction localement, vous devez mettre à niveau votre environnement de projet local et votre application de fonction s’exécutant dans Azure.

Projet local

Les instructions de mise à niveau peuvent dépendre de la langue. Si vous ne voyez pas votre langue, sélectionnez-la à l’aide du sélecteur en haut de l’article.

Pour mettre à jour une application de bibliothèque de classes C# vers .NET 6 et Azure Functions 4.x, mettez à jour TargetFramework et AzureFunctionsVersion :

<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

Vous devez également veiller à ce que les packages NuGet référencés par votre application soient mis à jour vers les dernières versions. Pour plus d’informations, consultez les changements cassants. Les packages spécifiques varient selon que vos fonctions s’exécutent exécutées dans le processus ou hors processus.

Pour mettre à jour votre application avec Azure Functions 4.x, mettez à jour votre installation locale d’Azure Functions Core Tools vers la version 4.x et le bundle d’extensions Azure Functions de votre application vers la version 2.x ou ultérieure. Pour plus d’informations, consultez les changements cassants.

Notes

Node.js 10 et 12 ne sont pas pris en charge dans Azure Functions 4.x.

Notes

PowerShell 6 n’est pas pris en charge dans Azure Functions 4.x.

Notes

Python 3.6 n’est pas pris en charge dans Azure Functions 4.x.

Azure

Un validateur de pré-mise à niveau est disponible pour identifier les problèmes potentiels lors de la migration d’une application de fonction vers 4.x. Avant de migrer une application existante, effectuez les étapes suivantes pour exécuter le validateur :

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

  2. Ouvrez le panneau Diagnostiquer et résoudre les problèmes.

  3. Dans Rechercher des problèmes courants ou des outils, entrez et sélectionnez Validateur de pré-mise à niveau Functions 4.x

Une fois que vous avez vérifié que l’application peut être mise à niveau, vous pouvez commencer le processus de migration. Consultez les sous-sections ci-dessous pour obtenir des instructions sur la migration sans emplacements et la migration avec des emplacements.

Remarque

Si vous utilisez un emplacement pour gérer la migration, vous devez définir le paramètre d’application WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS sur « 0 » sur les deux emplacements. Cela permet d’inclure les modifications de version que vous apportez dans l’opération d’échange d’emplacement. Vous pouvez alors mettre à niveau votre emplacement de préproduction (non-production), puis effectuer l’échange.

Pour migrer une application de la version 3.x vers la version 4.x, vous allez :

  • Définir le paramètre d’application FUNCTIONS_EXTENSION_VERSION sur ~4.
  • Pour les applications de fonction Windows uniquement, activez .NET 6.0 par le biais du paramètre netFrameworkVersion
Migration sans emplacements

Vous pouvez utiliser les commandes Azure CLI ou Azure PowerShell suivantes pour effectuer cette mise à niveau directement sur un site sans emplacements :

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

# For Windows function apps only, also enable .NET 6.0 that is needed by the runtime
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
Migration avec des emplacements

Vous pouvez utiliser les commandes Azure CLI suivantes pour effectuer cette mise à niveau en utilisant des emplacements de déploiement :

Tout d’abord, mettez à jour l’emplacement de production avec WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0. Si votre application peut tolérer un redémarrage (ce qui a un impact sur la disponibilité), il est recommandé de mettre à jour le paramètre directement sur l’emplacement de production, éventuellement à un moment de faible trafic. Si vous choisissez plutôt d’échanger ce paramètre en place, vous devez immédiatement mettre à jour l’emplacement de préproduction après l’échange. L’effet d’un échange pour lequel seule la préproduction a WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 est qu’il supprime le paramètre FUNCTIONS_EXTENSION_VERSION en préproduction, ce qui met l’emplacement dans un état incorrect. La mise à jour de la version de l’emplacement de préproduction juste après l’échange vous permet de restaurer vos modifications si nécessaire. Toutefois, dans une telle situation, vous devez quand même être prêt à mettre à jour directement les paramètres en production pour supprimer WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 avant le nouvel échange.

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

# OR

# Alternatively get production prepared with WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS via a swap
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
# The swap actions should be accompanied with a version specification for the slot. You may see errors from staging during the time between these actions.
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>

Une fois que l’emplacement de production a WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 configuré, vous pouvez configurer tout le reste dans l’emplacement de préproduction, puis procéder à l’échange :

# Get staging configured with WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
# Get staging configured with the new extension version
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
# For Windows function apps only, also enable .NET 6.0 that is needed by the runtime
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

# Be sure to confirm that your staging environment is working as expected before swapping.

# Swap to migrate production to the new version
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 quelques changements à prendre en considération avant de mettre à niveau une application de la version 3.x vers la version 4.x. Pour obtenir une liste complète, consultez les problèmes Azure Functions GitHub étiquetés Breaking Change: Approved (Changement cassant : Approuvé). D’autres changements sont attendus pendant la période de préversion. Abonnez-vous au flux App Service Announcements (Annonces relatives à App Service) pour obtenir des mises à jour.

Runtime

  • Azure Functions Proxies n’est plus pris en charge dans la version 4.x. Il est recommandé d’utiliser Gestion des API Azure.

  • 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 maximal sont désormais appliqués dans la version 4.x pour une application 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)

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

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

Migration de 2.x vers 3.x

Azure Functions version 3.x offre une compatibilité descendante forte avec la version 2.x. De nombreuses applications peuvent être mise à niveau sans problème vers la version 3.x, sans aucune modification du code. Bien que le passage à la version 3.x soit encouragé, effectuez néanmoins des tests intensifs avant de changer la version principale dans les applications de production.

Changements cassants entre 2.x et 3.x

Voici les changements spécifiques au langage à prendre en considération avant de mettre à niveau une application 2.x vers la version 3.x.

Lorsque vous exécutez des fonctions de la bibliothèque de classes .NET, la principale différence entre les versions se trouve au niveau du runtime .NET Core. Functions version 2.x est conçu pour s’exécuter sur .NET Core 2.2, et la version 3.x est conçue pour s’exécuter sur .NET Core 3.1.

Notes

En raison des problèmes de prise en charge de .NET Core 2.2, les applications de fonction épinglées à la version 2 (~2) s’exécutent essentiellement sur .NET Core 3.1. Pour plus d’informations, consultez Mode de compatibilité Functions v2.x.

  • Les liaisons de sortie affectées via 1.x context.done ou des valeurs de retour se comportent désormais de la même façon qu’une définition dans 2.x+ context.bindings.

  • L’objet de déclencheur de minuteur est en casse mixte au lieu de la casse Pascal

  • Les fonctions déclenchées par Event Hub avec un dataType binaire reçoivent un tableau de binary au lieu d’un tableau de string.

  • La charge utile des requêtes HTTP n’est plus accessible via context.bindingData.req. Elle néanmoins toujours accessible en tant que paramètre d’entrée, context.req, et dans context.bindings.

  • Node.js 8 n’est plus pris en charge et ne s’exécute pas dans les fonctions 3.x.

Migration de la version 1.x vers les versions ultérieures

Vous pouvez choisir de migrer une application existante écrite pour utiliser la version 1.x du runtime pour qu’elle utilise à la place une version plus récente. La plupart des modifications que vous devez apporter sont liées au runtime du langage, par exemple des modifications de l’API C# entre .NET Framework 4.8 et .NET Core. Vous devez également vous assurer que le code et les bibliothèques sont compatibles avec le runtime de langage choisi. Enfin, veillez à noter toutes les modifications soulignées ci-après qui affectent les déclencheurs, liaisons et fonctionnalités. Pour une migration plus performante, vous devez créer une application de fonction dans une nouvelle version et porter le code de la fonction existante en version 1.x vers la nouvelle application.

Bien qu’il soit possible de procéder à une mise à niveau « sur place » en mettant à jour manuellement la configuration de l’application, passer de la version 1.x à une version ultérieure implique certains changements cassants. Par exemple, en C#, l’objet de débogage passe de TraceWriter à ILogger. Quand vous créez un projet en version 3.x, vous commencez par des fonctions mises à jour basées sur les modèles de version 3.x les plus récents.

Changements dans les déclencheurs et les liaisons après la version 1.x

À compter de la version 2.x, vous devez installer dans votre application les extensions pour les déclencheurs et les liaisons spécifiques utilisés par les fonctions. La seule exception concerne les déclencheurs HTTP et de la minuterie, qui ne nécessitent aucune extension. Pour plus d’informations, voir Inscrire et installer des extensions de liaison.

Il convient également de noter quelques modifications dans function.json ou dans les attributs de la fonction entre les versions. Par exemple, la propriété path d’Event Hubs est désormais eventHubName. Consultez le tableau des liaisons existantes. Il contient des liens vers de la documentation sur chaque liaison.

Changements apportés aux fonctionnalités après la version 1.x

Quelques fonctionnalités ont été supprimées, mises à jour ou remplacées après la version 1.x. Cette section détaille les changements que vous voyez dans les versions ultérieures après avoir utilisé la version 1.x.

Les modifications suivantes ont été apportées à la version 2.x :

  • Les clés permettant d’appeler les points de terminaison HTTP sont toujours stockées et chiffrées dans le Stockage Blob Azure. Dans la version 1.x, les clés étaient stockées par défaut dans Azure Files. Au moment de mettre à niveau une application de la version 1.x à la version 2.x, les secrets existants qui se trouvent dans Azure Files sont réinitialisés.

  • La version 2.x du runtime n’intègre aucune prise en charge des fournisseurs de webhooks. Cette modification a été apportée pour améliorer les performances. Vous pouvez continuer à utiliser des déclencheurs HTTP comme points de terminaison des webhooks.

  • Le fichier de configuration d’hôte (host.json) doit être vide ou contenir la chaîne "version": "2.0".

  • Pour améliorer la surveillance, le tableau de bord WebJobs se trouvant dans le portail, qui a utilisé le paramètre AzureWebJobsDashboard, est remplacé par Azure Application Insights, qui utilise le paramètre APPINSIGHTS_INSTRUMENTATIONKEY. Pour plus d’informations, consultez Surveiller l’exécution des fonctions Azure.

  • Toutes les fonctions d’une application de fonction doivent partager le même langage. Lorsque vous créez une application de fonction, vous devez choisir une pile d’exécution pour l’application. La pile d’exécution est spécifiée par la valeur FUNCTIONS_WORKER_RUNTIME dans les paramètres de l’application. Cette exigence a été ajoutée pour améliorer l’empreinte mémoire et le temps de démarrage. Lorsque vous développez en local, vous devez également inclure ce paramètre dans le fichier local.settings.json.

  • Le délai d’expiration par défaut pour les fonctions dans un plan App Service est de 30 minutes. Vous pouvez modifier ce délai d’expiration manuellement et l’indiquer à nouveau comme étant illimité en utilisant le paramètre functionTimeout dans host.json.

  • Les limitations d’accès concurrentiel HTTP sont implémentées par défaut pour les fonctions de plan Consommation, avec une valeur par défaut de 100 requêtes simultanées par instance. Vous pouvez configurer ces limitations dans le paramètre maxConcurrentRequests du fichier host.json.

  • En raison des limitations de .NET Core, la prise en charge des fonctions de script F# (fichiers .fsx) a été supprimée. Les fonctions F# compilées (.fs) restent prises en charge.

  • Le format d’URL des webhooks de déclencheur Event Grid a été remplacé pour suivre ce modèle : https://{app}/runtime/webhooks/{triggerName}.

Versions d’une application développée en local

Vous pouvez effectuer les mises à jour suivantes sur les applications de fonction afin de changer localement les versions ciblées.

Versions du runtime Visual Studio

Dans Visual Studio, vous sélectionnez la version du runtime au moment de créer un projet. Azure Functions Tools pour Visual Studio prend en charge les trois versions majeures du runtime. La version appropriée est utilisée au moment du débogage et de la publication, en fonction des paramètres de projet. Les paramètres de version sont définis dans le fichier .csproj, dans les propriétés suivantes :

<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

Vous pouvez également choisir net6.0 ou net48 comme framework cible si vous utilisez des fonctions de processus isolé .NET. La prise en charge de net48 est actuellement en préversion.

Notes

Azure Functions 4.x nécessite que l’extension Microsoft.NET.Sdk.Functions soit au moins à la version 4.0.0.

Mise à jour des applications 2.x vers 3.x dans Visual Studio

Vous pouvez ouvrir une fonction existante ciblant 2.x et passer à 3.x en modifiant le fichier .csproj et en mettant à jour les valeurs ci-dessus. Visual Studio gère automatiquement pour vous les versions du runtime en fonction des métadonnées du projet. C’est néanmoins possible si vous n’ayez jamais créé d’application 3.x avant que Visual Studio ne dispose des modèles et du runtime pour 3.x sur votre machine. Ceci peut se présenter soi-même avec une erreur comme « Aucun runtime Functions disponible ne correspond à la version spécifiée dans le projet ». Pour récupérer les modèles et le runtime les plus récents, effectuez l’expérience de création d’un projet de fonction. Quand vous accédez à l’écran de sélection de la version et du modèle, attendez que Visual Studio termine la récupération des modèles les plus récents. Une fois les derniers modèles .NET Core 3 disponibles et affichés, vous pouvez exécuter et déboguer les projets configurés pour la version 3.x.

Important

Les fonctions en version 3.x peuvent être développées dans Visual Studio seulement si vous utilisez Visual Studio version 16.4 ou ultérieure.

VS Code et Azure Functions Core Tools

Azure Functions Core Tools est utilisé pour développer la ligne de commande, ainsi que par l’extension Azure Functions pour Visual Studio Code. Pour développer pour la version 3.x, installez la version 3.x de Core Tools. Le développement en version 2.x nécessite la version 2.x de Core Tools, etc. Pour plus d’informations, voir Installer Azure Functions Core Tools.

Pour un développement avec Visual Studio Code, vous devrez peut-être également mettre à jour le paramètre utilisateur pour azureFunctions.projectRuntime afin qu’il corresponde à la version des outils installés. Ce paramètre met également à jour les modèles et les langages utilisés lors de la création de l’application de fonction. Pour créer des applications dans ~3, vous devez mettre à jour le paramètre utilisateur azureFunctions.projectRuntime sur ~3.

Azure Functions extension runtime setting

Applications Maven et Java

Vous pouvez migrer des applications Java de la version 2.x vers la version 3.x en installant la version 3.x de Core Tools nécessaire pour une exécution locale. Après avoir vérifié que votre application fonctionne correctement en local sur la version 3.x, mettez à jour le fichier POM.xml de l’application en changeant le paramètre FUNCTIONS_EXTENSION_VERSION en ~3, 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>~3</value>
        </property>
    </appSettings>
</configuration>

Liaisons

À compter de la version 2.x, le runtime utilise un nouveau modèle d’extensibilité de liaison qui présente les avantages suivants :

  • Prise en charge pour les extensions de liaison de tiers.

  • Découplage du runtime et des liaisons. Cela permet de gérer les versions des extensions de liaison et leur publication de façon indépendante. Vous pouvez, par exemple, choisir de mettre à niveau vers une version d’une extension qui s’appuie sur une version plus récente d’un kit de développement logiciel (SDK) sous-jacent.

  • Un environnement d’exécution plus léger, où seules les liaisons en cours d’utilisation sont connues et chargées par le runtime.

À l’exception des déclencheurs HTTP et de la minuterie, toutes les liaisons doivent être explicitement ajoutées au projet d’application de fonction, ou enregistrées dans le portail. Pour plus d’informations, voir Inscrire des extensions de liaison.

Le tableau suivant indique les liaisons prises en charge dans chaque version du runtime.

Ce tableau présente les liaisons qui sont prises en charge dans les versions majeures du runtime Azure Functions :

Type 1.x 2.x et ultérieures1 Déclencheur Entrée Output
Stockage Blob
Azure Cosmos DB
Azure SQL (préversion)
Dapr3
Event Grid
Hubs d'événements
HTTP webhooks
IoT Hub
Kafka2
Mobile Apps
Notification Hubs
Stockage File d’attente
RabbitMQ2
SendGrid
Service Bus
SignalR
Stockage Table
Minuteur
Twilio

1 À compter du runtime de la version 2.x, toutes les liaisons à l’exception de HTTP et du minuteur doivent être inscrites. Consultez Inscrire des extensions de liaison.

2 Les déclencheurs ne sont pas pris en charge dans le plan Consommation. Nécessite des déclencheurs basés sur le runtime.

3 Pris en charge uniquement dans Kubernetes, IoT Edge et d’autres modes autohébergés uniquement.

Durée du délai d’expiration du conteneur de fonctions

La durée d’expiration d’une application de fonction est définie par la propriété functionTimeout dans le fichier projet functionTimeout. Le tableau suivant indique les valeurs par défaut et maximales (en minutes) pour des plans spécifiques :

Plan Default Maximum1
Plan de consommation 5 10
Plan Premium 302 Illimité
Plan dédié 302 Illimité

1 Quel que soit le paramètre de délai d’expiration du conteneur de fonctions, 230 secondes est le temps maximum que peut prendre une fonction déclenchée via HTTP pour répondre à une demande. Cela est dû au délai d’inactivité par défaut d’Azure Load Balancer. Pour des temps de traitement plus longs, pensez à utiliser un modèle asynchrone Durable Functions ou différez le travail actuel et renvoyez une réponse immédiate.
2 Le délai d’expiration par défaut pour la version 1.x du runtime Functions est illimité.

Étapes suivantes

Pour plus d’informations, consultez les ressources suivantes :