Comme premier article de 2016, j’ai décidé de décrire les évolutions qui ont lieu actuellement sur le framework .NET. Il ne s’agit pas d’un how-to, et je ne propose pas de nouvelles informations. Il y a beaucoup d’informations à recouper pour s’y retrouver dans la nouvelle trajectoire qu’a choisi Microsoft pour adapter son framework au marché pour les prochaines années. Cet article a pour but de proposer un tour d’horizon, de mon point de vue en tant que développeur, sur les récentes annonces faites autour de .NET.

Mise à jour du 23 janvier 2016
Le nom officiel d’ASP.NET 5 devient ASP.NET Core 1.0. Le but est de montrer que cette nouvelle version n’est pas une évolution d’ASP.NET 4 actuel mais bien un nouveau départ, basé sur le nouveau framework .NET Core.

Il s’agit encore d’un chantier en cours, manifestement le plus ambitieux pour .NET depuis de nombreuses années car il affecte un très grand nombre d’équipes et de projets différents de l’écosystème .NET, sans compter évidemment l’impact sur la communauté des développeurs et sur les entreprises. Il est en fait préparé par Microsoft depuis plusieurs années, probablement dès 2008! La trajectoire était-elle aussi claire à l’époque qu’elle le semble aujourd’hui ? Difficile à dire.

En 2015, nous avons vu exploser ces différents projets dont les premiers signes étaient clairement visibles dès 2014. C’est sans aucun doute en partie lié à l’arrivée de Satya Nadella au poste de CEO de Microsoft début 2014.

Toujours en 2015, Microsoft a fièrement annoncé l’ouverture de .NET à la communauté open source. Pour une telle entreprise, ce n’est pas une petite annonce.

Je tiens à préciser que cet article reflète uniquement des interprétations et opinions personnelles. Il en va de même pour le reste du blog mais je préfère le souligner ici à cause des extrapolations que je me permet de faire. Enfin, hormis le fait que cet article puisse contenir des erreurs, gardez en tête que certaines fonctionnalités, ou certains noms (espaces de noms, nom de produit ou de composant) pourront changer d’ici la sortie officielle d’ASP.NET 5.

Mono

Mono est une initiave non liée à Microsoft. Il s’agit de la réimplémentation du framework .NET pour Linux, à partir des spécifications ECMA du framework.

L’inconvénient majeur de Mono est qu’il n’est pas supporté par Microsoft. Une première conséquence est que son adoption est limitée au sein des entreprises. Un seconde conséquence est que les évolutions du framework arrivent avec un temps de retard non négligeable.

Je pense que la volonté de Microsoft de supporter .NET sur les autres plateformes est en partie dûe au succès qu’a rencontré Mono et au fait que cette initiative ait démontré en pratique que .NET pouvait fonctionner de façon viable, bien qu’expérimentale, sur Linux. Le développement .NET pour les smartphones est évidemment un autre argument majeur (même si le résultat reste à évaluer).

Les applications .NET type client léger (clients web) sont très probablement les plus utilisées en entreprise, avant les applications lourdes (exécutables à déployer sur chaque poste utilisateur). Un rapide test est de comparer le nombre de questions avec les tags asp.net et .net sur Stackoverflow.

Il paraît donc logique que ASP.NET ait été au centre de la nouvelle stratégie de Microsoft et soit donc la priorité de ce chantier.

OWIN et Katana

OWIN et Katana sont à mon sens le premier projet visible lié à ce chantier. C’est la première étape, nécessaire et la moins risquée, vers des applications .NET orientée web compatibles sur des plateformes non Windows. C’est la moins risquée car il ne s’agit que d’un projet de librairies .NET développées par un nombre de personnes restreint.

Auparavant, un projet web devait être hébergé dans IIS (webhost). Il existait des solutions selfhost telles que ServiceStack mais il s’agissait de librairies tierces au support plus limité.

