Partager via

Quand choisir .NET Framework pour les conteneurs Docker

Conseil / Astuce

Ce contenu est un extrait du livre électronique 'Architecture des microservices .NET pour les applications .NET conteneurisées', disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement, lisible hors ligne.

Télécharger le PDF

Architecture de microservices .NET pour les applications .NET conteneurisées - vignette de couverture du livre électronique.

Bien que .NET 8 offre des avantages significatifs pour les nouvelles applications et les modèles d’application, .NET Framework continuera d’être un bon choix pour de nombreux scénarios existants.

Migration directe d’applications existantes vers un conteneur Windows Server

Vous pouvez utiliser des conteneurs Docker simplement pour simplifier le déploiement, même si vous ne créez pas de microservices. Par exemple, vous souhaitez peut-être améliorer votre flux de travail DevOps avec Docker : les conteneurs peuvent vous donner de meilleurs environnements de test isolés et peuvent également éliminer les problèmes de déploiement causés par des dépendances manquantes lorsque vous passez à un environnement de production. Dans les cas comme ceux-ci, même si vous déployez une application monolithique, il est judicieux d’utiliser Docker et des conteneurs Windows pour vos applications .NET Framework actuelles.

Dans la plupart des cas pour ce scénario, vous n’aurez pas besoin de migrer vos applications existantes vers .NET 8 ; vous pouvez utiliser des conteneurs Docker qui incluent le .NET Framework traditionnel. Toutefois, une approche recommandée consiste à utiliser .NET 8 lors de l’extension d’une application existante, telle que l’écriture d’un nouveau service dans ASP.NET Core.

L’utilisation de bibliothèques .NET tierces ou de packages NuGet non disponibles pour .NET 8

Les bibliothèques tierces adoptent rapidement .NET Standard, ce qui permet le partage de code entre toutes les versions de .NET, notamment .NET 8. Avec .NET Standard 2.0 et versions ultérieures, la compatibilité de l’aire d’API entre différents frameworks est devenue beaucoup plus grande. Plus encore, .NET Core 2.x et les applications plus récentes peuvent également référencer directement des bibliothèques .NET Framework existantes (voir .NET Framework 4.6.1 prenant en charge .NET Standard 2.0).

En outre, le pack de compatibilité Windows étend la surface d’API disponible pour .NET Standard 2.0 sur Windows. Ce pack permet de recompiler la plupart du code existant vers .NET Standard 2.x avec peu ou pas de modification, à s’exécuter sur Windows.

Toutefois, même avec cette progression exceptionnelle depuis .NET Standard 2.0 et .NET Core 2.1 ou version ultérieure, il peut arriver que certains packages NuGet nécessitent l’exécution de Windows et ne prennent pas en charge .NET Core ou version ultérieure. Si ces packages sont essentiels pour votre application, vous devez utiliser .NET Framework sur les conteneurs Windows.

Utilisation des technologies .NET qui ne sont pas disponibles pour .NET 8.

Certaines technologies .NET Framework ne sont pas disponibles dans .NET 8. Certains d’entre eux peuvent devenir disponibles dans les versions ultérieures, mais d’autres ne correspondent pas aux nouveaux modèles d’application ciblés par .NET Core et peuvent ne jamais être disponibles.

La liste suivante présente la plupart des technologies qui ne sont pas disponibles dans .NET 8 :

  • ASP.NET Web Forms. Cette technologie est disponible uniquement sur .NET Framework. Actuellement, il n’existe aucun plan d’apporter ASP.NET Web Forms à .NET ou version ultérieure.

  • Services liés au flux de travail. Windows Workflow Foundation (WF), Les services de flux de travail (WCF + WF dans un seul service) et WCF Data Services (anciennement appelés services de données ADO.NET) ne sont disponibles que sur .NET Framework. Il n’existe actuellement aucun plan pour les amener à .NET 8.

Outre les technologies répertoriées dans la feuille de route .NET officielle, d’autres fonctionnalités peuvent être transférées vers la nouvelle plateforme .NET unifiée. Vous pouvez envisager de participer aux discussions sur GitHub afin que votre voix puisse être entendue. Et si vous pensez qu’un problème est manquant, créez un nouveau problème dans le dépôt GitHub dotnet/runtime .

Utilisation d’une plateforme ou d’une API qui ne prend pas en charge .NET 8

Certaines plateformes Microsoft et tierces ne prennent pas en charge .NET 8. Par exemple, certains services Azure fournissent un Kit de développement logiciel (SDK) qui n’est pas encore disponible pour la consommation sur .NET 8. La plupart des sdk Azure doivent éventuellement être portés vers .NET 8/.NET Standard, mais certains peuvent ne pas être pour plusieurs raisons. Vous pouvez voir les Kits de développement logiciel (SDK) Azure disponibles dans la page Dernières versions du Kit de développement logiciel (SDK) Azure .

En attendant, si une plateforme ou un service dans Azure ne prend toujours pas en charge .NET 8 avec son API cliente, vous pouvez utiliser l’API REST équivalente à partir du service Azure ou du Kit de développement logiciel (SDK) client sur .NET Framework.

Portage de l’application ASP.NET existante vers .NET 8

.NET Core est une étape révolutionnaire du .NET Framework. Il offre un grand nombre d’avantages par rapport à .NET Framework dans l'ensemble, de la productivité aux performances, et de la prise en charge multiplateforme jusqu'à la satisfaction des développeurs.

Ressources supplémentaires

PrécédentSuivant