Reprise du message précédent :
Pour un petit refresh de première pages, retrouvé sur mon linkedin :
 
https://media.licdn.com/dms/image/D [...] Tb4zsNvLuc  
 
et pour la postérité :
 
https://www.lemondeinformatique.fr/ [...] 92501.html
 

mapster c'est mieux que automapper ? je deteste ce truc de tout mon coeur

 
pas encore testé mapster, mais je connais automapper et je m'en méfie comme de la peste... à choisir, je préfère le mapping à la mano pour l'instant

J'ai testé un peu. Mapster est ultra rapide, car utilise les generators. Par contre un peu moins souple, on avait eu des soucis de mapping sur des cas tordus (conversion avec du managed code). Dans des cas simples ça fera sans doute mieux le taf et plus rapidement je pense.

Ca ira pour cette fois
 

Ben oui, ce qui est normal, mais chiant
 

Mais pourquoi je voudrais générer un constructeur inutile (vu que moi je l'appellerai pas), moche (plein de paramètres), qu'il faut maintenir (si modification des champs), et dont je suis pas sûr que mon deserialiseur le trouvera alors qu'avec les propriétés publiques y a aucune surprise et aucun code inutile ?
Pour un DTO les setters publics ne me dérangent pas, et je maintiens que je trouve l'usage de required plus élégant que le forçage des valeurs sur les non nullables ou bien la muiltiplication des ctors. Et vu que le truc est récent et n'avait pas été mentionné il y a quelques mois ça me paraissait important d'y revenir.
Pour un objet dont je veux protéger l'état interne là effectivement je ne veux pas de setters (ou à la limite en internal), et là c'est bien d'avoir un constructeur (avec surcharges et arguments optionnels éventuellement). Bref je crois qu'on a fait le tour du sujet...

C'est très bien de mettre en avant des concepts et des pratiques, mais là c'est un peu trop dirigiste niveau librairies, ça sent le prosélytisme

Pour Automapper, j'aime pas non plus. Chez mon client actuel y a quelques mois j'ai tenté de pousser des trucs que je juge plus transparents, comme Mapperly qui fonctionne par génération de code et qui offre pas mal de customisation.
Avantages :
- Absolument rien ne se fait par reflection ou autres mécanismes obscurs et lents au runtime, tout le code est généré et compilé.
- Du coup c'est 100% debugable, pas comme Automapper qui fonctionne en mode boîte noire.
Je sais bien qu'il y a un certain nombre de mécanismes tout à fait efficaces dans Automapper pour s'assurer qu'aucun mapping n'a été oublié en route, mais sur des scénarios un peu complexes je préfère quand même avoir plus de maitrise.
Mapperly est un projet assez récent par contre, il ne fait pas (encore) tout ce qu'offrent les solutions de mapping un peu plus matures.

edit : et j'ai pas compris pourquoi le 2e lien ?

Bin au lieu d'avoir un constructeur inutile, t'as des setters publics inutiles (vu que toi tu ne les appeleras pas non plus) ? Dans tous les cas y a un truc "moche" (selon les points de vue) : soit un constructeur avec plein de params, soit des propriétés avec des setters publics (et des mots-clés required là où y a besoin).
Dans le cas du constructeur, t'as pas besoin de forcer une valeur puisque par définition ta property non nullable sera initialisée par lui.

Pour moi, on en revient aux records qui sont à mon avis la meilleure solution pour les DTO. Le seul problème est effectivement la signature à rallonge mais face aux gains multiples dont on a déjà parlé plus haut et le fait que l'alternative c'est une classe avec un ctor par défaut + des props settables, ba à choisir je préfère nettement le premier.

En gros, mon utilisation depuis quelque temps : DTO/POCO => record, besoin de logique et de méthodes "non triviales" => class.
Maintenant oui c'est mon choix perso et on parle simplement de points de vue.

'Tain la lourdeur    

Écoute j'essaie d'échanger sur le sujet hein, autant je comprends que le ton de mon premier message n'était pas terrible, autant discuter de l'intérêt d'une classe avec properties settables vs un record ou une class avec un constructeur un peu long ba ça me paraît dans les clous du topic Accessoirement ça fait aussi partie de notre job.

Discuter oui, rabâcher non. Le tour a été fait 2/3 fois, avec les mêmes arguments, sans succès visiblement. Il est temps de passer à autre chose   .

Surtout en période DotNet 8, qui apporte des bonnes idées / rattrapages sur la concurrence : spread operator et initialisation de tableaux notamment

Bonjour par ici
 
J'ai une question un peu semi HS on va dire, mais bon peut être qu'il y a des solutions plus appropriées au .NET que d'autres, sait-on jamais...
 
Pour la plupart des mes développements .NET (web ou appli) j'utilise le même presta d'envoi de mails techniques (mails d'inscription, mails d'erreurs/logs, mails ponctuels quoi, pas de démarchage, mailing etc...) : MailJet.
C'est pas forcément un choix impartial, c'est juste une habitude que j'ai prise depuis ~10 ans, et j'aime bien bosser avec eux, c'est simple (clé API, mode relai vs mode API etc...)
 
Problème : le service s'est un peu dégradé avec le temps, j'ai une limitation sur mon compte mais le service technique ne sait pas me dire pourquoi, ni comment la lever, donc j'ai parfois des délais dans mes envois, c'est frustrant.
 
Vous avez une préférence vous de votre côté ?
Facile à exploiter en .NET (pas forcément en mode API, mais avec un wrapper ou un objet simple du SDK on va dire), qui ait bonne réputation (pour pas finir en spam chez mes clients ...) ?
 
Merci à vous

Azure communication services ?
Sendgrid ?

Mon client actuel utilise https://www.brevo.com/fr/ . Peu / pas de blocage chez les clients, API simple ou SMTP au choix

Merci beaucoup.
Pour le moment, je suis sincèrement trop petit pour me permettre un Azure ou un MS365 pro, mais je vais regarder pour les 2 autres

Trop petit pour un azure ?
- Ca coûte pas grand chose : calcul sur https://azure.microsoft.com/fr-fr/pricing/calculator/ tu prends communication services, tu es à < 3.50 € /mois pour 10k mails de 1Mo
- Tu paies à l'usage
- L'API est simple, l'admin aussi
 
Curieux de voir quel point te bloque, habituellement / de mon XP c'est plus les gros qui sont réticents au cloud (raisons politiques notamment)

Pourquoi trop petit ? Il y a pas besoin d'être gros pour ouvrir un compte, une simple CB suffit.
Je sais pas combien tu dois envoyer de mails mais c'est €0.00023/Email sent par ex

Ah bah j'avais une (mauvaise) idée conçue sur le sujet
Effectivement je m'en servais y a quelques années pour tout autre chose et les relais Microsoft sont faciles à utiliser (et configurer du coup !)

Je vais tester aussi  

Bon bah j'ai mis en place l'envoi via Azure
Effectivement, c'est très simple à faire et quasiment immédiat.
 
Les seules limitations que je rencontre dans mon application actuelle (ASP .NET MVC 5 / .NET Framework 4.8) :
- les courriers envoyés atterrissent en spam
- les courriers envoyés sont convertis en texte brut, la mise en forme HTML est ignorée
 
Pour le 1er point, je pense qu'il sera résolue de lui-même dans quelques heures, le temps que mes entrées SPF/DKIM/DKIM2 chez OVH soient prise en compte par les DNS.
Le 2e point venait de l'interface chaise/clavier, j'avais remplacé mes templates par des versions light en texte brut
 
Par contre l'envoi est un peu long du coup, l'envoi via EmailSendOperation.Send() est bloquant et bien plus long que celui via le bon vieux SmtpClient.Send().  
Il faut que je vois pour basculer sur la version asynchrone EmailSendOperation.SendAsync(), ou alors je vais devoir déléguer l'envoi des mails à un autre programme

Top !

L'envoi via async ne fera probablement pas aller plus vite par contre, c'est juste le thread de iis qui sera libéré pour une autre requête.

Oui voilà, le délai d'envoi ne me gêne pas trop, c'est plus le blocage du thread principal qui m'embête.
 
On peut jouer sur un paramètre de EmailSendOperation.Send(), dans lequel on peut lui demander de rendre la main soit dès que la commande est partie, soit une fois qu'Azure confirme avoir envoyé le message (et on peut aussi scruter le status de l'envoi pour jouer avec un event), mais même en le mettant au moins safe possible, ça prend toujours quelques centaines de ms.
 