OWIN est une spécification de Microsoft qui définit, en simplifiant, les interactions entre une application web et un serveur web. Katana est sa principale implémentation pour .NET (il en existe d’autres plus marginales). Grâce à Katana, il est possible de créer très facilement un selfhost avec le support de WebApi. Vous pouvez consulter un de mes anciens articles à ce sujet (WebApi2 en selfhost). Bien développée, une même librairie basée sur OWIN peut être hébergée sans adaptation soit en webhost sur IIS soit en selfhost dans un simple exécutable .NET (ou dans un service Windows).

Sachant qu’il y a peu de chance de voir IIS supporté sur une plateforme non Windows, il me paraît évident que la spécification OWIN était un premier pas vers le support d’ASP.NET sur des plateformes non Windows.

Je crois que l’initiative OWIN date de début 2011. Le projet Katana semble avoir été créé mi-2012 sur CodePlex.

ASP.NET 5 (vNext)

ASP.NET 5 est une refonte complète d’ASP.NET qui vise principalement à rendre possible le déploiement d’applications ASP.NET sur des plateformes non Windows. Les premiers signes visibles de cette refonte semblent remonter à début 2014 sous le nom d’ASP.NET vNext. La sortie officielle d’ASP.NET 5 est prévue au premier semestre 2016, donc très bientôt.

Puisqu’il s’agit d’une refonte qui ne sera pas rétro-compatible avec les précédentes versions, les ingénieurs de Microsoft en ont profité pour rendre plus cohérent l’ensemble des fonctionnalités du framework: cela concerne les héritages d’ASP.NET Webforms (Global.asax disparait) et de IIS, ainsi que la schizophrénie entre MVC et WebApi qui sont jusqu’à présent deux frameworks bien séparés mais qui partagent la plupart de leurs concepts. Webforms n’est plus supporté dans ASP.NET 5 et le pipeline de la requête a été réduit et donc optimisé (ASP.NET MVC étendait le pipeline de Webforms). Concrètement, ce pipeline n’est plus composé de cette liste (indigeste) d’événements auxquels peuvent se brancher les handlers. Au lieu de cela, le pipeline est une succession de tâches asynchrones exécutées en cascade, dont l’ordre d’exécution dépend de l’ordre d’inscription.

Le projet Katana est directement intégré dans ASP.NET 5 qui est, pourrait-on dire, « OWIN ready ». Le nom Katana n’a plus lieu d’être sous ASP.NET 5.

ASP.NET 5 repose sur le framework .NET Core. Le but de ce dernier est de servir de fondation pour le développement et le déploiement d’applications .NET sur des plateformes non Windows et pleinement supporté par Microsoft.

Je pense que ASP.NET 5 est la principale finalité stratégique visée par Microsoft. Le framework .NET Core et les autres projets décrits dans cet article sont des outils pour rendre cela possible. Mais l’intérêt dépasse largement ASP.NET puisqu’il rend le développement et le déploiement .NET en général possible sur différentes plateformes non Microsoft. Le nouveau framework ASP.NET 5 est en quelques sorte le POC de .NET Core (un énorme POC !).

MVC 6 et WebApi

Ces deux frameworks ont été fusionnés dans ASP.NET 5 pour le framework MVC 6. Le nom WebApi devrait donc disparaitre.

Les fonctionnalités devraient être sensiblement les mêmes, mais il n’y a plus de duplication des mêmes fonctionnalités dans deux espaces de noms différents: System.Web.Mvc et System.Web.Http sont regroupés dans Microsoft.AspNet.*. Et l’interface du conteneur IoC se trouve maintenant dans l’espace de nom Microsoft.Framework.DependencyInjection. ApiController n’existe plus et se voit remplacé par la même classe de base MVC Controller.

Plus de détails ici : http://aspnetmvc.readthedocs.org/projects/mvc/en/latest/migration/migratingfromwebapi2.html

A noter également: la méthode recommandée pour la configuration des routes WebApi et MVC est par les attributs (attribute routing).

ASP.NET WebForms

