.NET Core 2.0 : vague de fond sur le développement multiplateforme chez Microsoft

.NET Core 2.0 : vague de fond sur le développement multiplateforme chez Microsoft

Il y a .NET et .NET

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

22/09/2017 10 minutes
34

.NET Core 2.0 : vague de fond sur le développement multiplateforme chez Microsoft

Mi-août, Microsoft lançait .NET Core 2.0. Si ces technologies sont connues depuis des années, elles ont passé durant l’été un cap important. Au cœur des nouveautés, on trouve notamment .NET Standard 2.0, une version largement étoffée du socle API. L’ensemble peut désormais prétendre à un vrai statut de solution multiplateforme.

L’environnement .NET existe depuis 2002. Pour beaucoup, ces technologies sont intimement liées à Windows et permettent le développement de solutions allant de l’application classique aux composants de serveurs. .NET se sert d’un environnement d’exécution basé sur la Common Language Infrastructure (CLI), implémenté sous forme de  Common Language Runtime (CLR).

Bien que la « voie royale » pour utiliser cet environnement soit le langage C# (développé initialement par Anders Hejlsberg, qui avait créé Delphi), d’autres sont pris en charge, .NET en étant indépendant. Tous les programmes sont transcodés dans un premier temps en bytecode, intermédiaire avant la compilation proprement dite, un fonctionnement qui le rapproche de Java (auquel .NET est souvent comparé du fait de son code managé).

Initialement, .NET a été créé pour effacer progressivement la frontière entre applications classiques et web, mais l’environnement restait invariablement lié à Windows. Bien que des produits comme Xamarin (depuis rachetée par Microsoft) aient cherché à faire de .NET et C# des solutions de développement multiplateforme, la vision n’a réellement commencé à se concrétiser qu’avec l’arrivée de .NET Core.

.NET Core et la nouvelle orientation multiplateforme

Quand Microsoft lance la version 1.0 de .NET Core, les développeurs voient débarquer un remaniement complet de la technologie, tiré d’un sous-ensemble du framework existant. Plus question cette fois d’un environnement centré sur Windows : Microsoft a repris son produit depuis le début pour un faire un socle multiplateforme.

Sûre d’elle, l’entreprise avait même annoncé cette version durant le Red Hat Summit. Pourquoi ? Parce qu’en plus de changer complètement d’orientation, l’éditeur a créé en même temps la .NET Foundation, qui gère désormais l’environnement devenu open source.

Voilà d’ailleurs comment est présenté .Net Core : un ensemble de technologies pour Linux, macOS, Windows et autres, dont le code est protégé par une licence Apache 2.0 ou MIT selon les cas, avec des dépôts GitHub associés.

Cet ensemble est modulaire. Il ne s’agit plus d’un framework complet, mais de technologies que le développeur peut utiliser ou non selon le contexte. Ces composants sont distribués sous forme de paquets NuGet, et il n’est plus question d’un environnement présent sur la machine : il est embarqué avec l’application, ou plus globalement le projet.

L’appellation « .NET Core » sert en fait de parapluie. On retrouve des éléments comme CoreCLR, le moteur d’exécution lui-même, la bibliothèque .NET Standard qui définit le socle fonctionnel via les API (pour toutes les plateformes), ASP.NET Core, Entity Framework et autres.

La version 1.0 sortie l’année dernière avait le mérite de tracer une ligne nette dans le sable, indiquant aux développeurs que tel était désormais le futur du développement .NET. La parité fonctionnelle était cependant loin d’être atteinte. La mouture 1.1 améliorait la situation quelques mois plus tard, mais c’est surtout .NET Core 2.0, sorti le mois dernier, qui change réellement la donne.

.NET Standard 2.0 fait le grand saut

