Reprise du message précédent :
OK super merci les gars.
Je vais jeter un œil à la config de mes routes  

Je dois avoir les sources de mon programme en .Net 6 qui mixait les deux, je pourrai t'envoyer le contenu du startup.cs si tu galères à faire marcher l'ensemble. Mais je suis sûr à 99% qu'il y a des tutos sur internet genre "Mix MVC Core and Swagger service in same project" tellement ça me parait basique comme demande.

Tiens je viens d'avoir un souci rigolo : un update mineur de Visual Studio qui m'a foiré un projet.
Au build il ne trouvait plus certaines dépendances, genre IHttpClientFactory.
Pourtant ça vient du framework (Microsoft.Extensions.Http v7) et le package est bien référencé dans nuget.
En creusant et en le forçant à refaire la référence (pourtant sensée être bonne), je vois que c'est passé de :  

A

 
Sans doute que l'update de VS a mis à jour le SDK de .Net 7 en même temps, avec ce petit changement de chemin.
 
En local c'est déjà surprenant de plus rien avoir qui fonctionne juste en relançant VS, donc sur un serveur de build qui n'est même pas forcément au même niveau d'update que les postes locaux ça peut vite être le bordel. Du coup je partage cette petite expérience dont je me dis que dans un environnement plus complexe elle aurait pu me faire perdre pas mal de temps.

BON, note à moi-même : .NET Framework 4.8.1 n'est pas disponible sous Windows Server 2019... j'aurai du me renseigner avant d'envoyer mon dernier update

L'installe manuelle est pas possible ?
J'ai galéré pour installer du 4.6 sur windows 10.
En decompresant le contenus du framework directement dans le répertoire qui va bien, ça fonctionne. Obligé de le dl sur Gît il me semble

Oui ça m'avait fait tiquer aussi quand c'est sorti, heureusement je l'ai vu à temps
https://forum.hardware.fr/forum2.ph [...] 0#t2438693

Le unpack manuel sur de la production c'est un peu dégueu, surtout si l'upgrade de version n'était pas justifié

Vous bossez sur des trucs sympas en ce moment ?

Moi j'ai pas repris de client depuis quelques temps, mais il y a quelques mois je m'étais mis à Blazor pour un projet perso. J'avais posté sur le moment pour voir si des gens font du Blazor ( https://forum.hardware.fr/forum2.ph [...] 7#t2440477 ).
Je suis tombé accroc aux composants Radzen, c'est aussi riche et puissant que du Telerik et complètement gratos . En plus ça se customise bien.
C'est pile ce qui me fallait (j'avais besoin de grilles évoluées, de graphiques...) et c'est incomparablement supérieur aux libs JS libres que j'avais essayé.

J'ai fais une formation blazor en septembre/octobre, mais n'étant pas un fan du dev web et pas à l'aise pour l'instant avec les injections de dépendance , j'y ai vu peu d'intérêt.
Et dans mon service on est plutôt winform/service.

Ça dépend de ce qu'on appelle "sympa"
Je me fais vraiment plaisir sur tout le côté "interaction avec le métier", donc des discussions pour comprendre le besoin, des tests, du DDD, beaucoup de com et de transparence. Ça marche à fond.
0 technique en revanche, 0 framework, on fait essentiellement des API REST avec du SQL et des connexions à d'autres API (donc HttpClient & co). Le tout en .Net 6/7, sous Azure.
 
Après j'ai pas mal bossé récemment sur l'aspect perfs de nos API, et j'ai appris pas mal de trucs en bossant avec Application Insights d'Azure : sampling (notamment pour creuser la pile d'appels de dépendances d'une requête par exemple), cas à la marge, requêtes Kusto pour choper des infos, recommandations Azure sur le code et sur le SQL, etc... c'est très bien foutu , des outils clairs et intuitifs soit pour analyser en profondeur, soit pour donner des débuts de pistes d'amélioration.