Bien que cela puisse changer et que les informations ne soient pas claires à ce sujet, il semblerait que Webforms soit exclus d’ASP.NET 5. Ce qui pour moi est une excellente chose. C’est en revanche regrettable pour les entreprises qui ont choisi de conserver ce modèle (obsolète depuis longtemps pour moi, même si Microsoft a toujours pris des pincettes à son sujet et ne l’a jamais affirmé). ASP.NET MVC date déjà de plus de 6 ans. ASP.NET WebPages sera toujours supporté.

Nous devrions être fixé courant 2016/2017: soit Webforms sera supporté dans un second temps, soit il sera lentement déprécié et son support dépendra de celui de ASP.NET <5 (actuellement .NET 4.6 mais pourquoi n’y aurait-il pas de 4.7+ ?), qui lui-même dépend du framework .NET standard antérieur à .NET Core. Mon idée est qu’il sera déprécié, à moins que les entreprises fassent suffisamment de pression sur Microsoft. On peut faire le parallèle avec VB6 qui a été remplacé par VB.NET en 2002: le support de VB6 s’est poursuivi jusqu’en 2008. Cela étant, aucune inquiétude à avoir sur le fait que le framework .NET actuel sera supporté encore plusieurs années. .NET Core ne permet pas encore de le remplacer entièrement et même si c’était le cas, il serait inimaginable que Microsoft mette fin à son support du jour au lendemain sans transition de quelques années. En revanche, lorsqu’on parle de nouvelles fonctionnalités d’ASP.NET, il est bien possible que Microsoft ne les supporte que sur son dernier né.

.NET Core

En tant que développeur, .NET Core est ce qui m’intéresse le plus car il représente les nouvelles fondations de l’écosystème à venir.

.NET Core est une réimplémentation du framework .NET dont le but est de permettre d’unifier tous les développements .NET au sein d’une même version du framework.

L’un des workflows visé pour le déploiement d’applications est de déployer le code source directement sur la plateforme cible et de lancer la compilation au moment du déploiement. Cela permet de sauter la tâche fastidieuse de devoir précompiler différentes versions de son application pour chaque plateforme cible depuis le poste de développement. Certes, le code MSIL est le même, mais la logique d’initialisation de l’application et le runtime .NET lui-même sont différents selon la plateforme.

Comme il ne s’agit plus de déployer des .dll et autres exécutables mais du code source qui sera compilé une fois déployé sur la plateforme cible, cette nouvelle approche affecte non seulement le déploiement des applications mais également leur phase de développement car il faut définir une organisation standard de projet (comment le code source est organisé, de quelles librairies il dépend, les métadonnées du projet, etc.).

Avant .NET Core, la solution de Microsoft était de créer des copies du framework selon la plateforme cible. Par exemple, .NET Compact et Silverlight parmi d’autres étaient différentes implémentation d’un sous-ensemble de composants du framework .NET.

.NET Core vise à maintenir une seule implémentation de son framework qui soit compatible sur toutes les plateformes supportées (Windows, Linux, Mac OS X…). Il y aura bien sûr des composants bas niveau propres à chaque plateforme, mais il s’agira d’une infime partie du framework. Déjà aujourd’hui, la grande majorité des classes est implémentée de manière identique que ce soit en WPF ou en .NET standard, par exemple. Avec .NET Core, cette grande majorité se retrouve unifiée et modularisée. De ce point de vue, .NET Core est à un peu à .NET ce que Windows Embedded Standard est à Windows.

Ma compréhension est que .NET Core est conçu dans le but de remplacer progressivement les différentes versions du framework .NET tel qu’on le connait aujourd’hui. Ce processus sera lent car il n’est pas possible de référencer une librairie .NET standard dans un projet .NET Core. C’est un nouveau framework .NET, et les références devront être de même type (.NET Core).

Cela impacte donc l’écosystème de Microsoft mais également celui des librairies tierces (éditeurs de logiciels, communauté open source, code interne des entreprises…).

Roslyn