L’un des plus gros changements de cette deuxième version majeure est l’accélération de la spécification .NET Standard. Le nombre d’interfaces disponibles pour les développeurs passe ainsi de 13 000 à 32 000. Les fonctions couvertes sont donc beaucoup plus nombreuses et arrivent presque au niveau de l’ancien Framework .NET 4.6. En fait, les écarts se font surtout sur des possibilités liées à Windows, non incluses puisque .NET Core est un environnement multiplateforme, bien que les p/invoke y soient toujours possibles.

.NET Standard 2.0 est probablement l’élément le plus important de l’ensemble. Un lot commun d’API et un moteur d’exécution multiplateforme permettent aux développeurs de se focaliser sur leur projet sans normalement tenir compte des spécificités de chaque système. .NET Standard 2.0 est considéré comme isofonctionnel et est supporté par le .NET Framework 4.6.1, .NET Core 2.0, Mono 5.4, Xamarin iOS 10.14, Xamarin.Mac 3.8 et Xamarin.Android 7.5. La prise en charge par UWP (Universal Windows Platform) sous Windows 10 doit arriver avant la fin de l’année.

.NET Standard 2.0 ajoute également un important mode de compatibilité venant compenser en partie l’un des reproches majeurs faits à la première version de l’environnement. En théorie, il permet au développeur de faire référence dans son projet à une API d’un ancien Framework. En pratique, ce n’est possible qu’avec celles référencées dans .NET Standard, d’où l’importance de cette version 2.0 et ses 32 000 API. Par ailleurs, les paquets NuGet n’ont plus besoin de déclarer de dépendances aux composants de .NET Core 2.0 : elles sont directement fournies par le SDK de l’environnement.

L’insistance particulière de Microsoft sur le multiplateforme est marquée : le développement sous Windows devient en quelque sorte moins important que la possibilité de pouvoir exécuter son code partout. Un projet .NET Core 2 développé dans Visual Studio 2017 par exemple pourra cibler tout ou partie des systèmes pris en charge. Dans la plupart des cas, le code sera strictement identique. Ce n’est qu’en abordant certains points que des suppléments seront à prévoir.

Les améliorations principales de .NET Core 2.0

La nouvelle version commence par augmenter le nombre de plateformes officiellement prises en charge. Debian Stretch, SUSE Linux Enterprise Server 12 SP2 et macOS High Sierra sont notamment de la partie. Linux est également traité désormais comme une plateforme unique. La compilation se fait toujours par architecture, mais toutes les distributions testées sont compatibles, essentiellement celles basées sur glibc (surtout Debian, Red Hat et leurs dérivés). Red Hat fournit d’ailleurs un support officiel de .NET Core 2.0.

Depuis la mouture précédente, Microsoft indique que les performances sont nettement à la hausse dans presque tous les domaines. Autre changement important, le compilateur RyuJIT est présent dans la version x86 de l’environnement pour tout ce qui touche au just-in-time (compilation à la volée). Il était déjà présent en version x64 mais remplace ici l’ancien compilateur JIT32, avec lequel il est totalement compatible et qui sera supprimé de la plateforme.

Microsoft indique que le comportement général de .NET Core 32 bits sera de fait beaucoup plus proche de la mouture 64 bits. Il ne faut cependant pas s’attendre à de grands écarts de performances sur le code dans cette version particulière de RyuJIT, comme l’éditeur l’expliquait en avril dernier. Cependant, le nouveau compilateur a davantage de fonctionnalités et réalise certaines opérations de manière plus efficace, notamment tout ce qui touche aux calculs en virgule flottante.

Enfin, bien que l’on parle ici d’une version finale de l’environnement, Microsoft en a profité pour glisser des préversions ARM32 du .NET Core Runtime pour Linux et Windows. Et signalons dans une moindre mesure la compatibilité de Visual Basic avec .NET Core, même si ses attributions se limitent pour l’instant au développement de bibliothèques de classes et d’applications console.

Notez que l’installation de .NET Core 2.0 ne remplace pas les versions 1.0 et 1.1 de l’environnement. Elles restent concurrentielles, et les applications conçues pour des moutures antérieurs continueront à le faire sans craindre une quelconque incompatibilité.

