Non mais les developpeurs .Net on besoin de Linux dans certains cas (Le cloud par exemple).Parce je pense que le monde de Linux n'a pas besoin de ce framework.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Non mais les developpeurs .Net on besoin de Linux dans certains cas (Le cloud par exemple).Parce je pense que le monde de Linux n'a pas besoin de ce framework.
A noter également que le compilateur AOT (.Net Native) est lui aussi devenu un projet open-source depuis hier
Source : Twitter
encore une nouvelle syntaxe barbare a la M$ !
Qui sera tellement barbare qu'elle sera reprise plus tard par les pro / sectaire de l'open source en arguant que c'est tout nouveau et que c'est eux qui ont tout inventé, comme d'habitude ... (voir HTML 5)Envoyé par kilroyFR
Et sinon, tu peux argumenter STP ?
De quelle syntaxe parles-tu ? Cet article ne parle pas des langages, mais de la plateforme .NET
Il y a toutes sortes de langages basés sur .NET, avec des syntaxes très différentes (C#, VB.NET, F#, C++/CLI, Nemerle...). Après, on peut aimer ou non la syntaxe de ces langages, mais C# par exemple a des qualités largement reconnues, et de nombreux langages récents s'en inspirent (Swift, ECMAScript...)
Au passage, la syntaxe de ces langages ne sort pas de nulle part. Celle de C# est largement inspiré de Java et de C++, F# a une syntaxe presque identique à OCaml, etc. Donc je ne vois pas trop en quoi ils ont une syntaxe "a la M$" (sic).
Bref, renseigne-toi un minimum avant de troller gratuitement
C'est moi ou les troll/ignares sont de plus en plus nombreux(en proportion) avec les annees ?
C'est le second effet de la democratisation du metier d'informatitien/de dvp ?
Pas un troll et c'etait pas non plus pour me faire insulter, juste pour donner mon avis sur les expressions lambdas et autre LINQ que je trouve particulierement penibles a lire dans certaines situations.
Il y a 25 ans quand on ecrivait un programme en C qui tenait sur une ligne (alors qu'on pouvait l'ecrire plus lisiblement en 5-10 lignes) on nous reprochait que c'etait difficilement maintenable.
Quand je vois certaines syntaxes (ex: LINQ : strSignature = Signature.Aggregate(strSignature, (current, Byte_L) => current + Byte_L.ToString("X2"))
je me dis qu'on n'a pas vraiment fait de progres (ca glorifie certainement l'ego de certains de croire qu'ils sont les rois du monde ou des artistes (merci Resharper) parce qu'ils arrivent a condenser un maximum de chose dans un minimum de syntaxe).
Ce n'est pas un critere pour moi; je prefere quelque chose de maintenable par le plus grand nombre que d'utiliser des syntaxes pour le moins cabalistiques quelques fois.
Et le bout de code montré m'a fait pensé a ceci. C'est tout.
C'est un exemple un peu caricatural (la méthode Aggregate n'est pas la plus intuitive, et d'ailleurs la plupart des gens l'utilisent rarement)... Pour ma part je trouve ce code tout à fait lisible, c'est juste une question d'habitude.
Après évidemment il ne faut pas abuser des expressions lambda, mais c'est une feature extrêmement utile. Quand c'est utilisé à bon escient, ça permet de faire des choses qui seraient assez complexes à faire autrement (par exemple dès que tu commences à capturer des variables locales dans une lambda, ce serait super galère d'écrire un code équivalent sans lambda).
Quant à Linq, je trouve ce code :
Beaucoup plus lisible et expressif que celui ci :
Code : Sélectionner tout - Visualiser dans une fenêtre à part var names = people.Where(p => p.Age > 18).Select(p => p.Name).ToList();
Et concernant ReSharper, il ne faut pas appliquer toutes ses suggestions sans réfléchir... il te propose des trucs, après c'est à toi de voir si tu les veux ou pas. Il ne réfléchit pas à ta place !
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
Bonjour,
je travaille actuellement sur Apache et je crée des sites Web avec Angular, actuellement j'ai des problèmes de SEO à cause du routage Angular, je serai donc intéressé par mettre en place Asp.net afin de l'utiliser pour le routage et la génération des balises meta dans le header des pages web, je voulais savoir si quelqu'un avais déjà déployé un site Asp.net en prod sur un serveur Apache (environnement Linux), si c'était vraiment exploitable en production.
A priori c'est supposé bien marcher puisque la RC a une licence "go live". Par contre à ce stade tu ne vas sans doute pas trouver grand monde qui l'a déjà fait, puisque c'était en beta jusqu'à maintenant...
Toute façon j'arriverai pas à vendre ça à mes supérieurs étant donné qu'il n'y aura pas grand monde pour assurer la maintenance derrière je vais me retrouver à faire une vrai page pour chaque route avec du SSI pour tout ce qui est récurrent (header,footer,menu), mon Dieu que c'est propre et amusant.
Passage de .NET à l’open source : un an plus tard . . .
Passage de .NET à l’open source : un an plus tard,
comment se porte la plateforme de Microsoft ?
Il y’a un peu plus d’une année que Microsoft a annoncé le passage d’une grande partie du framework .NET à l’open source. Une question qu’il est pertinent de se poser depuis lors est celle de savoir comment il se porte. La communauté a-t-elle adopté .NET comme le souhaiterait Microsoft ? À l’aide de l’outil Microsoft Power BI, Matt Warren a effectué une analyse de trois des projets les plus significatifs, mais aussi les plus actifs de l’écosystème .NET à savoir Roslyn, CoreCLR et CoreFX. Pour rappel, Roslyn est la plateforme de compilation de .NET comprenant les compilateurs pour C# (open source) et Visual Basic ainsi qu’une performante API d’analyse de codes sources. CoreCLR est composé du noyau de la plateforme d’exécution de .NET appelé CoreCLR, de la bibliothèque de base appelée mscorlib, le ramasse-miettes, un compilateur JIT, les types de données de base ainsi que beaucoup de classes de bas niveau. CoreFX lui, est composé des bibliothèques fondamentales du noyau de .NET et comprend les classes de gestion des collections, les fichiers système, la console entre autres. L’analyse effectuée s’est faite en incluant plusieurs paramètres permettant d’avoir des résultats qui reflètent le mieux la situation actuelle de la plateforme .NET.
Nombre de problèmes relevés par projet et par groupe
L’analyse des données des trois projets a montré que le nombre de problèmes relevés par les propriétaires du projet et les collaborateurs était supérieur au nombre de problèmes relevés par le reste dans la communauté pour le projet Roslyn avec seulement 40 % d’entre eux signalés par la communauté. Cependant, la communauté est beaucoup plus active sur le projet CoreCLR pour lequel le nombre de problèmes signalés par la communauté est supérieur au cumul de ceux signalés par les propriétaires et leurs collaborateurs. Cela peut s’expliquer notamment par le fait que CoreCLR soit la partie la plus visible de .NET, car englobant la plupart des bibliothèques utilisées par les développeurs .NET dans leurs programmes de tous les jours. Une autre raison de cette popularité de CoreCLR par rapport aux deux autres projets est qu’il est plus ancien. Les utilisateurs ont naturellement plus de suggestions d’améliorations ou de résolutions de bogues, ce qui n’est pas encore le cas de Roslyn qui est beaucoup plus récent sans compter le fait que les bogues du compilateur ne sont pas très faciles à détecter.
Nombre total de requêtes d’extraction par projet et par groupe
Sur ce plan, l’activité de la communauté est plus faible que celle des propriétaires et de leurs collaborateurs sur l’ensemble des trois projets avec seulement 12 %. Ce faible taux s’explique par le fait qu’il ne soit pas facile de faire une requête d’extraction qui aboutit. Pour faire une requête d’extraction qui aboutisse, il faut tout d’abord choisir une question relative à la partie concernant sa requête d’extraction, attendre de recevoir des modifications de l’API à travers un examen du code et répondre à toutes les exigences de comparabilité, de performance et d’exactitude. Cependant, il n’est pas aisé de donner des chiffres permettant de dire que la contribution de la communauté est plus importante ou non, même s’il faut noter que la participation de la communauté est assez consistante sur une période qui reste quand même relativement courte.
Les libellés des bogues signalés par projet
Le dernier paramètre considéré pour réaliser l’étude de la plateforme montre que le libellé « CodeGen » est assez fréquent du fait notamment que RyuJIT, le compilateur JIT de .NET avait été lancé il y a seulement quelques jours. Par ailleurs, le fait qu'il y ait un nombre de bogues aussi important en si peu de temps peut amener à se poser des questions, sachant que certains d’entre eux sont des bogues avec des conséquences graves comme le soulignent des statistiques publiées par Stack Overflow. Il est à noter aussi que les requêtes avec comme libellé « Up for Grubs » sont assez nombreuses pour tous les trois projets. Ce qui prouve que la communauté est en train d’approfondir ses connaissances sur les trois projets et montre un intérêt grandissant. Une dernière chose à noter et non des moindres est que les problématiques de la performance et de l’optimisation sont assez considérées par la communauté.
Source : mattwarren.org
Et vous ?
Quelle analyse faites-vous du framework .NET, un an après son passage à l'open source ?
Voir aussi
Est-ce qu'il est possible de bâtir un environnement de développement et un environnement de production complets avec seulement de l'open-source ?
Ta question est un peu vague. Comme nous sommes sur un article .Net, je pars du postulat que tu parles d'environnements .Net.
- Développement : oui, mais ça va être très limité car le seul IDE open source actuel avec .Net Core est Visual Studio Core. Comme son nom l'indique, tu as vraiment juste un ... Core. C'est un éditeur de code très avancé, mais on est bien loin de Visual Studio sous Windows. De plus, pour le moment .Net Core n'implémente pas l'intégralité du framework .Net, donc selon tes besoins, tu ne pourras pas y recourir ; mais c'est en cour de portage complet.
- Production : encore une fois, le principale problème vient de tes besoins : si tu utilises des fonctionnalités non implémentées dans .Net Core, tu seras bloqué. Un autre souci est l'hébergement, car pour du Web, il n'y a que IIS pour le moment.
Il ne faut pas oublier que le virage open source de .Net est récent (je mets à part Xamarin, qui n'est pas le sujet de l'article), et que les choses évoluent très vite. Donc pour te répondre je dirai que non, ce n'est pour l'instant pas possible, mais il est évident que cela va le devenir car Microsoft en a la volonté ... et les moyens, aussi bien en termes techniques qu'en termes de compétence.
Sauf que son nom est Visual Studio Code, et non Core, du coup la blague tombe un peu à l'eau
Pour moi, VS Code n'a pas vraiment vocation à être un IDE complet, mais plutôt un éditeur de code avancé, qui se positionne sur le même créneau que Atom ou Sublime Text.
Non, tu peux très bien faire tourner un site ASP.NET 5 (basé sur .NET Core) sous Linux, où IIS n'existe pas... Il n'y a pas d'intégration avec Apache ou Tomcat pour l'instant (quoique ça pourrait certainement se faire), mais il y a un serveur fourni avec ASP.NET 5, que tu peux mettre derrière un nginx si besoin.
(j'ai testé sur un Raspberry Pi il y a plusieurs mois, et ça marchait déjà très bien)
il y'a aussi sharp develop qui est open source
http://www.icsharpcode.net/OpenSource/SD/Default.aspx
Todo list de ce week-end : dormir ;-)Sauf que son nom est Visual Studio Code, et non Core, du coup la blague tombe un peu à l'eau
VS Code a beaucoup de fonctions évolués, accessibles par raccourcis clavier, donc pas forcément visibles. Je conseille de passer un petit moment à regarder le tuto de M$, c'est assez instructif et on voit que ça va quand même plus loin que l'éditeur de code.
Merci pour l'info, je vais tester ça rapidement !
De ce que j'ai vu, la dernière version de SharpDevelop ne fait pas encore tourner .Net Core.
Il y a aussi monodevelop qui est utilisé notamment avec Xamarin, mais bon on est quand même loin de visual studio...
on voit que le sujet ne passionne pas les foules, trop peu de concret pour l'instant.
Y avait il d'ailleurs une attente pour le .Net en open source ?
J'ai bien peur qu'il n'y ait que M$ intéressé par cela, et un peu tard.
Seuls ceux qui sont déjà acquis à MS sont intéressés par le sujet et le passage en OpenSource pourrait être interprété comme un début de lâchage sur le long terme.
Ceux qui développent du web, seul sujet qui semble avoir de l'avenir, ne croient pas en .Net pour du web.
Va falloir que M$ mette le paquet pour faire rêver sinon ca fera Pschitt et ce serait vraiment dommage.
L’intérêt peut être de faire du multiplate-forme dans quelques années avec des technos comme Wpf ou UWP, du côté d'Asp.Net MVC ça commence à être fonctionnel.
C'est limite du troll, énormément de nouveau projet sont développé en Asp MVC, je ne vois pas pourquoi celui-ci serai abandonné, les alternatives que sont Php ou Java pour le web ne propose rien qui soit tellement mieux que Asp MVC qui pousserait à migrer sur ces plateformes, sinon il y a Node pour faire du Javascript côté serveur mais je pense que ça rebute plus les développeurs d'en faire que les décideurs.
Donc d'ici que Asp soit poussé vers la sortie tu as encore le temps mais pour les 10 prochaines années (estimation basse) il y aura encore du boulot dessus et encore après avec la maintenance.
Répondre avec citation
Partager