Reprise du message précédent :
Messieurs, avec les versions modernes de Visual Studio (sous Visual Studio Installer quoi), c'est safe désormais d'installer la version n-1 après avoir installé la nouvelle ?
Une réparation de la nouvelle version est à prévoir une fois l'ancienne désinstallée ?

Aucun soucis d'ordre entre 2017-2019-2022, et probablement avec d'autres versions. Tu peux même mixer les éditions sans soucis

Yes c'est ce que j'ai fait là, 2022 Pro à côté d'une 2017 entreprise.
Mais du coup je peux desinstaller la 2017 sans risques de péter la 2022 ?

Yes, déjà testé. Je n'ai pas eu de soucis

Top, merci

Pas de soucis. J'ai viré 2015 et 2017 il y a 3 semaines pour garder que 2019 et 2022, sans aucun soucis.

Sinon, je viens de voir que .net 6.0 était passé de base en LTS alors que 5.0 n'y a pas eu le droit  

Une version sur deux est LTS -> 7.0 ne le sera pas, 8.0 le sera

C'est moi où la version 2022 est bien plus longue et lente que la 2019

Ok... c'est couillon car 5.0 était un gros debug/updater de 3.1 (qui lui est LTS)...

Dommage , je garde mon 5.0 pour mes besoins et je passe mes client sous 6.0 ( qui est pas trop mal pour l'instant )

Heu..  c'est plutôt l'inverse normalement... sous 22 j'ai l'impression d'avoir un 19 sous stéroïdes

C'est pas normal, c'est le contraire et de loin chez moi comme au boulot

5.0 et core 3.1 sont très très éloignés, ce n'est pas un "gros debug" du tout. 5.0 est la réunification de .Net Framework et dotnet core et netstandard. Ce framework est loin d'être performant. Pour de la prod, mieux vaut rester sur 3.1 ou aller sur 6.0. La v6 est une stabilisation et perf optimisation de la v5

Si ça ne tenait qu'à moi... hors le problème c'est que mes clients sont frileux (comme tous...) et entre ceux qui veulent rester en 3.1 car LTS et ceux qui veulent du 5 car ils ont pas confiance en 6.0 car trop récent... bah c'est relou... je suis rendu au point de faire que du self embebed pour masquer la supercherie.. mais ça fait chier de pondre des package de 120mo pour des petits trucs de merdes parfois  

Ah bah chez moi aussi VS2022 est incroyablement plus performant, réactif et rapide toute tache confondue, que les 2017 et 2019

+1 pour la partie où ils sont éloignés ; je trouve d'ailleurs le planning officiel un peu sportif, .Net 6 est dispo en GA sur Azure depuis genre 1 mois maximum et fin du support .Net 5 genre en mai Alors OK, on a rarement besoin du support MS sur .Net m'enfin quand même c'est chaud, on a du .Net 5 en prod les gars

Pendant ce temps, l'équipe IT d'une ancien client à moi peaufine la migration de son CRM interne historique vers .NET Core 3.2 ...

C'était annoncé dès l'alpha la durée de vie de la 5.0 et la non recommandation d'utilisation sur les projets prod long-terme sans prévision de migration en 6.0

C'est 2.2 (ultra deprecated) ou 3.1, mais pas de 3.2

C'est 3.1, effectivement

De notre côté on étudie le passage de la 3.1 à la 6 mais je sens bien que ça peut être galère...

C'est 3.1 vers 5 qui pique ; 5 vers 6 ça va bien se passer. J'ai fait 3.1 -> 5 en novembre sur notre plus grosse codebase, en faisant bien attention et en suivant le guide officiel, y a eu 0 problème. Mais c'est long, faut être vigilant et bien lire les liens qui parlent de trucs qui cassent ou de packages qui ne sont plus maintenus car faisant partie du framework.

J'entends mais la migration 3.1 -> 5 est déjà pas triviale et passer directement à la 6 alors qu'elle vient de sortir ça fait un peu peur aux directions/équipes ops.

Le choix va devoir être rapidement fait : le support pour la 3.1 expire le 03/12/2021, la 5 jusqu'au 08/05/2021, après faudra assumer les failles. Chaque LTS dure 3 ans, avec une période de recouvrement d'un an minimum, et prévisible. Ca laisse le temps d'intégrer au planning logiquement, surtout que l'effort n'est pas si énorme suivant ton cas. Typiquement pour moi qui n'utilise ni razor ni blazor (API pur), c'est l'histoire d'un jour.

Après le temps de migration ne dépend pas que du FW de départ, mais plein d'autres trucs comme tes dépendances embarquées, de tes tests unitaires (pour fiabiliser le truc rapidement), de tes environnements où tu dois déployer (web, client lourd, parc homogène et maitrisé ou non...).
 
Mais on est d'accord que passer du 5 au 6 ça semble très simple. Sauf cas exotique en général tu augmentes le FW dans les csproj, tu upgrades les packages nuget et basta.
Même sur du Web (t'es pas obligé d'adapter les simplifications syntaxiques du 6 pour recompiler une appli web faite en 5, etc).

 
Crois moi, l'effort il n'est absolument pas de mon côté... mais de celui des clients

As-tu remarqué des baisses de performance ? Chez mon client actuel, on y songe dans certaines situations mais je n'ai pas eu l'occasion de benchmarker ça

 
Non, aucune.. après, j'ai pas spécialement mesuré non plus, mais au ressenti, pas de différence.
 
par contre, ça fait chier de trimbaler entre 80 et 140 mo pour un pauvre outils avec 4 fenêtres et 3 services mais au moins, on se fade pas la validation de l'installation du framework XY par la DSI du client...  
 
Pour les gros outil de prod, par contre, on se plie à ce qui est disponible chez eux.. mais on pousse aussi de plus en plus vers du Docker/Kubernetes pour eviter au maximum d'être dépendant de leur infra... mais c'est pas toujours facile non plus à faire passer

Hello,
Petite question LINQ toute simple pour les amateurs de MoreLINQ et autres librairies du même genre :
https://stackoverflow.com/questions [...] to-objects

C'est pas vital et ça marche très bien de la façon que j'utilise déjà mais je me dis que le besoin est plutôt basique alors il y a sans doute un mec qui a écrit un truc concis pour faire ça, genre "prendre le dernier élément de chaque partition sur X en triant par Y" .
Merci

En .Net 6 tu peux remplace :

prp.OrderByDescending(o => o.Time).First()

par :

MaxBy(o => o.Date)

MoreLINQ permet aussi de le faire semble-t-il, ça sera plus performant

https://stackoverflow.com/a/9143173

Bonsoir, ici est-ce le bon endroit pour des questions existentielles mais qui ne feront rien avancer ?
Par exemple, j'aime beaucoup l'instruction "foreach" depuis le début c# 1.0 et je serais très frustré qu'elle n'existe pas. Cependant je me demande de plus en plus si elle nécessaire. Quelle grosse différence y-t-il vraiment entre ces deux codes !?

Point de vue compilateur, la 1ère version a besoin de la construction de machines à états, la seconde uniquement de bêtes fonctions.
A l'exécution, je ne pense pas qu'il y ait de différence fondamentale de vitesse (même s'il ne se passe pas exactement la même chose)

Bien sûr, en codant, je préfère la 1ère version. Les 'parenthèses-crochets' de la 2nd version c'est un peu de la merde surtout avec des boucles imbriquées... mais sans ce détail qu'est ce qui justifie la création du mot clé 'foreach', 'yield' avec tout ce que cela implique pour le compilateur... alors qu'une solution universelle existe !?

Après, si vous me trouver pas d'avantage fondamental, je fais pareil avec async-await

Je viens de faire un test rapide en .NET 6, foreach semble deux fois plus rapide sur une liste de 250 objets vides

En .Net Core 3.1, le résultat est différent avec avantage pour l'utilisation de la méthode .ForEach() (qui est stable d'un framework à l'autre) :

EDIT : ces tests fait à l'arrache n'ont probablement que très peu de valeur

La grosse différence c'est que tu as dans le cas 2 une méthode, avec ce que ça implique :
- Factorisation / déport de la logique possibles
- Mais optimisation impossible de la boucle via le compilateur (inlining etc.), du moins pas à ce niveau

D'un point de vue technique, .ForEach() ne s'applique que sur des List. Donc déjà ça part mal pour la cohérence du code (et sans parler du fait que du coup foreach est une instruction nécessaire, puisque c'est ta première interrogation ).

D'un point de vue lisibilité et approche par d'autres devs, la seconde version est nettement moins facile d'approche, que ce soit en mots-clés (foreach/break/continue sont quasi-universels dans tous les langages, alors que LoopState.Merdier non) ou en bruit (les parenthèses, flèches de lambda, point-virgule, etc...).

Bref, perso dès que je vois du .ForEach() je le remplace par une instruction foreach.

  AMHA pas autant d'effort d'optimisation on était fait sur le second cas car peu utilisé.
 

T'aurais un exemple concret d'optimisation qui serait impossible dans le second cas    

Où est-ce nécessaire dans

C'est pas comme si je l'avais dit    Sauf qu'il faut voir un peu plus loin.
 
En retenant cette approche, on peut imaginer l'ajout de sucre syntaxise et la possibilité de définir un retour par défaut. L'appel de ma méthode pourrait ressembler à ça :  

On pourrait donc faire du "aussi propre" avec beaucoup moins de mots-clés et un compilateur moins complexe.
 
Par exemple l'invention du bien intelligemment tordu "out Type Nom"  (AMHA le "out" devrait mérité la peine de mort )

Serait avantageusement remplacé par

... et même faire des choses qui demanderait de nouveaux mots clés.

Mon point était que foreach est nécessaire dans la mesure où .ForEach ne marche que sur les List

Tu n'as parlé que du bruit ; je parle de lisibilité en général et  

Non mais ce que tu cites n'existe pas en C# (avec des si...) et je trouve le | encore plus illisible Enfin après t'as le droit de vouloir ça, mais la conversation dévie du sujet initial.
Pour en revenir à foreach, c'est quoi "beaucoup moins de mots-clés" ? Y en a 3, foreach, continue et break, avec les 2 derniers qui ne s'appliquent pas qu'à foreach mais aux boucles en général et qui sont connus dans la plupart des langages de prog. Pourquoi introduire de la complexité là où il n'y en a pas besoin ?

Pas de cas concret, je donne juste du théorique sur la compilation, en pratique je ne sais pas comment le JIT décide de ses optimisations. C'est par contre connu que l'inlining de méthode n'est en général pas implicite, il faut passer par des indicateurs pour éviter des problèmes de perfs voire des bugs (fonctions récursives !). Et le benchmark au dessus semble confirmer que le compilateur fait du meilleur boulot sur les boucles classiques (avec probablement d'autres optimisations que l'inlining, je n'ai cité que la plus connue).

C'est le but de ma conversation !

Mon sujet : est-ce qu'une autre implémentation aurait été plus simple et universelle que le foreach usuel ?

Donc je suis en plein dans mon sujet.  

Y a aussi "yield return" et "yield break" Sinon j'ai donné l'exemple du "out Type VarName" qui deviendrait aussi inutile. Sans parler des nouvelles versions et implémentations nécessaires pour coupler foreach avec les awaits et même des exceptions

Donc justement, je ne n'introduis pas de la complexité, j'en enlève énormément point de vue implémentation de cas particuliers.

La complexité que tu me reproches est seulement dans l'approche "différente" et "moins standard". C'est le but de ma conversation : réinventer une autre roue ! Mais elle ne serait pas forcement plus complexe à utiliser pour qui en connait son utilisation.

Mais pourquoi donc souhaiter une autre roue !? (voila la question )

Car celle-ci me semble permettre d'avoir directement les outils pour faire du foreach, exception ou await sans l'implémenter spécifiquement dans le compilateur et donc d'être aussi directement utilisable pour des choses qui demanderaient une implémentation future en approche standard.

M'sieurs dames, question rapide
 
Quand on développe une application web avec .NET (ici du MVC 5 en .NET Framework 4.8, mais osef, ça s'applique à toute la plateforme), on est sensé gérer les requêtes HEAD des clients séparément des GET c'est bien ça ?
 
J'ai lu que le HEAD était un moyen rapide pour les robots (proxys, moteurs de recherche, réseaux sociaux ...) de s'assurer qu'un serveur est bien dispo à l'adresse donnée, sans devoir récupérer tout le body, en ne téléchargeant donc que le header de la réponse.
 
Du coup, si, dans mon appli MVC je ne réponds qu'aux GET (décoration [HttpGet] sur mes actions), ça veut dire qu'en cas de HEAD, je retourne une erreur ?
Dois-je donc prévoir pour chacune de mes actions, son homologue "HttpHead" (si ça existe), dans laquelle je return rien, pour satisfaire les robots ?
Ou existe-t'il un moyen de factoriser ça (route MVC basée sur un verbe HTTP plutôt qu'une URL ?) ?
 
Merci à vous

Ça a l'air de correspondre à ta question : https://stackoverflow.com/questions [...] sp-net-mvc

Merci, c'est pile poil en effet.
Comme j'ai décoré HttpGet mes actions, ça exclue les POST (voulu) mais du coup les HEAD aussi, c'est pour ça que je stacke comme un porc
 
Bref, merci

 
Pour revenir là-dessus, je me suis demandé si c'était moi qui était juste un peu réfractaire au changement ou si vraiment ça donne un truc confus, apparemment vu les réactions sur le sujet :  
https://github.com/dotnet/docs/issues/27420
Je ne suis clairement pas le seul à trouver ça affreux

Ouais enfin là c'est un gros thread de rageux, honnêtement je pige pas l'intérêt sachant que l'ancien modèle est toujours supporté et n'a pas de décommissionnement prévu.
 
Je comprends qu'on trouve ça moche ou quoi, perso je trouve ça plus lisible et moins verbeux, mais je pige qu'on n'aime pas. Maintenant le thread que tu linkes est ridicule. Suffit de voir, y a 1 mec qui dit "ah perso je trouve ça pas mal" sans attaque ni rien et pan, 36 downvotes.