Quid d’ASP.NET Core 2.0 et Entity Framework Core 2.0 ?

Bien qu’éléments importants de l’ensemble, ASP.NET Core et Entity Framework Core ne font plus partie du tronc commun. Comme indiqué précédemment, l’environnement est modulaire, et ces éléments ne seront donc appelés que si le développeur en a besoin.

Comparativement au reste, ASP.NET Core 2.0 propose moins de nouveautés, mais certaines sont importantes. Pour simplifier le travail de ceux qui en ont besoin, Microsoft propose ainsi un métapaquet Microsoft.AspNetCore.All pour récupérer d’une traite tous les paquets nécessaire aux projets ASP.NET. La modularisation avait en effet entrainé une multiplication des paquets, provoquant l’agacement de certains.

Plus significatif, ASP.NET Core 2.0 introduit les Razor Pages, une alternative à l’architecture classique MVC (Model-View-Controller) quand le développeur travaille sur un projet centré sur les pages elles-mêmes. Il se concentre alors sur leur conception et l’interface utilisateur. Il n’y a plus par défaut qu’un seul fichier .cshtml contenant l’ensemble de la page. Solution tournée vers les petits et moyens projets, ou pour les débutants, elle permet dans un projet vide d’ajouter un dossier Pages puis de créer autant d’éléments PageModel que l’on souhaite.

Microsoft fournit en outre un nombre plus important de modèles, dont un nouveau justement pour les Razor Pages. D’autres se concentrent sur les scénarios SPA (single-page-applications), qui utilisent les JavaScript Services pour embarquer NodeJS dans ASP.NET Core côté serveur. Les applications JavaScript sont également compilées en même temps que le reste du projet.

Parmi les autres nouveautés, signalons une importante simplification de la configuration Host via un nouveau WebHost.CreateDefaultBuilder présent par défaut dans tous les modèles ASP.NET Core. Citons également un renforcement du serveur web Kestrel via la déclaration de limites (connexions clients entre autres), la compilation par défaut des vues et pages Razor pendant la publication (elle peut être désactivée).

Entity Framework est de son côté un O/RM (Object/Relational Mapping), à savoir une bibliothèque faisant le lien entre une base de données et son équivalent en modèle objet. Il permet donc de réaliser des requêtes (en LINQ ou en SQL) pour récupérer des éléments dans la base pour les transformer en objets exploitables par le développeur.

La version 2.0 du framework apporte là encore des nouveautés, notamment une traduction LINQ vers SQL améliorée, l’ajout de l’opérateur Like dans LINQ, la possibilité de définir des entités owned et child, l’ajout de filtres globaux pour les requêtes ou encore les requêtes explicitement compilées.

Pour se lancer dans ASP.NET Core 2.0

Il existe déjà plusieurs moyens d’exploiter les nouvelles versions de ces briques, même si l’installation du SDK est dans tous les cas obligatoires. Comme Microsoft l’indiquait dans son annonce, le développeur devra disposer au moins de la version 15.3 de Visual Studio 2017, ou des dernières révisions de Visual Studio pour Mac ou de Visual Studio Code. Pour ce dernier – et qu’il s’agisse de Linux, macOS ou Windows – l’extension C# sera nécessaire.

34

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

.NET Core et la nouvelle orientation multiplateforme

.NET Standard 2.0 fait le grand saut

Les améliorations principales de .NET Core 2.0

Quid d’ASP.NET Core 2.0 et Entity Framework Core 2.0 ?

Pour se lancer dans ASP.NET Core 2.0

Commentaires (34)


Il n’y a que moi que ça fait hérissé les poils d’entendre parler de bytecode au lieu de MSIL ? (même si c’est fondamentalement équivalent).

Je m’en rappelle à l’époque, il fallait parler du Bytecode Java, et du MSIL de C# au risque de se faire mal voir <img data-src=" />


Si je voulais être pédant, je ferais remarquer qu’on ne dit plus MSIL mais CIL&nbsp;<img data-src=" />


