Share via


Différences entre le modèle Worker isolé et le modèle in-process pour .NET sur Azure Functions

Il existe deux modèles d’exécution pour les fonctions .NET :

Modèle d’exécution Description
Modèle de worker isolé 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.
Modèle in-process Le code de votre fonction s’exécute dans le même processus que le processus hôte Functions. Prend uniquement en charge les versions LTS (Long Term Support) de .NET. Pour plus d’informations, consultez Développer des fonctions de bibliothèque de classes .NET.

Important

La prise en charge du modèle in-process prendra fin le 10 novembre 2026. Pour continuer à bénéficier d’une prise en charge complète, nous vous recommandons vivement de migrer vos applications vers le modèle worker isolé.

Cet article décrit l’état actuel des différences fonctionnelles et comportementales entre les deux modèles. Pour migrer du modèle in-process vers le modèle de travail isolé, consultez Migrer des applications .NET du modèle in-process vers le modèle de travail isolé.

Tableau de comparaison des modèles d’exécution

Utilisez le tableau suivant pour comparer les différences fonctionnelles et fonctionnelles entre les deux modèles :

Fonctionnalité/Comportement Modèle de worker isolé Modèle in-process3
Versions .NET prises en charge Versions du support à long terme (LTS)
Versions de support à durée Standard (STS),
.NET Framework
Versions du support à long terme (LTS) 6
Packages principaux Microsoft.Azure.Functions.Worker
Microsoft.Azure.Functions.Worker.Sdk
Microsoft.NET.Sdk.Functions
Packages d’extension de liaison Microsoft.Azure.Functions.Worker.Extensions.* Microsoft.Azure.WebJobs.Extensions.*
Fonctions durables Pris en charge Pris en charge
Types de modèles exposés par des liaisons Types simples
Types sérialisables JSON
Tableaux/énumérations
Types de kit de développement logiciel (SDK) de service4
Types simples
Types sérialisables JSON
Tableaux/énumérations
Types de kit de développement logiciel (SDK) de service4
Types de modèles de déclencheur HTTP HttpRequestData / HttpResponseData
HttpRequest / IActionResult (à l’aide de l’intégration ASP.NET Core)5
HttpRequest / IActionResult5
HttpRequestMessage / HttpResponseMessage
Interactions de liaison de sortie Renvoie les valeurs dans un modèle étendu avec :
– sorties simples ou multiples
– tableaux de sorties
Valeurs de retour (sortie unique uniquement),
out paramètres,
IAsyncCollector
Liaisons impératives1 Non pris en charge : au lieu de cela, utiliser directement les types de SDK Pris en charge
Injection de dépendances Pris en charge (modèle amélioré cohérent avec l'écosystème .NET) Pris en charge
Middleware Pris en charge Non prise en charge
Journalisation ILogger<T>/ILogger obtenu à partir de FunctionContext ou via l’injection de dépendances ILogger transmis à la fonction
ILogger<T> via l’injection de dépendances
Dépendances d’Application Insights Pris en charge Pris en charge
Jetons d’annulation Pris en charge Pris en charge
Temps de démarrage à froid2 Optimisations configurables Optimisée
ReadyToRun Pris en charge Pris en charge

1 Lorsque vous devez interagir avec un service à l’aide de paramètres déterminés au moment de l’exécution, l’utilisation directe des Kits de développement logiciel (SDK) de service correspondants est recommandée à l’aide de liaisons impératives. Les Kits de développement logiciel (SDK) sont moins détaillés, couvrent plus de scénarios et présentent des avantages pour la gestion des erreurs et le débogage. Cette recommandation s’applique aux deux modèles.

2 Le temps de démarrage à froid peut être également affecté sur Windows lors de l’utilisation de certaines préversions de .NET en raison du chargement juste-à-temps des frameworks de préversion. Elles ont un impact sur les modèles In-process et Out-of-process, mais cela peut être négligeable lorsque vous comparez différentes versions. Ce retard pour les préversions n’est pas présent sur les plans Linux.

3 Les fonctions de script C# s’exécutent également in-process et utilisent les mêmes bibliothèques que les fonctions de bibliothèque de classes in-process. Pour plus d’informations, consultez la référence du développeur Azure Functions script C# (.csx).

4 Les types de kit de développement logiciel (SDK) de service incluent les types du SDK Azure pour .NET , tels que BlobClient.

5 Les types ASP.NET Core ne sont pas pris en charge pour .NET Framework.

6 .NET 8 n’est pas encore pris en charge sur le modèle In-process, bien qu’il soit disponible sur le modèle Worker isolé. Pour plus d’informations sur les plans .NET 8, y compris les options futures du modèle In-process, consultez le billet de mise à jour de la feuille de route Azure Functions.

Versions prises en charge

Les versions du runtime Functions prend en charge des versions spécifiques de .NET. Pour en savoir plus sur les versions de Functions, consultez Vue d’ensemble des versions du runtime Azure Functions. La prise en charge des versions varie également selon que vos fonctions s’exécutent in-process ou dans des processus Worker isolés.

Notes

Pour savoir comment modifier la version du runtime Functions utilisée par votre application de fonction, consultez Afficher et mettre à jour la version actuelle du runtime.

Le tableau suivant indique le niveau le plus élevé de .NET ou .NET Framework pouvant être utilisé avec une version spécifique de Functions.

Version du runtime Functions Modèle de worker isolé Modèle in-process5
Functions 4.x1 .NET 8.0
.NET 6.02
.NET Framework 4.83
.NET 6.02
Functions 1.x4 n/a .NET Framework 4.8

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

2 .NET 6 atteint la fin du support officiel le 12 novembre 2024.

3 Le processus de génération nécessite également le kit de développement logiciel (SDK) .NET.

4 La prise en charge de la version 1.x du runtime Azure Functions prend fin le 14 septembre 2026. Pour plus d’informations, lisez cette annonce relative à la prise en charge. Pour une prise en charge complète continue, vous devez migrer vos applications vers la version 4.x.

5 La prise en charge du modèle in-process prendra fin le 10 novembre 2026. Pour plus d’informations, lisez cette annonce relative à la prise en charge. Pour continuer à bénéficier d’une prise en charge complète, vous devez migrer vos applications vers le modèle worker isolé.

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.

Étapes suivantes