Roslyn est le nouveau compilateur de .NET (compilation du code source vers le langage intermédiaire MSIL). Il s’agit d’une refonte en code managé, sous la forme d’une API utilisé par Visual Studio mais aussi accessible aux plugins et librairies tierces. Celui-ci permet la compilation de code .NET à la volée (sans même avoir à sauver de fichiers sur le disque).

Roslyn a été développé dans le même chantier que .NET Core, cependant il est utilisable à la fois par .NET Core et .NET standard.

RyuJIT

RyuJIT est le nouveau compilateur JIT (Just In Time, compilation du MSIL vers le code machine), inclus dans le nouveau runtime. Comme Roslyn, il est à mon sens la version open source et cross-platform de l’ancien compilateur JIT de .NET. Tout comme Roslyn, RyuJIT n’est pas limité à .NET Core mais il est spécifiquement conçu je pense pour le support de l’écosystème .NET Core.

.NET Native

.NET Native est la continuité de ce qui existait anciennement sous le nom de NGen, mais avec la nouvelle stack .NET Core. L’utilisation de .NET Native est plus restrictive que NGen mais son utilisation devrait s’en trouver plus robuste.

Il est également prévu que .NET Native soit l’unique façon de déployer des applications Universal Windows Platform (UWP) à partir de Windows Store vers les terminaux clients.
UWP est l’autre cible stratégique de .NET Core (en plus d’ASP.NET 5).

Concrètement .NET Native est une alternative à RyuJIT: la compilation en code machine n’a pas lieu en temps réel (JIT, Just In Time) mais à l’avance (AOT, Ahead Of Time). Le temps d’exécution, notamment le chargement de l’application, s’en trouve nettement amélioré.

Visual Studio Code (basé sur Atom)

Pour aller plus loin que le support du déploiement sur Linux et autres systèmes non Windows, Microsoft devait proposer une alternative à Visual Studio. C’est le rôle de VSCode basé sur Atom. Et comme la compilation peut maintenant se faire à la volée, sur la plateforme cible, à partir du code source .NET, il aurait été bien dommage de ne pas proposer de solution pour l’édition de projets .NET Core.

Evidemment, l’idée n’est pas de remplacer Visual Studio. Si vous avez accès à Visual Studio, l’expérience est bien meilleure que sur VSCode. On peut espérer qu’à terme, il soit possible de développer des applications simples sur VSCode (des applications simples mais un peu plus que des « démo »).

.NET Open source

Microsoft a fait cette annonce en 2015. Outre les bénéfices d’images que cela lui apporte, j’ai dans l’idée que ce geste, bien qu’il n’eut sans doute pas été indispensable, est stratégiquement lié à l’ouverture du support de .NET sur les plateformes non Windows et qu’il participera beaucoup à son succès.

Notons que seuls sont open source .NET Core, sa stack (runtime, compilateurs…) et certains frameworks (ASP.NET 5, SignalR, Entity Framework, etc.). Ni l’actuel .NET standard, ni ses dérivés (WPF, Silverlight, .NET Compact…) ne le sont.

Pour consulter la liste des projets open source : http://www.dotnetfoundation.org/projects

Notons aussi que le code source d’un sous-ensemble de .NET est disponible sur http://referencesource.microsoft.com/, ce qui était déjà en soi un grand pas (ça ne signifie pas que le code est open source pour autant). Cette initiative de Microsoft remonte à 2008 et il est intéressant de savoir que son but initial était de servir de guide au développement de .NET Core (cf. readme du projet source sur GitHub).

.NET Core et WCF

Seul un sous-ensemble de WCF est porté vers .NET Core: il s’agit essentiellement de ce qui est nécessaire côté client. Les services WCF doivent continuer à s’appuyer sur .NET standard pour le moment. La cible du sous-ensemble WCF supporté dans .NET Core est très probablement UWP (pour l’invocation de services WCF).

Le projet peut être suivi ici: https://github.com/dotnet/wcf

L’avenir de WPF et WinForms dans tout ça ?

