Partage via

Vue d’ensemble des versions du runtime Azure Functions

  • Article

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

Version Niveau de support Description
4.x GA Version d’exécution recommandée pour les fonctions dans toutes les langues. Consultez les versions de langue prises en charge.
1.x GA (fin du support le 14 septembre 2026) Pris en charge uniquement pour les applications C# qui doivent utiliser .NET Framework. Cette version est en mode maintenance, et les améliorations ne seront apportées que dans les versions ultérieures. La prise en charge prendra fin pour la version 1.x le 14 septembre 2026. Nous vous recommandons vivement de migrer vos applications vers la version 4.x, qui prend en charge .NET Framework 4.8, .NET 6, .NET 8 et .NET 9.

Important

Depuis le 13 décembre 2022, les applications de fonction exécutées sur les versions 2.x et 3.x du runtime Azure Functions ont atteint la fin du support étendu. Si vous souhaitez obtenir plus d’informations, consultez Versions mises hors services.

Cet article détaille certaines des différences entre les versions prises en charge, 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 peut pas être modifié lorsqu’il existe des fonctions existantes.

Le tableau suivant présente les versions .NET prises en charge par Azure Functions. Sélectionnez votre langage de développement préféré en haut de l’article.

La version prise en charge de .NET dépend à la fois de la version de votre runtime Functions et du modèle d'exécution que vous avez choisi :

Le code de votre fonction s’exécute dans un processus Worker .NET distinct. Utilisez avec les versions prises en charge de .NET et .NET Framework. Pour plus d’informations, consultez Développer les fonctions de processus Worker isolé .NET.

Version prise en charge Niveau de support Date de fin de vie attendue de la communauté
.NET 9 Aperçu Consulter la stratégie
.NET 8 GA 10 novembre 2026
.NET 6 GA 12 novembre 2024
.NET Framework 4.8.1 GA Consulter la stratégie

.NET 7 était précédemment pris en charge sur le modèle de Worker isolé, mais il a atteint la fin du support officiel le 14 mai 2024.

Pour plus d’informations, consultez Guide pour l’exécution d’Azure Functions C# dans un processus Worker isolé.

Le tableau suivant présente les versions des langages prises en charge pour les fonctions Java. Sélectionnez votre langage de développement préféré en haut de l’article.

Version prise en charge Niveau de support Date de fin de vie attendue de la communauté
Java 21 (Linux uniquement) Aperçu Septembre 2028
Java 17 GA Septembre 2027
Java 11 GA Septembre 2027
Java 8 GA 30 novembre 2026

Pour plus d’informations, consultez le Guide des développeurs Java pour Azure Functions.

Le tableau suivant présente les versions des langages prises en charge pour les fonctions Node.js. Sélectionnez votre langage de développement préféré en haut de l’article.

Version prise en charge Niveau de support Date de fin de vie attendue de la communauté
Node.js 22 Aperçu 30 avril 2027
Node.js 20 GA 30 avril 2026
Node.js 18 GA 30 avril 2025

TypeScript est pris en charge via la transpilation vers JavaScript. Pour plus d’informations, consultez le Guide des développeurs Node.js sur Azure Functions.

Le tableau suivant présente les versions des langages prises en charge pour les fonctions PowerShell. Sélectionnez votre langage de développement préféré en haut de l’article.

Version prise en charge Niveau de support Date de fin de vie attendue de la communauté
PowerShell 7.4 GA 10 novembre 2026
PowerShell 7.2 GA 8 novembre 2024

Pour plus d'informations, consultez le Guide des développeurs PowerShell sur Azure Functions.

Le tableau suivant présente les versions des langages prises en charge pour les fonctions Python. Sélectionnez votre langage de développement préféré en haut de l’article.

Version prise en charge Niveau de support Date de fin de vie attendue de la communauté
Python 3.11 GA Octobre 2027
Python 3.10 GA Octobre 2026
Python 3.9 GA Octobre 2025
Python 3.8 GA Octobre 2024

Pour plus d'informations, consultez le Guide des développeurs Python sur Azure Functions.

Pour plus d’informations sur les modifications prévues sur la prise en charge des langages, consultez la Feuille de route Azure.

Pour découvrir d’autres informations sur les versions des langages des versions précédemment prises en charge du runtime Functions, consultez Versions du runtime mises hors service.

Exécuter sur une version spécifique

La version du runtime Functions utilisée par les applications publiées dans Azure dépend du paramètre d’application FUNCTIONS_EXTENSION_VERSION. Dans certains cas et pour certains langages, d’autres paramètres peuvent s’appliquer.

Par défaut, les applications de fonction créées dans le Portail Azure, par l’interface Azure CLI ou à partir des outils Visual Studio, 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. La mise à jour vers une version majeure ultérieure est autorisée même pour les applications qui ont des fonctions existantes.

Migration des applications de fonction existantes

Lorsque votre application comporte des fonctions existantes, vous devez prendre des précautions avant de passer à une version majeure plus récente du runtime. Les articles suivants détaillent les changements cassants entre les versions majeures, y compris les changements cassants spécifiques aux langages. On vous fournit également des instructions pas à pas pour une migration réussie de votre application de fonction existante.

Changement de la version des applications dans Azure

Les valeurs des versions majeures du runtime suivantes sont utilisées :

Valeur Cible du runtime
~4 4.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. Pour les applications de fonction existantes, suivez les instructions de migration.

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

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 le fichier de configuration lié.

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": "[4.0.0, 5.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": "[4.0.0, 5.0.0)"
    }
}

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