J'aime la technique mais le côté "échange humains" tant que les utilisateurs sont de bonne foi et agréables c'est top aussi !
Par contre Azure les outils de profiling/diagnostiques m'avaient bien gonflé quand j'ai voulu me mettre dedans (lenteurs, problèmes incompréhensibles genre requêtes jouées deux fois, logs introuvables bien qu'activés...), mais ça fait déjà >2 ans donc ça a dû progresser .
 
 
-
J'ai une question "Best practices" niveau super-noob
Mettons un projet C# en .Net 5 ou plus, avec <Nullable>enable</Nullable> dans le .csproj.
Du coup si je fais une classe avec des types non nullable, genre  
 

VS va râler parce que je n'initialise pas Chaine dans mon constructeur.  
Mais je peux quand même avoir l'intention de le faire quand même dès la construction de l'objet avec un initialiseur de classes (bcp plus clair à mon goût qu'un constructeur dès qu'on a plusieurs membres !).
 
Pour corriger le warning je peux  
- Désactiver le warning (non )
- Mettre Chaine en Nullable, sauf que à l'usage je sais que "fonctionnellement" elle n'est pas sensée l'être donc c'est idiot.
- Ajouter un = null!; sur la propriété, ce qui n'empêche pas le "null check" de se faire ailleurs si je tente de lui coller un null depuis l'extérieur. C'est habituellement ce que je fais, mais c'est assez moche quand on fini par en avoir un peu partout.
 
Au final j'ai jamais trouvé de compromis propre pour ça alors que ça semble être absolument trivial. Il me semble que MS avait parlé d'améliorer ça dans une version récente (7 ? 8 ?) du framework.
 
Vous avez un avis ?

 
Je vire systématiquement le  <Nullable>enable</Nullable>
 
systématiquement...

visual studio part un peu en couille sur la dernière version c'est très agaçant

en debug il s'arrête sur un throw, jusque là ok, sauf qu'ensuite il reste bloqué dessus... f5 le fait juste re-highlight la même ligne qui throw, sans fin

c'est très casse couille quand je veux justement fix mon traitement de l'exception...

je redémarre VS et ça remarche une demi heure avant de recommencer

Déjà je ferais un record et je dégagerais les setters publics
 
Ensuite ba pose-toi la question en prenant du recul : est-il normal que la chaîne soit nulle parfois ? Si oui, ajoute un ?. Sinon :
1. Rends-la obligatoire (mets-la dans le constructeur, auquel cas, fais un record ²).
2. Initialise-la à string.Empty si tant est qu'une chaîne vide ne soit pas une valeur particulière pour ton appli. Principe du Null Object pattern, que j'affectionne particulièrement.
 
Je mets nullable enable au niveau du projet (j'ai même passé les warnings en tant qu'erreurs sur une solution), je trouve ça parfait, ça permet de faire un code cohérent, pas/moins défensif et de se poser les bonnes questions en amont (= avant que ça pète en prod).

Euh... Pourquoi ? C'est sûr que mettre ça sur du code ancien c'est bon à être inondé de warnings, mais sur du code pensé pour ça fait une bonne barrière contre les nullreferenceexceptions et autres trucs du genre.

On est d'accord sur l'utilité du nullable à enable

Pour les setters publics, évidemment c'est mieux sans (j'ai zappé ça pour mon exemple), mais ça n'enlèvera pas le warning qui m'intéressait dans ma question

Ma classe est une classe parce que c'est pas un record

Pour le String.Empty c'est un peu arbitraire, et ça marchotte à peu près pour une chaîne, mais pas pour un autre type non nullable.

En fait je pense que j'aurais voulu un truc du genre "ce champ n'est pas nullable. Mais il n'est pas forcément initialisé dans le constructeur, ne gueule pas tant qu'il l'est par un initialiseur de classe [ce qui revient au même, à la syntaxe près]", mais c'est juste pas supporté, ou pas encore

J'ai fait chier avec les records mais stait pas le but du post ; le but stait les Null Objects, qui de mon point de vue répondent à ton besoin.
 
