Microsoft présente .NET Core
Son « fork open source du Framework .NET »

Le , par Hinault Romaric

0PARTAGES

5  0 
Le mois dernier, lors d’un événement en ligne, Microsoft a présenté l’avenir de sa plateforme de développement .NET et de ses outils, notamment Visual Studio 2015.

Le mot d’ordre était l’ouverture ! La firme avait annoncé qu’elle allait publier en open source le code du cœur du Framework .NET (.NET Core), sous licence MIT.

L’ambition de Microsoft est de rendre .NET accessible à un nombre plus important de développeurs, sous plusieurs plateformes, y compris Linux et Mac.

Dans un long billet de blog sur MSDN, Microsoft présente de façon détaillée ce qu’est « .NET Core », comment il sera publié, ce qu’il représente pour le Framework .NET et ce que cela implique pour le développement multiplateforme et open source.

Lorsque Microsoft avait publié .NET pour la première fois en 2002, il était disponible comme un Framework unique. Peu de temps après, plusieurs déclinaisons ont vu le jour, dont .NET Compact Framework, un sous-ensemble de .NET à destination des terminaux à faibles ressources, comme les terminaux mobiles.

Au fil du temps, plusieurs déclinaisons du Framework .NET ont été expédiées pour Silverlight, Windows Phone, et plus récemment pour le Windows Store. Cela a créé une fragmentation de .NET, qui était désormais disponible en plusieurs plateformes, gérées par des équipes différentes au sein de Microsoft.

Cela ne poserait pas de problème si les développeurs créaient des applications spécifiques pour chaque plateforme. Cependant, il est assez fréquent pour ceux-ci de cibler plusieurs dispositifs et plateformes à travers leurs applications. Cette diversité pourrait même être l’une des principales causes de la faible croissance du Windows Store, car les applications Windows Desktop, ne peuvent figurer sur le store, qui supporte uniquement WinRT.


Pour contourner le problème, Microsoft a développé dans un premier temps les bibliothèques de classes portables (portable class libraries), dont l’objectif était d'écrire et générer des assemblys managés qui fonctionnent sur plusieurs plateformes .NET Framework. Puis, la firme a dévoilé en avril dernier lors de sa conférence Build, Universal Apps, un moyen pour les développeurs de créer une seule application, qui fonctionne de façon fluide sous l’ensemble des plateformes Windows (Windows 8 et Windows Phone 8).

Mais, il s’agissait des solutions limitées et partielles. .NET Core a pour ambition d’aller au-delà, en offrant une implémentation unifiée de .NET. « .NET Core est essentiellement un fork du Framework .NET, dont le développement a été optimisé autour de ces préoccupations », écrit Microsoft. .NET Core est une implémentation modulaire, qui pourra être utilisé dans une grande variété de plateformes. Il sera soutenu par Microsoft sur Windows, Linux et Mac OS X.

.NET Core comprend un BCL (Base Class Library) unifié qui sera le même code pour toutes les plateformes. « Même si les scénarios pour NET Native (dispositifs tactiles) et ASP.NET 5 (développement Web côté serveur) sont très différents, nous avons pu fournir une bibliothèque de classes de base unifiée. », se réjouit Microsoft.


Actuellement, Microsoft propose deux implémentations du .NET Core BCL : l’une pour .NET Native et l’autre pour CoreCLR, utilisé par ASP.NET 5.0. Cependant, la majeure partie de BCL de .NET Core est commune aux deux plateformes.

Autre fait intéressant : .NET Core introduira un nouveau modèle de déploiement des applications. Il sera possible de déployer des applications .NET avec des copies des bibliothèques du Framework .NET. L’idée est de permettre aux développeurs d’importer uniquement les parties de .NET dont ils ont besoin, et les déployer avec leur application. Les bibliothèques de .NET Core seront livrées à travers le gestionnaire de paquets NuGet.

Les avantages de cette approche sont multiples. Une machine n’aura plus besoin d’une version complète de .NET Framework pour exécuter une application, car chaque application sera livrée avec son propre Framework. De plus, les mises de .NET Core ne briseront plus les applications existantes.

Le diagramme ci-dessus soulève cependant quelques interrogations puisqu’au-dessus, on retrouve uniquement « Windows Store App Model » pour les applications WinRT et « ASP.NET 5 App Model ». Qu’en est-il des applications desktop et ASP.NET 4 ?

.NET Core représente un sous-ensemble du Framework .NET, selon Microsoft. Le développement d’application desktop avec WPF ou Windows Forms continuera à se faire sous le Framework .NET et non .NET Core. Microsoft compte mettre à jour ce dernier chaque année. Il y’aura donc des fonctionnalités qui seront exclusives au Framework .NET.


Pour les développeurs qui souhaitent exécuter leur code à la fois sur le Framework .NET et .NET Core, Microsoft prévoit d’étendre les bibliothèques de classes portables pour couvrir ce cas, car pour la firme, .NET Core est « le fondement de toutes les futures plateformes .NET »

Source : MSDN

Et vous ?

Que pensez-vous de .NET Core ? Et de son ouverture par Microsoft ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Issam
Membre confirmé https://www.developpez.com
Le 08/12/2014 à 15:20
Personnellement j'attends avec impatience l'implémentation de .Net Native pour le Desktop qui est pour le moment que pour le store
2  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 08/12/2014 à 15:23
En théorie c'est une très bonne chose,
cela permettra d'avoir des implémentations communes avec mono ( qui prévoit de reprendre le code).

Cela dit , le fait de gérer tout ses multiples package risques de devenir assez bordélique, à voir dans le futur.

