Discussion :

[tomlev]

Cela veut donc dire que le fichier project.json va être supprimé ? Moi qui trouvais cela un peu mieux que l'ancien système...

Moi aussi ça me plaisait bien, beaucoup de gens sont déçus. De ce que j'ai compris, les raisons sont les suivantes :

• il manquait beaucoup de choses à project.json par rapport aux projets MSBuild "traditionnels", et ajouter tout ce qui manque reviendrait à réimplementer MSBuild et prendrait trop longtemps
• beaucoup d'outils reposent sur MSBuild, et risquent de ne pas être adaptés pour project.json avant longtemps
• la migration des projets existants vers project.json est loin d'être triviale, et beaucoup de projets ont lourdement investi dans MSBuild (custom tasks/targets)
• project.json posait beaucoup de problèmes pour les références entre projets

Bref, au final ils ont fini par décider que le jeu n'en valait pas la chandelle, et ils ont fait machine arrière. Même si je suis un peu déçu, je comprends cette décision, et je dois admettre que c'est plus raisonnable.

Cela dit, tout n'est pas perdu, certains concepts de project.json devraient être conservés, notamment :
- ne plus lister explicitement tous les fichiers sources dans le projet, mais inclure implicitement tous ceux qui se trouvent dans le répertoires des sources
- meilleure gestion des packages NuGet (références aux packages eux-mêmes, plutôt qu'aux assemblies qu'ils contiennent)

J'ai démarré 2 projets avec les RC1 et RC2 de Net.Core et je dois dire que la passage à la version finale est relativement douloureux (en fait je ne suis pas arrivé).

C'est clair qu'il y a eu de grosses erreurs sur la communication, ça a causé pas mal de mécontentement dans la communauté .NET. Normalement, une RC est une version presque finale, il ne devrait pas y avoir de breaking changes (ou en tout cas le moins possible) entre une RC et une RTM. Perso j'ai décroché aux alentours de la beta8, je me suis dit que j'attendrais la version finale pour continuer mon projet...

[Stéphane le calme]

Microsoft dévoile la feuille de route de .NET Core,
l'entreprise compte apporter des concepts de programmation fonctionnelle aux langages .NET

Le mois dernier, Microsoft a annoncé la disponibilité générale de la première version majeure de .NET Core et ASP.NET Core, anciennement appelés respectivement .NET Core 5 et ASP.NET Core 5.

Comme l’explique Microsoft, le .NET Core est une version modulaire du .NET Framework portable sur plusieurs plateformes pour optimiser le partage et la réutilisation du code. Il faut noter que le .NET Core est open source et accepte les contributions de la Communauté.

Scott Hunter, membre de l’équipe d’ingénierie .NET, a donné une feuille de route de .NET Core.

Selon le planning de Microsoft, durant le mois d’août la version 1.0.1 sera disponible. Elle embarquera un certain nombre de correctifs dans le SDK de .NET Core. Microsoft n’a pas précisé de date, mais Hunter dit qu’il est probable qu’elle soit disponible en début de mois.

Du quatrième trimestre 2016 au premier trimestre 2017, Microsoft prévoit de déployer la première mise à jour mineure qui sera principalement axée sur le remplacement de .xproj/project.json par .csproj/MSBuild. Hunter assure que la mise à jour projet sera automatique : il suffira d’ouvrir un projet 1.0 pour déclencher la mise à jour vers le nouveau format.

Bien entendu, il y aura également de nouvelles fonctionnalités et des améliorations au niveau de l’environnement d’exécution et des bibliothèques.

Du côte des outils .NET Core par exemple, Microsoft évoque le support du système de projet .csproj/MSBuild, une amélioration au niveau de « dotnet restore » qui ne va plus restaurer des paquets appartenant à .NET Core, de nouvelles commandes pour gérer les frameworks sur la machine ou encore une amélioration de « dotnet publish » qui ne va publier que les dépendances requises pour une taille de distribution optimale.

Hunter a indiqué que Microsoft a l’intention d’apporter des concepts de programmation fonctionnelle aux langages .NET qui vont s’appliquer à toutes les plateformes .NET. Parmi ces concepts figurent les tuples et pattern matching. Les langages devraient également bénéficier d’une amélioration de la performance et de la qualité du code, notamment en ce qui concerne les littéraux binaires, les retours de fonction de type de référence, les expressions Throw ou les séparateurs de chiffres. Hunter note également que des améliorations de la productivité des développeurs sont à l’ordre du jour.