String.Empty est un exemple de Null Object pattern directement intégré au framework ; si t'as un type Youpi à toi à la place d'une string, tu peux faire un type NullYoupi qui dérive de Youpi et qui fait juste rien. Dans ton constructeur tu initialises ta propery à NullYoupi et, quand t'as besoin de l'utiliser, au lieu de faire if(Truc.Youpi != null), tu fais if(Truc.Youpi is NullYoupi) et basta. Et ta classe Truc n'a pas besoin de caler un ? après le type de la property.
 

 
L'avantage c'est que ça pète pas en NullRef et que en plus, comme tu t'es posé la question avant, tu peux le nommer mieux en fonction de ton contexte métier. Genre YoupiWhenThereIsNoPrice ou UnavailableYoupi et autres joyeusetés. Donc c'est combo null-proof et code lisible, que demande le peuple
 
Dans ton exemple, si string.Empty te semble arbitraire, pose-toi la question de l'utilité de passer par un type primitif et du code smell "primitive obsession" : as-tu vraiment besoin d'une string ? Ou peux-tu faire un wrapper autour, un type qui serait plus parlant, plus adapté et plus contraignant ? Comme dit un copain, dans une string l'intégrale de Shakespeare en mandarin est une valeur tout à fait correcte mais peut-être pas pour ton use case. Si on prend un exemple de code IBAN, on peut tout à fait le mettre dans une string mais c'est pas ouf (imagine du mandarin dedans ). Peut-être qu'il serait plus adapté de faire un type IbanCode, qui contiendrait une string en privé mais qui aurait un constructeur qui ferait de la validation pour empêcher les conneries. Dans ton cas c'est peut-être ça aussi.
 
Les nullables c'est bien, ça permet de dérouler plein de pelotes de questions auxquelles on pense pas toujours quand on met un bête string avec nullable en disable

Clairement je ne me vois pas revenir en arrière sur les nullable : ça explicite le contrat, évite des bugs...

Perso j'alterne entre string.Empty (cas général) et null! pour les cas qui ne peuvent pas être null, genre les classes d'API qui se retrouvent par construction [required]. Dans la prochaine version de c# ça deviendra d'ailleurs probablement inutile grâce au mot clef required.

Dites, je cherche une piste.
 
J'exécute un appel a une API qui fait un appel http. Parfois, l'appel HTTP ne répond pas et bloque toute exécution.
C'est un appel HTTP, mais ca pourrait être tout autre "travail" derrière, genre fabriquer un fichier Zip.
Je cherche à exécuter mon appel, et lui laisser un temps définit (5 secondes par exemple), temps au bout duquel soit ca a aboutis et je continue, soit je considère que ca ne répondra pas et je mets ma tache en erreur..
J'aimerai, en cas de timeout forcer l'arrêt de l'appel pour éviter une surcharge en mémoire vu que c'est un service windows.
 
Pour mes tests, j'utilise la génération d'un zip, mais je n'arrive pas a "stopper" le travail de cette tache.  
J'ai essayer avec une task et un canceltoken, un backgroundworker avec cancelasync, mais impossible.
 
en c# et .Net 4.6.1

Pour tous les trucs du genre "si ça foire déclenche ça à la place" ou "si ça foire recommence x secondes plus tard, et y secondes plus tard si ça foire encore" ou "si ça foire on arrête tout et on bombarde la russie" il faut absolument que tu rencontres Polly : https://github.com/App-vNext/Polly

Par contre dans le cas spécifique de ton appel, si tu as un truc zombie qui continue de tourner quelque part parce que l'appel est déjà parti, là on peut pas faire de miracle, c'est une histoire de protocole et d'implémentation. Les CancellationToken et cie faut bien que ça soit géré quelque part.

Tu parles de http et de service windows en même temps, ça me parait pas forcément coller ensemble. Surtout que le http de base, c'est pas top pour gérer le flux aussi finement.

Yes !!! Polly ! j'hésitais à le conseiller car je ne savais pas s'il était dispo en .NET 4.6.1 et.. coup de bol, c'est le plus vieux FW qu'il supporte

Ah j'avoue j'avais même pas pensé à aller vérifier ce détail, pour moi le 4.6.1 il est au musée à côté des os de dinosaures

Et on recommence avec le passage à la 17.6.3 (7.0.7 au lieu de 7.0.5 maintenant)

Ca va être pratique si ça le fait à chaque MAJ de VS...