Nous nous en servons au travail, très bon produit que ce .Net Core, Microsoft est sur la bonne voie&nbsp;<img data-src=" />


comme l’indique le lien aussi au mot bytecode de l’article le mot “bytecode” est un terme générique: CIL (MSIL) est un bytecode, le java bytecode est un bytecode, les fichiers python “pyc” sont du python bytecode, etc.


Je compte l’utiliser pour un nouveau projet. Je suis en train de me former dessus les améliorations sont vraiment sympa :)


Très classe mais quel retard! C’est un peu ce qu’on pensait voir arriver à la sortie de Windows 10 ou peu après.



Testé sur&nbsp;trois petits projets (mais sous Windows seulement):

&nbsp;* ciblage en Core.Net plutôt simple (bon, j’ai recréé les projets et la solution et copié les fichiers sources)&nbsp;

&nbsp;* performance au moins identique à .Net 4.5 (souvent visiblement mieux sans besoin de bencher)

&nbsp;* idem pour la mémoire: ça monte moins vite et moins haut



Par ailleurs, le serveur web intégré est très léger



–&gt; On voit bien que la cible des environnements type “docker” a été très travaillée.


Je bosse avec la version 1.1 et EF7 actuellement, ça fonctionne plutôt bien. Des fois EF me joue des sales tours avec des drops en cascade que je demande pas mais c’est une autre histoire.&nbsp;



Ce qui manque à EF7, le support des vues ! Ca faciliterait la vie sur certaines récupérations de données. Surtout quand tu bosses avec des données issues de cubes BI…



Quant à .net Core 2.0 reste à voir si ça s’est amélioré. Il manquait quelques éléments lors de certains devs spécifiques mais rien de grave.


Questions pour ceux qui savent: Quel type d’application est visé ?


Bibliothèques, applications web et console. Les applications avec interface graphique (Desktop, Mobile) ne sont pas prises en charge.&nbsp;

&nbsp;


C’est prévu ?&nbsp;


De ce que je sais, à court terme, non.&nbsp;



Par contre, il y a une initiative qui est une première brique dans ce sens : XAML Standard 1.0. Il s’agit notamment de spécifier les composants de base (bouton, label, etc…) utilisable avec XAML.



L’idée est de permettre une certaine portabilité des interfaces utilisateurs en les réutilisant, qu’importe le type d’application (tout comme .Net Standard permet de définir des bibliothèques utilisables quel que soit le type de projet).


Merci pour l’info !




Voilà d’ailleurs comment est présenté .Net Core : un ensemble de technologies pour Linux, macOS, Windows et autres





Ca perce un peu les solutions .NET Core dans le monde Linux/Mac/autre… ou ca reste cantonné à Windows ?


j’ai toujours fait&nbsp; du dev avec des versions pro de Visual Studio, du coup je ne suis pas très au courant des autres versions.

Mais quelle est la différence entre la version Code et Community ?

J’ai l’impression que Community est une version complète alors que Code est light

mais les deux sont gratuits, et si biensur mon hypothèse de départ est bonne, a quoi sert la version Code ?



&nbsp;


La Community est une version Pro oui. La version Code s’oriente davantage vers le web dev, mais n’y est pas cantonnée si tu ajoutes les modules qui vont. L’avantage est surtout la légèreté, et si tu fais du multiplateforme, ça peut être pas mal aussi, puisque tu as la même chose partout.


Questions de noob qui ne connais pas bien ces technos :



Nous avions fait développer une application web (qui utilise des interfaces REST pour communiquer avec une tablette), pas d’interface graphique. Elle s’interface avec PostgreSQL. Elle avait été faite sous Windows, en C# je crois et avec .NET 4.5 (je crois aussi).



Question : serait-il possible de faire tourner cela sous Linux sans trop de modifications et même le foutre dans un container (Docker) ?



https://docs.microsoft.com/en-us/dotnet/framework/get-started/overview


Ok Merci <img data-src=" />








Vincent_H a écrit :



