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) jusqu’à .NET 8 |
| 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 fonctionILogger<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 |
| [Consommation flexible] | Pris en charge | Non 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.
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 9.0 (préversion) .NET 8.0 .NET 6.02 .NET Framework 4.83 |
.NET 8.0 .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.