J'ai fait l'expérience de remplacer toute la référence par un
<PackageReference Include="Microsoft.Extensions.Http" Version="7.0.0" />
Et ça a l'air de marcher au build, au run, et pour nuget
Ca n'explique pas pourquoi la réf générée par nuget est aussi stricte mais bon, on va tenter comme ça.

C'est un service windows, qui fait des appels a une api via http.
Par moment, l'API ne renvoi rien (soit elle a fait son job et ne renvoi rien, soit elle foire et ne renvoie rien non plus, il faut qu'on fouille la dedans aussi) et le service "fonctionne" mais ne fait rien.
Utiliser une task ou un backgroundworker permet juste de tourner en asynchrone et de continuer si ça merde.
Ce qui me gène c'est que je vais avoir potentiellement un paquet de task fantôme, avec les soucis que ça peut générer niveau mémoire.

A voir ce quon peut faire coté Api, je sais pas qui en a la charge.

Je vais regarder Polly, merci.

Une fois n'est pas coutume, j'ai un petit problème... WPF
 
Un client me demande d'implémenter un copier/coller (enfin.. juste un "copier ) à partir de mon application, cela porte sur un usercontrol qui contient une grid pour le positionnement, et des group box contenant Label/TextBlock...
 
Le but est de pouvoir selectionner à la souris les couples label/textblock, puis click droit -> copier (ou ctrl-c), comme s'il s'agissait d'un contenu web quoi
 