La Community est une version Pro oui. La version Code s’oriente davantage vers le web dev, mais n’y est pas cantonnée si tu ajoutes les modules qui vont. L’avantage est surtout la légèreté, et si tu fais du multiplateforme, ça peut être pas mal aussi, puisque tu as la même chose partout.





Pour préciser.



La “famille” Visual Studio se découpe principalement en 2 branches (si l’on oublie TeamServices,…):





  • &nbsp;La classique : Community, Pro et Enterprise.

  • &nbsp;La “multiplateforme”: Code qui se base sur l’éditeur Atom codé avec en NodeJS.





    Depuis la version 2015 de Visual Studio “classique”, ils ont changé la gamme.

    Avant, tu avais :



  • &nbsp;Express (version limitée gratuite)

  • &nbsp;Pro

  • &nbsp;Premium

  • &nbsp;Ultimate

  • &nbsp;(on oubliera la Test Pro).



    &nbsp;

    &nbsp;Maintenant :



  • &nbsp;Community (équivalent à la Pro avant en gratuit),

  • &nbsp;Pro (équivalent Premium)

  • &nbsp;Enterprise (équivalent Ultimate)





quel est l’ordre de grandeur de temps d’exécution entre ce bytecode et du code natif ?








ashlol a écrit :



quel est l’ordre de grandeur de temps d’exécution entre ce bytecode et du code natif ?






Difficile de comparer.     





Le code natif, comme son nom l’indique, est fait pour tourner dans un environnement particulier (OS CPU, …).

Donc, il sera optimisé pour cela.



Le bytecode .Net, est fait pour tourner quelque soit l’environnement. Il est “recompilé” par le CLR à la volée (JIT) lors de la première exécution et le “résultat” est placé dans un cache pour les exécutions suivantes (si le code n’a pas changé).



Une autre différence, c’est que le code natif est du code “non-managé” donc la gestion de la mémoire est à la charge du développeur là où le framework .Net te fournit des composants pour cela (code managé).



Donc, tu n’auras jamais de performances équivalentes et la différence de performance sera difficilement comparable dû aux différences des environnements (managé vs non-managé).









ashlol a écrit :



quel est l’ordre de grandeur de temps d’exécution entre ce bytecode et du code natif ?





Qu’entends-tu par code natif? Un algo&nbsp;compilé par le compilo standard ou un code de benchmark ultra optimisé développé aux petits oignons?



Le bytecode a fait d’énormes progrès, notamment lié à la limitation du nombre d’objets “intermédiaires” créés pour avant d’appeler du code “natif” (donc l’overhead).

&nbsp;

Il est très efficace, pour peu qu’on sache l’utiliser (avoir un garbage collector ne signifie pas qu’on peut créer des millions d’objets en mémoire sans se soucier des conséquences).

&nbsp;

Pour le calcul, il se débrouille, mais reste en deçà de ce que te fournirait un compilateur qui fait e fortes optimisations (notamment SIMD), mais ça reste&nbsp;une utilisation rare pour laquelle d’ailleurs on aura tendance à utiliser un GPU actuellement si on cherche des perfs.



Par ailleurs, .Net t’apporte des syntaxes de dingue (async/await) qui permettent de paralléliser un programme assez naturellement. Donc gain en réactivité que tu aurais du mal à obtenir en C/C++.



En clair: choisir le langage est surtout une question de cible de programme. Pour un programme qui doit tourner dans un temps fini, des ressources mémoire limitées et une faible contrainte de tolérance aux pannes, je préfère du C++ (encore que je peux y faire des entorses), pour un programme qui tourne à l’infini/qui doit récupérer d’un peu n’importe quelle erreur&nbsp;je préfère du .Net (ou autre chose avec un GC et une librairie qui est cohérente dans la gestion des erreurs).



oui j’entends compilé par un compilateur standard pour la plateforme en question.



j’avais vu il y a longtemps qu’il y avait pas mal de différence entre du .net et du c++.