Les frameworks WPF et WinForms ne sont officiellement pas inclus dans .NET Core à ce jour. Cela peut rassurer les inquiets à propos d’ASP.NET WebForms: tant que WinForms devra exister, .NET standard devra être supporté.

WPF est un framework à part (un fork de .NET comme Silverlight, .NET Compact, etc.). S’il pouvait fonctionner de manière équivalente sur Linux, sur lequel DirectX n’existe pas, alors la logique voudrait qu’à terme, WPF soit inclus dans .NET Core. Hormis sa dépendance à DirectX, le principal frein que j’y vois est qu’aujourd’hui, WPF n’est pas open source et Microsoft n’est peut-être pas décidé à ouvrir son code à la communauté. Peut-être attendent-ils de voir la réception de .NET Core ? Vu l’ampleur de la tâche, je pense que c’est une question de priorité. La priorité est actuellement ASP.NET et UWP. Il est compréhensible qu’ils n’aient pas souhaité tout refaire en même temps.

WinForms quant à lui est encore plus dépendant de Windows que WPF. J’ai dans l’idée qu’il devrait devenir obsolète au profit de WPF, comme l’est ASP.NET Webforms au profit d’ASP.NET MVC.

L’alternative est que Microsoft choisisse de maintenir deux frameworks à long terme: .NET standard (incluant WPF et Webforms pour Windows) et .NET Core (ASP.NET et développements cross-platform). Il est toujours possible de partager du code entre les différents frameworks .NET avec les PCL (Portable Class Library) et les fichiers de code partagé (aka Shared Project).

Il faudra sûrement attendre plusieurs années encore pour avoir les réponses à ces questions.

À court terme, .NET Core supportera les applications web et console. En dehors d’un projet ASP.NET selfhost, l’attrait pour un projet console est encore relativement limité.

Et les services Windows ?

Tout comme Winforms, les services Windows sont spécifiques à Windows. Il y a donc peu de chances de les voir supportés dans .NET Core. Si un service doit être développé pour Linux (démon), il suffit, je pense, de développer une application console .NET Core.

Conclusions

La nouvelle stack basée sur .NET Core s’aligne parfaitement avec les tendances récentes: microservices, Docker, le cloud… En effet, .NET Core rend .NET compatible avec les images Docker, elles-mêmes orientées microservices par nature. Et l’empreinte mémoire d’une application .NET Core devrait être sensiblement réduite par rapport à une application basée sur le framework .NET complet. Cela va également dans le sens des microservices et du cloud.

Je m’avance peut-être mais si WPF et WCF étaient supportés dans .NET Core, il ne manquerait pas grand chose pour pouvoir développer des applications .NET de tous types, sur toutes les plateformes.

Même s’il est encore limité à ce jour, .NET Core offre un nouvel horizon de possibilités. Par exemple, il devient possible de développer pour des images Docker (sans avoir besoin d’héberger une VM Windows dans une image Docker!).

L’avenir de .NET Core dépend de son accueil et de son adoption par la communauté .NET et par les autres développeurs des plateformes non Windows: restera-t-il un framework complémentaire aux actuels frameworks .NET (.NET standard, compact, WPF…) ou tendra-t-il lentement, mais sûrement, à les remplacer ? Mon espérance va évidemment vers ce dernier chemin, on peut toujours rêver :-).

Dans le même sens, un tweet récent de l’architecte d’ASP.NET 5, David Fowler, cache à peine sa volonté de remplacer à terme .NET standard avec .NET Core.

Mise à jour du 1 juin 2016: dans la continuité de cet article, Making it easier to port to .NET Core confirme les aspirations de .NET Core à devenir plus généraliste que le support d’ASP.NET multi plateforme.

Références

.NET Foundation sur Github
Introducing .NET Core
Introducing ASP.NET 5: The New ASP.NET in Town!
OWIN, Katana and ASP.NET vNext: eliminating the pain of IIS
ASP.NET vNext: The Next Generation
Understanding .NET 2015
Inside ASP.NET Core 1.0 with Damian Edwards