Versions supprimées

Important

La prise en charge de la version 1.x du runtime Azure Functions prendra fin le 14 septembre 2026. Nous vous recommandons fortement de migrer vos applications vers la version 4.x pour bénéficier d’une prise en charge complète.

Ces versions du runtime Functions ont atteint la fin du support étendu le 13 décembre 2022.

Version Niveau de prise en charge actuelle Niveau de prise en charge précédent
3.x Hors prise en charge GA
2.x Hors prise en charge GA

Dès que possible, vous devez migrer vos applications vers la version 4.x pour bénéficier d’une prise en charge complète. Pour obtenir un ensemble complet d’instructions de migration spécifiques à un langage, consultez Migrer des applications vers Azure Functions version 4.x.

Les applications utilisant les versions 2.x et 3.x peuvent toujours ê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 interrompre les modifications. Toutefois, vos applications ne sont pas éligibles aux nouvelles fonctionnalités, aux correctifs de sécurité et à l’optimisation des performances. Vous ne pouvez obtenir le support du service associé qu’après avoir mis à niveau vos applications vers la version 4.x.

La fin de la prise en charge des versions 2.x et 3.x est due à la fin de la prise en charge de .NET Core 3.1, qu’elles avaient comme injection de dépendances. Cette exigence concerne toutes les langues prises en charge par Azure Functions.

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. Les outils Azure Functions pour Visual Studio prennent 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>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

Si vous utilisez le modèle de Worker isolé, vous pouvez choisir net8.0, net6.0, ou net48 comme framework cible. Vous pouvez également choisir d’utiliser la prise en charge de la préversion pour net9.0. Si vous utilisez le modèle in-process, vous pouvez choisir net8.0 ou net6.0 et vous devez inclure l’extension Microsoft.NET.Sdk.Functions définie sur au moins 4.4.0.

.NET 7 était précédemment pris en charge sur le modèle de Worker isolé, mais il a atteint la fin du support officiel le 14 mai 2024.

Visual Studio 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 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.

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.x1 2.x et ultérieur2 Déclencheur Entrée Output
Stockage Blob ✔ ✔ ✔ ✔ ✔
Azure Cosmos DB ✔ ✔ ✔ ✔ ✔
Explorateur de données Azure ✔ ✔ ✔
Azure SQL ✔ ✔ ✔ ✔
Dapr4 ✔ ✔ ✔ ✔
Event Grid ✔ ✔ ✔ ✔
Hubs d'événements ✔ ✔ ✔ ✔
HTTP et Webhooks ✔ ✔ ✔ ✔
IoT Hub ✔ ✔ ✔
Kafka3 ✔ ✔ ✔
Mobile Apps ✔ ✔ ✔
Notification Hubs ✔ ✔
Stockage File d’attente ✔ ✔ ✔ ✔
Redis ✔ ✔
RabbitMQ3 ✔ ✔ ✔
SendGrid ✔ ✔ ✔
Service Bus ✔ ✔ ✔ ✔
SignalR ✔ ✔ ✔ ✔
Stockage Table ✔ ✔ ✔ ✔
Minuteur ✔ ✔ ✔
Twilio ✔ ✔ ✔

Remarques :

  1. La prise en charge de la version 1.x du runtime Azure Functions prendra fin le 14 septembre 2026. Nous vous recommandons fortement de migrer vos applications vers la version 4.x pour bénéficier d’une prise en charge complète.
  2. À 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.
  3. Les déclencheurs ne sont pas pris en charge dans le plan Consommation. Nécessite des déclencheurs basés sur le runtime.
  4. Pris en charge dans Kubernetes, IoT Edge et d’autres modes auto-hébergés uniquement.

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

La durée du délai d’expiration pour les fonctions d’une application de fonction est définie par la propriété functionTimeout dans le fichier projet host.json. Cette propriété s’applique spécifiquement aux exécutions de fonction. Une fois que le déclencheur démarre l’exécution d’une fonction, la fonction doit retourner/répondre dans la durée du délai d’expiration. Pour éviter les délais d’expiration, il est important d’écrire des fonctions robustes. Pour plus d’informations, consultez Améliorer les performances et la fiabilité d’Azure Functions.

Le tableau suivant indique les valeurs par défaut et maximales (en minutes) pour des plans spécifiques :

Plan Default Maximum1
Plan Consommation flexible 30 Illimité2
Plan Premium 304 Illimité2
Plan dédié 304 Illimité3
Applications de conteneur 30 Illimité5
Plan Consommation 5 10
  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. Il n’existe aucun délai maximal d’expiration d’exécution appliqué. Toutefois, la période de grâce donnée à une exécution de fonction est de 60 minutes pendant le scale-in pour les plans Consommation flexible et Premium, et une période de grâce de 10 minutes est donnée pendant les mises à jour de la plateforme.
  3. Nécessite que le plan App Service soit défini sur Always On. Une période de grâce de 10 minutes est donnée pendant les mises à jour de la plateforme.
  4. Le délai d’expiration par défaut pour la version 1.x du runtime Functions est illimité.
  5. Lorsque le nombre minimal de réplicas est défini sur zéro, le délai d’expiration par défaut dépend des déclencheurs spécifiques utilisés dans l’application.

Étapes suivantes

Pour plus d’informations, consultez les ressources suivantes :