pour la parallélisation en c++ c’est pas vraiment compliqué t’ouvres un/plusieurs thread de plus et avec des sémaphores pour la synchro des threads ça passe crème.



Qu’entends tu par récupérer de n’importe quelle erreur ? Tout est testé automatiquement sans rien devoir écrire ? si oui ça doit quand même ajouté un paquet d’instruction et donc de temps d’exécution.


clairement c’est difficile de comparer mais je me demandais si pour une appli spécifique quelqu’un avait fait un test entre les 2. Le code natif tourne effectivement sur une architecture de CPU genre x86 et sur une famille d’OS genre windows mais il existe des environnements de dev qui permettent de faire du code natif pour différent OS ou architecture CPU donc plusieurs “exécutables” à la fin mais le même code à la base.

&nbsp;

justement la gestion de la mémoire est quelque chose d’important, la laissé libre à la librairie fait qu’on se retrouve avec tout un paquet d’application “codé avec les pieds” ou qui consomme je ne sais pas combien de ram pour ne rien faire.


Une application mal codée, quel que soit le langage, elle sera pourrie (et d’autant plus dans un langage natif j’ai envie de dire).

La plupart des problèmes de perfs viennent du code plus que du langage. Il n’y a bien que dans des cas particuliers que le code natif a encore du sens, et il ne sert à rien de prendre 3 fois plus de temps à développer une appli en C++ quand on peut faire la même chose en C#/Java/…



S’il est vrai que la gestion de la mémoire est importante, c’est bien là que les langages managés sont bien plus intéressants. Il est beaucoup plus facile de détecter les fuites de mémoires et les corriger que dans du code natif.

On notera d’ailleurs que .Net Core a amélioré beaucoup de choses sur la conso de certaines classes de base, notamment pour limiter le nombre d’allocations et réduire les cycles du garbage collector (voir ici :https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-improvements-in-n… ).


oui effectivement en natif ça peut vite mal finir :P



les problèmes de perf peuvent venir du code effectivement mais lorsqu’il y a une couche supplémentaire comme ici entre bytecode et code natif cela ajoute forcément du temps donc un bytecode sera presqu’à tous les coup plus lent qu’un code natif mais il y a la question du temps pour le faire c’est sûr.



pas sûr que cela soit plus facile de trouver une fuite mémoire sur du code managé car au moins sur du non managé le code plante et puis basta alors que sur le managé la conso ram va augmenter jusqu’à prendre tout ce qui est disponible/allouable.



j’imagine bien qu’ils ont amélioré avec .net core et merci pour le lien c’est plus ou moins ce que je cherchait à savoir. Impressionnante amélioration de 30à50% par rapport à .net 4.7 sur pas mal d’opérations ça doit commencer à être intéressant va vraiment falloir que je regarde ça de plus près.








ashlol a écrit :



quel est l’ordre de grandeur de temps d’exécution entre ce bytecode et du code natif ?





J’ai en tête un benchmark C# / C++ où en gros le code C# était environ 2 fois plus lent que le C++. Je ne me rappelle plus des conditions exacts, mais c’était grosso modo dans des cas où les 2 codes étaient à peu près bien codés sans non plus chercher l’optimisation ultime.





Strimy a écrit :



Une application mal codée, quel que soit le langage, elle sera pourrie (et d’autant plus dans un langage natif j’ai envie de dire).

La plupart des problèmes de perfs viennent du code plus que du langage. Il n’y a bien que dans des cas particuliers que le code natif a encore du sens, et il ne sert à rien de prendre 3 fois plus de temps à développer une appli en C++ quand on peut faire la même chose en C#/Java/…



S’il est vrai que la gestion de la mémoire est importante, c’est bien là que les langages managés sont bien plus intéressants. Il est beaucoup plus facile de détecter les fuites de mémoires et les corriger que dans du code natif.

On notera d’ailleurs que .Net Core a amélioré beaucoup de choses sur la conso de certaines classes de base, notamment pour limiter le nombre d’allocations et réduire les cycles du garbage collector (voir ici :https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-improvements-in-n… ).