Je comprend pour le moment qu'ils n'ouvrent pas WPF ,
car y'a déjà un gros travail à faire sur le Core.
Cela dit il faudra juger en pratique (bugs, performance , maintenance)

D'autre part tout n'est pas encore dispo, actuellement P-Linq et TPL Dataflow viennent d'être rajoutés, on attend le reste avec impatience.

Pour l'implémentation .NET native, je ne pense pas que ça s'appliquera à WPF pour le moment , y'a d'autres axes d'optimisations plus importants.

Pour la fragmentation, il faudra voir avec le .NET normal, depuis l'install du 4.6 (preview)sur ma machine de test (Windows 7)
j'ai beaucoup d'applications qui ne fonctionnent pas ( je pense que c'est dû à ryuJit )
1  0 
Avatar de CeluiQuiCode
Membre régulier https://www.developpez.com
Le 08/12/2014 à 15:27
Xamarin / Mono-project , prochain(s) rachat(s) de Microsoft ? Histoire d'aller encore plus vite pour son ouverture
2  0 
Avatar de Issam
Membre confirmé https://www.developpez.com
Le 08/12/2014 à 15:53
Citation Envoyé par dfiad77pro Voir le message


Pour l'implémentation .NET native, je ne pense pas que ça s'appliquera à WPF pour le moment , y'a d'autres axes d'optimisations plus importants.
oui mais c'est dans leurs plans !
1  0 
Avatar de Washmid
Membre averti https://www.developpez.com
Le 08/12/2014 à 15:55
Ça fait des années (depuis toujours?) qu'on peut faire ça en java, déployer les APIs avec les applis, avoir des binaires uniques pour toutes les plateformes, et ça pose pas vraiment de soucis (à ma connaissance).

Bon, java permet également de déployer le runtime carrément dans les exécutable ce qui ne semble pas être le cas ici.

Bref, très bonne nouvelle pour la portabilité, marre des moulinettes de "csproj" pour gérer plusieurs plateformes.
4  1 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 08/12/2014 à 16:02
Citation Envoyé par Washmid Voir le message
Ça fait des années (depuis toujours?) qu'on peut faire ça en java, déployer les APIs avec les applis, avoir des binaires uniques pour toutes les plateformes, et ça pose pas vraiment de soucis (à ma connaissance).

Bon, java permet également de déployer le runtime carrément dans les exécutable ce qui ne semble pas être le cas ici.

Bref, très bonne nouvelle pour la portabilité, marre des moulinettes de "csproj" pour gérer plusieurs plateformes.

ah et donc le projet Jigsaw pour JAVA 9 , c'est pas ça??

Java aura droit à son système de modules. Le projet Jigsaw prend forme après plusieurs problèmes techniques qui ont entraîné son report et sa réimplémentation.

Pour rappel, le projet Jigsaw vise essentiellement à découper la bibliothèque d’exécution de base de Java en différents modules. Cela devrait permettre à une machine virtuelle Java (JVM) de fonctionner sans le support de certains packages de base.
On parle de modularité au sein du core même du framework .NET
1  2 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 08/12/2014 à 16:51
Citation Envoyé par Washmid Voir le message
Bon, java permet également de déployer le runtime carrément dans les exécutable ce qui ne semble pas être le cas ici.
Les programmes Java n'embarquent pas de runtime (des projets hors du standard le permettent peut-être).
Un projet là-dessus est en cours (JEP 148).
1  0 
Avatar de Olivier Famien
Chroniqueur Actualités https://www.developpez.com
Le 08/12/2014 à 16:54
Voilà que les choses avancent dans le bon sens. Ils ont compris que les dev d'aujourd'hui sont de gros "paresseux" qui ne veulent plus apprendre 1 langage pour 1 plateforme mais 1 langage pour x plateforme. Et puis à quoi ca sert une multitude de langages, si je peux faire tout et n'importe quoi avec le même langage et même sortir le chien ou me faire du thé pendant qu'on y est .
Vive le CODE (Code once deploy everywhere).
3  0 
Avatar de frfancha
Membre éclairé https://www.developpez.com
Le 08/12/2014 à 17:31
Citation Envoyé par Washmid Voir le message
Ça fait des années (depuis toujours?) qu'on peut faire ça en java, déployer les APIs avec les applis, avoir des binaires uniques pour toutes les plateformes, et ça pose pas vraiment de soucis (à ma connaissance).
Oui bon les produits d'entreprise c'est: seule le jdk a.b.c release x modifié par nos soins est supporté ==> donc on se retrouve avec des dizaines de versions sur le serveur, qui finissent par s'écraser les unes les autres du coup on fait une VM par produit avec SA version de java..
2  2 
Avatar de Washmid
Membre averti https://www.developpez.com
Le 08/12/2014 à 19:48
Citation Envoyé par Gugelhupf Voir le message
Les programmes Java n'embarquent pas de runtime (des projets hors du standard le permettent peut-être).
Un projet là-dessus est en cours (JEP 148).
Tu copie colle n'importe quel runtime java sur la machine destination, puis tu lance ton programme avec définissant une variable d’environnement et ça marche (la licence de base t'autorise à faire ce genre de choses).

Sinon t'as eclipse qui permet de s'exécuter avec la JRE que t'as juste à coller en sous-répertoire.

Sans parler des compilateurs natifs qui te sortent un .exe très léger n'ayant aucune dépendance envers une quelconque JRE installée (pdf tool kit par exemple qui fonctionne de cette manière sauf erreur)

Et tout ça existe depuis au moins 10 ans. En .NET, actuellement, bonne chance ^^

@frfancha : oui effectivement si on s'amuse à trifouiller sur ce genre de chose ou à référencer des package sun.* effectivement ça peut virer au cauchemar
2  1 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web