--> Ca ira très bien pour mon humble usage, mais je me vois pas implémenter ça pour un envoi en batch par exemple ...

Pour les envois en batch (email, notif, sms), j'ai toujours délégué à un service dédié

Bonjour

Besoin d'un petit hint de la part d'un vétéran de l'ASP .NET MVC (.NET Framework) parmi vous
Depuis quelques jours, j'ai une quantité affolante (par rapport à mes habitudes on va dire) de stacks qui proviennent d'une appli web, mais la trace est très très inhabituelle.
Je n'avais jamais vu ce type d'exception jusque maintenant, et ça se produit chez plein d'utilisateurs, sur une URL précise, mais évidemment non reproductible en test...

Et c'est tout !
Je n'ai pas de référence à la ligne qui fait appel à CheckSuspiciousPhysicalPath(), et je ne sais pas ce qui a foiré.
Est-ce qu'il y a une erreur ou est-ce que c'est juste une info, j'en sais rien.
Ca a l'air de poper dans le global.asax, dans une des méthodes de navigation, mais comme je ne le reproduis pas en dev, je n'arrive pas à en être sûr.

Le fichier en question (passé en paramètre) existe, et n'est pas locké en lecture/écriture dans un autre processus.
L'erreur se produit chez plusieurs utilisateurs différents, j'ai bien des user agents et IP publiques différents et non suspects.

Ca semble faire suite à 2 dernières opérations effectuées sur cette application :
- migration .NET Framework 4.7.2 -> 4.8
- augmentation du nombre de requêtes permises par session (via le setting aspnet:RequestQueueLimitPerSession)

L'application est écrite en ASP .NET MVC 5 et tourne sur une machine Windows Server 2019, sous IIS.

Vous avez déjà vu une telle exception ?

C'est un path en dur ou en relatif ?

Normalement, la navigation sur cette appli se fait via des URL complètes, mais c'est vrai que quand ces erreurs arrivent, l'URL demandée est alors sous sa forme relative oui

Exemple ici sur une qui vient juste d'arriver :

EDIT : par contre c'est vrai que ça ne semble concerner qu'1 ou 2 fichiers, les URL demandées sont tout le temps les 2 mêmes.

https://referencesource.microsoft.c [...] til.cs,185
 
Apparemment il n'aime pas les `/` et préfère les `\\`

Merci !
 
Effectivement j'étais arrivé à cette conclusion aussi, mais comme ce n'est pas moi qui fais appel directement à cette méthode, je ne sais pas où intervenir pour manipuler le chemin d'accès
 
Peut être un appel fait automatiquement quand je fais un FileExists() ?
Je vais chercher de ce côté là.
 
Merci pour le tuyau en tout cas