Je suis d’accord sur le fait que le développement est plus rapide en C# / Java comparé au C++, mais c’est surtout parce que les librairies livrées en standard ne sont pas comparables : en C++ tu as les conteneurs de base, quelques algo simple, et tout le reste il faut aller le chercher dans des librairies externes.

En revanche, je mettrais un bémol sur ta remarque sur les fuites mémoires : en C++, tu peux assez facilement savoir d’où viennent les fuites en remplaçant les new par des macros (la manière dégueulasse). Même mieux en utilisant des smart pointer, tu n’as presque plus besoin de te préoccuper des fuites. Dès lors que tu utilises des smart pointer partout (où il y en a besoin), tu te retrouves au même niveau que C# et Java, à savoir : éviter les dépendances cycliques entre objets sinon ils ne sont jamais détruits.









ashlol a écrit :



quel est l’ordre de grandeur de temps d’exécution entre ce bytecode et du code natif ?





http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharpcore&…



Evidemment c’est du bench, c’est à prendre avec des pincettes mais on peut en conclure que :




  1. temps d’execution similaires

  2. occupation mémoire x2 au minimum



Le principe des Razor Pages ressemblent beaucoup aux WebForms, Microsoft compterait-il abandonner WebForm pour Razor sans dérouter les aficionados ? Cela lui permettrait de migrer toute la communauté ASP.NET autour d’un même langage d’interface, modulo quelques spécificités.



A moins que ce soit pour les faire passer au .NET Core ?


Je vois plus grand monde utiliser les webform (sur des nouveaux projets).

&nbsp;Razor peut-être mais surtout on couple avec de l’angular ou autre joyeuseté JS à la mode&nbsp;<img data-src=" />








PèrePatience a écrit :



Je vois plus grand monde utiliser les webform (sur des nouveaux projets).

&nbsp;Razor peut-être mais surtout on couple avec de l’angular ou autre joyeuseté JS à la mode&nbsp;<img data-src=" />





Peut être aussi pour une “migration” en douceur des anciens projets ?









Strimy a écrit :



On notera d’ailleurs que .Net Core a amélioré beaucoup de choses sur la conso de certaines classes de base, notamment pour limiter le nombre d’allocations et réduire les cycles du garbage collector (voir ici :https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-improvements-in-n… ).





Intéressant ce lien. En voyant le code source des modif, c’est instructif voir étonnant des fois.









ashlol a écrit :



j’avais vu il y a longtemps qu’il y avait pas mal de différence entre du .net et du c++.&nbsp;

&nbsp;



Sur de l’algo de calcul, je ne pense pas que .Net ait fait de gros progrès.



Les performances des langages recompilé à chaud dépendent souvent de multiples overhead ajoutés entre la plate-forme du langage et les API.

Là où les langages type java/.Net gagnent en perfs, c’est souvent sur les allocations mémoire … au détriment du temps nécessaire pour désallouer cette mémoire. Par contre ils ont l’avantage d’éviter (ou plutôt de repousser pour .Net) des problèmes de fragmentation mémoire (saturation de la mémoire par allocation de petits ensembles et désallocation sauvage).

Par ailleurs, parfois il faut raisonner en temps de réponse plutôt qu’en temps de calcul (par expl ne pas compter le temps de “garbage collect” qui suit la réponse). Tout dépend de la priorité du dev.

Pour la majeure partie des cas que j’ai pu traiter, .Net a fait le job, mais on a pu rencontrer des problèmes non prévus (exemple sous Windows 32 bits: la limite d’un process est bien de 2Go, mais ça fait environ 1.1Go de données pour une plate-forme .NET 1.1 qui a besoin de place pour le GC)



Une chose qui est différente entre C et .Net/Java: en C rien ne t’empêche de compiler du code qui va rechercher de la mémoire en dehors d’un tableau, .Net et Java vérifient systématiquement que tu n’es pas en dehors.

