Partager via

Vue d’ensemble des versions du runtime Azure Functions

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 Descriptif
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 (la prise en charge prend 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 pour la version 1.x prendra fin 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 8, .NET 9 et .NET 10 Preview.

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 la prise en charge étendue. Pour 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.

Langues

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.

Veillez à sélectionner votre langage de développement préféré en haut de l’article.

Le tableau suivant présente les versions .NET prises en charge par Azure Functions.

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 sélectionné.

Le code de votre application de 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 Guide d’exécution d’Azure Functions C# dans le modèle worker isolé.

Version prise en charge Niveau de support Date de fin de support attendue
.NET 10 GA 14 novembre 2028.
.NET 9 GA 10 novembre 20261
.NET 8 GA 10 novembre 2026
.NET Framework 4.8.1 GA Consultez Stratégie de prise en charge du .NET Framework.

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

.NET 6 était précédemment pris en charge par le modèle de Worker isolé, mais a atteint la fin du support officiel le 12 novembre 2024.

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

Pour plus d’informations, consultez Guide d’exécution d’Azure Functions C# dans le modèle worker isolé.

Le tableau suivant présente les versions des langages prises en charge pour les applications de fonction Java :

Version prise en charge Niveau de support Pris en charge jusqu’à
Java 25 Preview En attente*
Java 21 GA Consultez la Feuille de route de mise en production et de maintenance.
Java 17 GA Consultez la Feuille de route de mise en production et de maintenance.
Java 11 GA Consultez la Feuille de route de mise en production et de maintenance.
Java 8 GA Consultez la Page de support de Temurin.

*La date de fin de prise en charge de Java 25 est déterminée lorsque la disponibilité générale est déclarée.

Pour plus d’informations sur le développement et l’exécution d’applications de fonctions Java, consultez le Guide des développeurs Java sur Azure Functions.

Le tableau suivant présente les versions des langages prises en charge pour les applications de fonction Node.js :

Version prise en charge Niveau de support Date de fin de support attendue
Node.js 24 Preview 30 avril 2028
Node.js 22 GA 30 avril 2027
Node.js 20 GA 30 avril 2026

TypeScript est pris en charge via la transpilation en 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 applications de fonction PowerShell :

Version prise en charge Niveau de support Date de fin de support attendue
PowerShell 7.4 GA 10 novembre 2026

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

Le tableau suivant présente les versions de langages prises en charge pour les applications de fonction Python :

Version prise en charge Niveau de support Date de fin de support attendue
Python 3.13 GA Octobre 2029
Python 3.12 GA Octobre 2028
Python 3.11 GA Octobre 2027
Python 3.10 GA Octobre 2026

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

Pour plus d’informations sur les modifications planifiées apportées à la prise en charge linguistique, consultez les mises à jour de la feuille de route Azure.

Pour plus d’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, notamment les changements cassants spécifiques à un langage. On vous fournit également des instructions pas à pas pour une migration réussie de votre application de fonction existante.

Modification 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 que votre application de fonction peut avoir lors de l’exécution sur la dernière version principale, vous devez épingler temporairement votre application à une version mineure spécifique. L’épinglage 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 bundle d’extensions dans le 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 concernant la version de votre offre groupée d’extensions ne répondant pas à une version minimale requise, mettez à jour votre référence d’offre groupée d’extensions existante dans l' 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 vivement 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 support GA
2.x Hors support 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. Par ailleurs, 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 niveaux de performance. Vous ne pouvez bénéficier de la prise en charge des services associés qu’après avoir mis à niveau vos applications vers la version 4.x.

Les versions 2.x et 3.x ne sont plus prises en charge en raison de la fin de la prise en charge de .NET Core 3.1, qui était une dépendance principale. 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 deux 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 net9.0, net8.0 ou net48 en tant qu’infrastructure cible. Vous pouvez également choisir d’utiliser la prise en charge de préversion pour net10.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 10 n'est pas pris en charge par le modèle en cours de traitement ; si vous utilisez le modèle en cours de traitement et souhaitez utiliser .NET 10, migrez votre application vers le modèle de travail isolé.

.NET 6 était auparavant pris en charge sur le modèle de travailleur isolé et le modèle en cours de processus, mais il a atteint la fin du support officiel le 12 novembre 2024. .NET 7 était pris en charge sur le modèle de Worker isolé, mais 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 le développement Visual Studio Code, vous devrez peut-être également mettre à jour le paramètre utilisateur pour qu’il azureFunctions.projectRuntime 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 des extensions de liaison non Microsoft.

  • 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, consultez les modèles d’expression de liaison Azure Functions.

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 versions ultérieures2 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 ✔ ✔ ✔
Applications mobiles ✔ ✔ ✔
Protocole de contexte de modèle ✔ ✔
Notification Hubs ✔ ✔
Stockage de files d’attente ✔ ✔ ✔ ✔
Redis ✔ ✔ ✔ ✔
RabbitMQ3 ✔ ✔ ✔
SendGrid ✔ ✔ ✔
Service Bus ✔ ✔ ✔ ✔
Azure SignalR Service ✔ ✔ ✔ ✔
Stockage de table ✔ ✔ ✔ ✔
Minuteur ✔ ✔ ✔
Twilio ✔ ✔ ✔

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

2 À partir de la version 2.x du runtime, toutes les liaisons, à l'exception de HTTP et du minuteur, doivent être enregistrées. Consultez Enregistrer les extensions de liaison Azure Functions.

3 Les déclencheurs ne sont pas pris en charge dans le plan de consommation. Ce type de liaison nécessite des déclencheurs pilotés par l'exécution.

4 Ce type de liaison est pris en charge uniquement dans Kubernetes, Azure IoT Edge et d’autres modes auto-hébergés.

Durée du délai d’expiration de l’application de fonction

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 a démarré l’exécution d’une fonction, la fonction doit retourner/répondre dans les limites 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 Par défaut Maximum1
Plan Consommation flexible 30 Illimité2
Plan Premium 304 Illimité2
Plan Dédié 304 Illimité3
Container Apps 30 Illimité5
Plan de consommation 5 10
  1. Quel que soit le paramètre de délai d’expiration de l’application de fonction, 230 secondes est le temps maximum que peut prendre une fonction déclenchée via HTTP pour répondre à une requête. 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. Aucun délai maximal d’expiration d’exécution n’est 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 hôte 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.

Les valeurs de ce tableau supposent que le processus hôte Azure Functions a démarré et s’exécute correctement. Un délai d’expiration maximal de 60 secondes est autorisé pour que le processus Worker propre au langage démarre également. Le délai d’expiration du processus de travail n’est actuellement pas configurable.

Contenu connexe

Pour plus d’informations, consultez les ressources suivantes :

  • Last updated on