Partager via

Quand choisir .NET Framework pour les conteneurs Docker

  • Article

Conseil

Ce contenu est un extrait du livre électronique « .NET Microservices Architecture for Containerized .NET Applications », disponible sur .NET Docs ou sous forme de PDF téléchargeable gratuitement et pouvant être lu hors ligne.

Télécharger le PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

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

Migration d’applications existant directement dans un conteneur Windows Server

Vous pouvez utiliser des conteneurs Docker uniquement 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 offrir des environnements de test mieux isolés et même éliminer les problèmes de déploiement liés à des dépendances manquantes au moment de passer à un environnement de production). En pareil cas, même si vous déployez une application monolithique, il est judicieux d’utiliser des conteneurs Docker et Windows pour vos applications .NET Framework actuelles.

Dans la plupart des cas, pour ce scénario, vous n’avez pas besoin de migrer vos applications existantes vers .NET 8 ; vous pouvez utiliser des conteneurs Docker qui incluent le .NET Framework classique. En revanche, il est recommandé d’utiliser .NET 8 si l’objectif est d’étendre une application existante, par exemple en développant un nouveau service dans ASP.NET Core.

Utilisation de bibliothèques .NET ou de packages NuGet tiers non disponibles pour .NET 8

Les bibliothèques tierces adoptent rapidement .NET Standard, ce qui permet de partager du code entre toutes les versions de .NET, dont .NET 8. Avec .NET Standard 2.0 et versions ultérieures, la compatibilité de surface 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 les 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 de modifications ou aucune, pour s’exécuter sur Windows.

Cependant, malgré cette progression exceptionnelle depuis .NET Standard 2.0 et .NET Core 2.1 ou ultérieur, certains packages NuGet peuvent avoir besoin que Windows s’exécute et peuvent ne pas prendre en charge .NET Core ou ultérieur. Si ces packages sont indispensables à votre application, vous devez utiliser le .NET Framework dans des conteneurs Windows.

Utilisation de technologies .NET non disponibles pour .NET 8

Certaines technologies .NET Framework ne sont pas disponibles dans .NET 8. Certaines d’entre elles peuvent devenir disponibles dans les prochaines versions, tandis que d’autres, qui ne s’appliquent pas aux nouveaux modèles d’application ciblés par .NET Core, risquent de ne jamais l’être.

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

  • Web Forms ASP.NET : cette technologie est disponible uniquement sur le .NET Framework. Il n’est pas prévu d’intégrer Web Forms ASP.NET à .NET ou ultérieur.

  • Services liés aux flux de travail : Windows Workflow Foundation (WF), les services de flux de travail (WCF + WF dans un seul service) et WCF Data Services (anciennement ADO.NET Data Services) sont disponibles uniquement sur le .NET Framework. Il n’est actuellement pas prévu de les intégrer à .NET 8.

En plus des technologies listées dans la feuille de route .NET officielle, d’autres fonctionnalités pourraient être portées vers la nouvelle plateforme .NET unifiée. Participez éventuellement aux discussions sur GitHub pour faire entendre votre voix. Et si vous pensez que quelque chose fait défaut, enregistrez 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 ou tierces ne prennent pas en charge .NET 8. Par exemple, certains services Azure fournissent un SDK qui n’est pas encore utilisable dans .NET 8. La plupart des SDK Azure finiront par être portés vers .NET 8/.NET Standard, mais certains ne pourront peut-être pas l’être pour plusieurs raisons. Vous pouvez voir les SDK Azure disponibles dans la page Dernières versions des SDK Azure.

En attendant, si une plateforme ou un service Azure ne prend toujours pas en charge .NET 8 avec son API cliente, vous pouvez utiliser l’API REST équivalente du service Azure ou le SDK client de .NET Framework.

Portage d’applications ASP.NET existantes vers .NET 8

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

Ressources supplémentaires

PrécédentSuivant