C’est sûr que c’est plus lourd, mais pour du dev en entreprise, c’est bien plus sécurisé.





ashlol a écrit :



pour la parallélisation en c++ c’est pas vraiment compliqué t’ouvres un/plusieurs thread de plus et avec des sémaphores pour la synchro des threads ça passe crème.&nbsp;



.Net a poussé le vice très très très loin je trouve avec la possibilité d’écrire des codes où chaque instruction&nbsp;“bloquante” peut laisser la place à une autre charge de travail, et ce, sans créer ses sémaphores.

Les points de passage de contrôle d’un thread à l’autre sont multipliés par rapport à un code C/C++ “classique”. De plus le programmeur est abstrait des notions de Thread. .Net gère.

Après j’avoue ne pas avoir suivi les évolutions C++ de ce côté.





ashlol a écrit :



Qu’entends tu par récupérer de n’importe quelle erreur ? Tout est testé automatiquement sans rien devoir écrire ? si oui ça doit quand même ajouté un paquet d’instruction et donc de temps d’exécution.



Comme tes souvenirs de différences de perfs entre C et .Net, moi j’ai des souvenirs de gestion des exceptions différentes et incompatibles entre 2 librairies C++ et d’une gestion “à la mano” du code d’erreur après chaque appel système en C.

Je préfère Java qui force à nommer les erreurs qui peuvent se produire, mais les Framework type .Net et java sont très bon pour une récupération sur erreur, là où les bibliothèques C++ m’ont parfois laissé dans des états impossibles à récupérer sans arrêt de l’appli.









Strimy a écrit :



S’il est vrai que la gestion de la mémoire est importante, c’est bien là que les langages managés sont bien plus intéressants. Il est beaucoup plus facile de détecter les fuites de mémoires et les corriger que dans du code natif.&nbsp;



D’expérience, je&nbsp;ne suis pas d’accord.



&nbsp;En code managé, la fuite mémoire a moins d’impact, mais elle existe. Les programmes sont plus résistants aux fuites mémoire, mais&nbsp;ça n’empêche pas d’en faire et d’avoir un impact différent (dans mon exemple: 50% de CPU soutenu&nbsp;dans le GC - toutes les x minutes)

&nbsp;

Quand à les détecter…



Voici un exemple: une routine crée en boucle des chaînes de caractères.



Dans du code non managé, on finira certainement par créer un “out of memory”. On aura un dump “post mortem” représentatif



Dans du code managé, on constatera plutôt une occupation CPU liée au GC importante. Cela signifie aussi que le GC nettoie les preuves régulièrement. De plus, il se déclenche de façon non synchrone avec la routine que l’on cherche.

-&gt; on passe par un dump et un analyseur, mais comme tout crée des chaînes de caractères, on ne sait pas toujours quoi chercher parmi les millions d’instanciations. Je passe sur les performances d’un analyseur et l’espace de données nécessaire pour collecter les&nbsp;infos, et le passage quasi systématique par WinDBG/SOS (en gros, revenir quasiment à l’assembleur pour déboguer du .Net), et le “bruit” généré par les appels à EntityFramework et les chargement de Datasets qui instancient énormément de chaînes de caractères…



Au final (attention, de mémoire donc pas trop de détails), le problème venait d’une initialisation de Datasets réalisé dans une boucle, au lieu de remettre à zéro le même à chaque itération. résultat:&nbsp;tous les datasets étaient maintenus en mémoire ainsi que leurs données. A cause d’un lien inutile ils étaient maintenus en vie pendant l’exécution de la routine (un gros truc qui faisait plein d’autres appels qui eux-mêmes créaient des datasets). Les datasets restaient suffisamment longtemps pour passer en génération 1 pour le GC. Et ainsi ils étaient récupérés plus tard, en cas de pression mémoire, lors d’un GC de génération 1. Le GC de génération 0 libérait toutes les chaînes de caractères liées aux Datasets.



-&gt; Je pense que sans GC, ce type de problème est détecté lors de la libération mémoire “manuelle”.