Et... j'ai fais le tour de google, je trouve rien... Si quelqu'un a une idée ? (autre que le petit bouton à rajouter qui ferait un write dans le clipboard de mes infos MVVM hein, car pour l'instant, c'est le seul truc que j'ai en stock...)

Et moi j'ai une question Blazor .
Et elle doit être niveau super débutant .

Depuis une page Razor classique, comment on génère un lien vers une page Blazor ?

J'ai une directive

en haut de ma page Blazor, elle répond bien à son url https://localhost:44351/mapage (donc elle est routée), mais si j'essaie depuis un contexte Razor de générer vers elle un lien de la forme

il me génère un lien tout moche avec le nom de la page passé en GET en paramètre à la page actuelle ( https://localhost:44351/laoujesuis?page=%2mapage ), parce qu'il ne la connaît pas depuis Razor j'imagine.

La même syntaxe pour faire un lien vers une page Razor fonctionne (naturellement).

Je sais que Razor et Blazor s'exécutent dans des pipelines un peu différents, mais j'imagine qu'il y a un truc tout con pour générer des liens de l'un vers l'autre

Merci

Hello,  
 
Autre petite question, depuis .Net Core comme on le sait tous on peut facilement cibler à la compilation plusieurs versions de framework donné pour un projet.
 
C'est assez simple à faire (dans le .csproj mettre TargetFrameworks au pluriel, utiliser des <ItemGroup Condition="..." pour bidouiller ses packages, dans le code utiliser des directives de préprocesseur si besoin... Bref).  
Mais depuis le début ça se fait entièrement à la main (éditer le .csproj) et donc c'est fastidieux.
 
Je suis surpris qu'au fil des années il n'y ait pas un truc plus visuel.  
Genre pouvoir ajouter une cible de compilation, gérer les packages par cible tout en vérifiant leur compatibilité, etc. Avec une interface, au lieu de se palucher du XML (même si le format SDK des csproj est carrément plus lisible que l'ancien).
 
Y a une extension (officielle ou pas) ou une fonction cachée dans le gestionnaire nuget par exemple qui m'a échappé pour ce genre de choses ?
 
Merci

Pas que je sache. Vu que c'est la norme de "coder" la partie build dans les autres frameworks, et qu'ils ont comme tu as dit simplifié le csproj en édition, pas sûr qu'un effort soit fait de ce côté.

C'est bien encore et toujours manuel, mais perso ça ne me pose pas de soucis. Il est important de faire ses lib en .NET Standard pour ne pas avoir à se poser de questions. Tout ce qui ne peut être en .NET Standard doit avoir sa propre lib qui gèrera une compilation multi-framework
 
Perso, ce fut extrêmement rare d'avoir eu besoin d'utiliser les Condition, autre sur sur des lib exotiques mal foutus

Ok, merci d'avoir confirmé que je perds pas mon temps à faire ça à la main .
 
Bah moi ça m'arrive d'avoir besoin des conditions, genre pour une vieille librairie qui contient des petits bouts de WCF dispo juste dans ServiceModel 4 (et pas dans les versions 6 et cie), mais dont 95% était migrable (mais bon, c'est un cas marginal).
 
J'étais passé par du .Net Standard à un moment donné mais les restrictions m'ont gonflé, puis j'aime faire mumuse avec les features récentes du langage
Aujourd'hui c'est un peu mourant quand même, pour les versions récentes autant cibler ce qu'on veut et profiter du support maximal (.Net 7 dans mon cas), sachant que si je ne me goure pas .Net Standard 2.1 s'arrête à .Net Core 3.1 et qu'il n'y aura de toute façon pas de nouvelle version.  
 
Et pour les vieilles versions, le Standard 2.0 était un peu limité (me rappelle plus les restrictions que j'avais eu avec mais je me souviens que dans mon cas c'était pas viable, probablement que j'avais des contrôles Windows dans les projets concernés aussi ou ce genre de choses).  
 
 
Au final dans mon cas je m'en sors avec un mix d'assemblies en .Net 4.7.2 (que je dois garder pour de vieux projets MVC impossibles et sans pertinence à migrer), et du .Net 6 ou 7, notamment pour tout ce qui est Winform.  
Pour certaines des assemblies en 4.7.2 j'ai mis une cible en .Net 7 en plus, mais c'est pas indispensable vu qu'on peut référencer du 4.7.2 dans du .Net 6 ou 7, et les adaptations à faire se sont avérées modestes. Tant que je n'essaye pas de lancer ça ailleurs que sous Windows évidemment

Perso j'ai laissé tomber .net standard aussi. Je multicible .net 7 en plus de 4.7.2 pour les très legacy, ça me paraît plus future proof, notamment ça permet de gérer les nullable dans les contrats.

coucou, vous conseillez quoi comme alternative à postman ?

en gros je cherche juste... postman, mais sans leur mise à jour débile qui va tout foutre en remote et plus rien en local.

je pensais que ça serait une recherche courte mais je tombe soit sur des trucs douteux, soit des trucs payants, soit des trucs webapp.

d'avance merci

Ah bah ça, c'est de la coïncidence
J'ai justement récemment ouvert la discussion dans la catégorie : https://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
 
Il en ressort quelques noms qui pourraient t'aider dans ta recherche

 
merci

J'ai utilisé un temps Insomnia, qui était vraiment pas mal, (lors du passage de Postman 1.xx à 2.xx), puis je suis repassé à PostMan.... Mais pour les mêmes raisons que toi je vais probablement repasser sur Insomnia

Plop,  
 
Je redonne vie au topic, c'est Noël
 
Plus haut on parlait de Nullable et d'initialisation "forcée", finalement j'ai adopté la plupart du temps le mot clé required qui correspond bien à la plupart des cas sans forcer à initialiser avec des valeurs sans aucun sens ni polluer le code ou forcer à shunter des warnings. C'est un excellent compromis. Evidemment faut être en C# 11.
 
Pour le client webservice, chez mon client actuel on est partis sur Kreya, c'est limité (pour le moment) au gRPC et REST et il y a quelques petits bugs ou manque (la partie "tests automatisés" notamment), mais c'est beaucoup moins cher qu'un postman par exemple (50$ la licence pro complète, 25 lors du black friday ).
 
A part ça quoi de neuf chez vous ?
 
Joyeuses fêtes à tou(te)s  

Si pour toi les nullables c'est forcer à initialiser avec des valeurs sans aucun sens ou polluer le code ou shunter des warnings, c'est qu'il une incompréhension quelque part sur le but du truc je pense C'est surtout pour bien se poser la question au moment du build si une variable peut avoir une valeur ou pas et, si pas, est-ce qu'on gère bien le cas null dans le reste du code. C'est tout. Si on propage un null sur 7-8 couches de code et que les warnings font chier, ba je me dis qu'il vaut mieux le savoir au moment du build qu'au runtime avec une NullRef en prod Et donc agir en conséquence avant le drame. Typiquement, utiliser un null object pattern peut éviter la propagation et donc les warnings à la con et le code défensif à outrance.
 
Pour moi les nullables, c'est le truc à activer sur chaque nouveau projet (perso je mets carrément les warnings en erreur). C'est clairement difficile sur un projet legacy (mais pas impossible non plus) donc je comprends que ça soit pas activé mais faut le voir comme une sécurité en plus, pas une contrainte idiote.
 
"required" je suis pas fan car perso j'initialise toujours mes champs indispensables via le constructeur. Sinon ça veut dire que tu colles une property en required pour quelque chose qui n'est pas demandé dans le constructeur, je trouve ça pas ouf.

Le "null!" initialisé dans les properties est bien du code inutile juste pour éviter les warnings. C'est bien pour ça qu'ils ont rajouté le mot clef required, c'est contre productif sinon.

Pour l'initialisation dans le constructeur, ça n'est pas une solution : perso au delà de 3 properties je vire le constructeur si j'en avais mis un, ça devient illisible comparé à une initialisation avec les properties explicites. Sonar est un peu moins extrémiste que moi, il limite par défaut à 7 paramètres pour le constructeur / méthodes. Si pour la prochaine version MS pouvait faire évoluer les records sur ce point là d'ailleurs, ça serait pas mal : je ne les utilise pas à cause de ça...

On doit pas bosser pareil alors, c'est pas grave

Pour détailler : un constructeur avec beaucoup de paramètres n'est un sujet que si t'es sur un bon gros POCO, mais perso je vois pas le souci à passer par un constructeur plutôt qu'un initialiseur, tu peux aller à la ligne entre chaque param et utiliser des parenthèses au lieu des accolades (et en plus tu évites le "Property = " devant, ou alors si ça te manque tu peux utiliser les params nommés).
En fait, le problème sous-jacent de la construction d'objet en initialisant les properties c'est que tu vas avoir des properties settables (à moins d'utiliser le scope init, auquel cas je vois vraiment pas la valeur ajoutée par rapport à un constructeur), et donc des objets mutables et donc des effets de bord.

Les records prémunissent de ça en étant des value objects donc non mutables (sauf bidouille) et super simples à comparer. Et la syntaxe avec with permet aussi de jouer avec facilement.

EDIT : quant au null!, je ne l'utilise quasiment jamais, je crois que j'ai dû l'utiliser 1 ou 2 fois en 2 ans.

Si tu ne vois pas le souci des méthodes et constructeurs (et méthodes )avec des milliers de paramètres, sonar le voit bien . Risque multiplié qu'un boulet inverse 2 paramètres, car il ne les aura pas nommés.

Init suffit largement pour l'immutabilité.

Attention grosse erreur par contre : les records sont des reference type, à moins d'utiliser des record struct. Les records ne changent globalement rien par rapport à une classe / struct, à part le sucre syntaxique du constructeur qui fait des properties {get; init} en une ligne.

Je ne dis pas que je ne vois pas de souci des signatures avec plein de paramètres, c'est généralement un code smell, je suis d'accord Ceci étant, utiliser des setters pour des properties pour éviter d'avoir trop de params dans le constructeur est un contournement très discutable à mon sens (cf ce qui suit).

Oui init suffit mais dans ce cas tu te retrouves à écrire
var machin = new MyMachin
{
  A = a,
  B = b,
  ...
}
au lieu de var machin = new MyMachin(a, b...)
Pas sûr qu'on gagne quelque part.

Pour les records, je parle de value object au sens DDD, pas de value type Voir https://en.wikipedia.org/wiki/Value_object et https://martinfowler.com/bliki/ValueObject.html
En gros, l'idée est de dire que 2 objets sont égaux parce qu'ils ont les mêmes propriétés, sans forcément avoir la même référence. Ex :
var p1 = new Price(12, "EUR" );
var p2 = new Price(12, "EUR" );
Si Price est un value object comme un record, tu auras p1 == p2. Pas besoin de struct. Avec une classe, tu auras p1 != p2 parce que les refs seront différentes.

C'est un confort énorme je trouve, t'as pas à te farcir les overrides de Equals, de GetHashCode, de créer un Comparator custom... sans même parler de l'immutabilité qui garantit l'absence d'effets de bord. Et l'utilisation du mot-clé with permet en outre de s'affranchir de la "chiantitude" de recopier manuellement un record dans un autre, ex : var p3 = p2 with { Amount = 15 } et en avant Guingamp.
Le sucre syntaxique de la création auto des properties est un gain appréciable mais mineur par rapport à ce que je considère comme le véritable apport des records : immutabilité et comparaison d'objets "gratuite".

Et moi je crois qu'avant d'écrire ce genre de phrase sacrément condescendante tu devrais au moins t'assurer d'avoir bien compris de quoi il était question, par exemple en relisant la discussion mentionnée, pour éviter les incompréhensions quelque part

Prenons un exemple :
Une classe qui sert de DTO pour un WS (donc comme ça on évacue direct les setters privés et le constructeur à 15 paramètres ), projet en <nullable>true</nullable>, mix de champs nullables et pas nullables donc compilo qui gueule.

Quelques options :
- dire ta gueule au compilo avec un #pragma jesaispascombien ()
- tout mettre en nullable (non, pas si ça n'a pas de sens, si un truc est obligatoire ça doit se voir)
- utiliser = null!; (généralement ce que je faisais avant)
- faire un constructeur sans paramètre avec plein de valeurs par défaut genre string.Empty, 0, Guid.Empty, etc (les valeurs sans aucun sens dont je parlais et qui t'ont fait réagir), ou mettre ces valeurs par défaut sur les propriétés elles même, ce qui revient exactement au même.
Pour moi aucune de ces solutions n'est satisfaisante.

... Reste par contre en .Net 7 la possibilité de juste ajouter "required" à ces champs, ce qui au lieu d'avertir au moment de la définition de la classe fait en sorte qu'à la place tu le sois lors de son instanciation si tu oublies une propriété. Ce qui me parait beaucoup plus propre et censé que tous les cas précédents.

Je donne l'exemple du DTO mais ça marche aussi ailleurs évidemment.

record (ou struct) pour moi c'est pas le débat. C'est aussi super utile mais pas si c'est juste pour contourner des comportements du langage intentionnels sur les classes.
Et les méthodes (ou constructeur) à plus de 5 paramètres j'évite également quand je veux faire du propre et lisible.

C'est vrai c'était pas cool et pas nécessaire, mea culpa, je te présente mes excuses.

Je pige pas le "donc" ici ? En gros t'as des champs non nullables et, comme ils sont pas initialisés ça râle ?

Je comprends mieux le problème Tout est question de contexte je pense. Si on est sur un DTO, par exemple utilisé pour de la désérialisation en sortie d'un WS/requête HTTP avec payload JSON/SQL, en quoi c'est "mal" un constructeur ? La désérialisation va l'utiliser, tout le monde sera content.
Je suis d'accord avec les autres remarques.
En fait, si t'es sur un DTO que tu ne construis pas et que c'est le framework/une lib qui fait ce job, toi ce qui va t'intéresser c'est de lire les propriétés pour faire du mapping ou je sais pas quoi derrière, donc que ce soit un constructeur ou une property, c'est pas très grave.
Si t'es sur un DTO que tu construis, je trouve important que le constructeur définisse ce qui est nécessaire et ce qui ne l'est pas, soit avec des params optionnels, soit en ne mettant que les params nécessaires et en settant les properties optionnelles au besoin. C'est le job du constructeur, quoi. J'en reviens à "pourquoi le constructeur c'est mal ?" parce que pour moi les props settables c'est impliquer de la mutabilité à un objet (et de mon point de vue c'est pas ouf) et que je vois pas en quoi initialiser un objet avec des propriétés est mieux ou plus lisible ou plus propre

Pour un petit refresh de première pages, retrouvé sur mon linkedin :
 

 
et pour la postérité :
 
https://www.lemondeinformatique.fr/ [...] 92501.html