« Ces fonctionnalités seront disponibles dans C # 7 », a promis Hunter. Et de préciser que VB 15 va également implémenter certaines de ces fonctionnalités comme les tuples ou les retours de fonction de type de référence, certaines seront disponibles dans la prochaine mise à jour du langage comme le pattern matching, et d’autres ne sont pas encore dans la feuille de route.

F #, le langage de programmation fonctionnel, impératif et orienté objet pour la plate-forme .NET qui est développé par Microsoft, sera lui aussi mis à jour. Un peu plus tard cette année ou au début de 2017, F # 4.1 va embarquer un support complet de .NET Core et proposer une meilleure expérience de l’EDI avec le support des workspace. Des fonctionnalités seront ajoutées comme les tuples qui vont interopérer avec ValueTuple.

Microsoft prévoit également d'accueillir les processeurs ARM 32/64 dans l’environnement d’exécution et les bibliothèques .NET Core l’année prochaine, à la fois sur les plateformes Windows et Linux, mais à des moments différents. Des distributions Linux supplémentaires seront également prises en charge, bien que Microsoft ne précise pas quelles seront celles qui vont être ajoutées. Pour rappel, la version 1.0 prend déjà en charge les distributions comme Red Hat Enterprise Linux 7.2 et OpenSUSE 13.2.

Au début de l’année 2017, Microsoft prévoit d’apporter plusieurs des API qui manquent à .NET Core. « Ces API vont faire partie intégrante de .NET Standard 2.0, qui sera publié au même moment, ce qui va résulter en une consistance des API sur le framework .NET, .NET Core et Xamarin », a avancé Hunter.

Source : blog Microsoft

[SaiRictus]

Les choses avancent vite à ce que je vois.
Étant open source, je n'en attendais pas moins.

Par contre je ne comprends pas pourquoi ce retour en arrière concernant le fichier .xproj /project.json qui redeviendrait un fichier *.csproj

[tomlev]

Par contre je ne comprends pas pourquoi ce retour en arrière concernant le fichier .xproj /project.json qui redeviendrait un fichier *.csproj

Je l'ai expliqué 2 messages plus haut

[SaiRictus]

Je l'ai expliqué 2 messages plus haut

Je n'avais pas vu ton message (ayant répondu directement depuis l'article)

[micka132]

Les choses avancent vite à ce que je vois.
Étant open source, je n'en attendais pas moins.

Bof, soit je sais pas trop comment voir les contributeurs (ce qui est fort probable), soit y a 99% des participations qui sont faites par des gars de chez microsoft. Bref j'ai pas l'impression que ca va plus vite que n'importe quel autre projet Microsoft -_-.

[mermich]

C'est pas parce ce que c'est open source que c'est plus rapide. Il y a auncuns liens de parente. Mais bon on va mettre open source histoire d'etre swag.

Pour le coup, les techno open sources microsoft sont libre d'etre lues par tous le monde, mais seuls les employes de microsoft peuvent contribuer au tronc.

[Aeson]

mais seuls les employes de microsoft peuvent contribuer au tronc.

Tu peus tout a fait faire des Pull Request qui seront approuvé par Microsoft. Ca arrive régulièrement. Comme sous Linux. Sauf que sous Linux toutes les validations se font par UN seul homme si je ne me trompe.... Et a coup d'insulte en plus...

[tomlev]

Pour le coup, les techno open sources microsoft sont libre d'etre lues par tous le monde, mais seuls les employes de microsoft peuvent contribuer au tronc.

Tu devrais peut-être te renseigner un peu...

https://blogs.msdn.microsoft.com/dot...-net-core-1-0/

At this point, nearly half of all pull requests for .NET Core related projects (e.g. corefx, coreclr) come from the community.

Et plus bas, à propos des 9723 contributeurs uniques :

Note: These numbers include Microsoft employees, which are (at most) 10% of the count.

Donc au moins 90% des contributeurs viennent de la communauté et non de Microsoft.

[giova_fr]

ca pour une bonne nouvelle !

J'ai vraiment hate de voir le compilateur pour processeur ARM

[kilroyFR]

Ca c'est bien du M$, remplacement de 'xproj/project.json par .csproj/MSBuild'; ce doit etre essentiel effectivement comme fonctionnalité...
ce qui est toujours surprenant c'est que s'ils font la comm la dessus c'est qu'il n'y a rien d'autre a presenter. les developpeurs ne sont pas cons, on veut du vrai fonctionnel, quelque chose qui apporte des choses en plus, qui fasse chuter les temps passés dans le dev, des outils RAD, du multi plateforme etc.

[Jeanchristophe56]

Très bonne nouvelle !
Enfin un peu d'ouverture...