Reprise du message précédent :
Par défaut (sans appel de la méthode), configureAwait est à true. Tu n'auras pas de grosses différences de perf en le passant à false, mais par contre tu t'exposes à des bugs, notamment en wpf et ASP.net. Il me semble que la reco c'est de ne pas y toucher dans les applis, seulement dans les DLL

J'avais compris que c'est "modérément utile et totalement sans risque" pour tout ce qui est API (conso de WS, etc).
Mais j'ai jamais vu de bench pour tenter de chiffrer le bénéfice qu'il y a à s'emmerder à le faire. Mais bon, à mon avis ça ne va pas super loin, surtout quand ça vient autour d'un appel de WS qui prend lui même 10ms...

Ca me fait penser : avec du code asynchrone, si vous développez en .Net Framework un service fortement sollicitée qui fait lui-même appel à un autre service, n'oubliez pas d'augmenter le nombre maximum de connexions simultanées à un même hôte qui par défaut est de 2 et peut créer un goulot d'étranglement

Dites,  
 
Presque à chaque fois que je déploie (ms webdeploy) une appli .Net 5.0 dans IIS, elle se vautre au démarrage, avec l'erreur 500.30 (ancm in-process start failure).
IIS : Site dédié à l'appli, pool avec tous les paramètres par défaut sans code managé.
Appli : MVC Core .Net 5, Release, Any CPU, rien de bien spécial dedans.
 
.Net 5.0.5 fraîchement installé (sans reboot, mais ça ne semble pas changer grand chose) via le "tout en un" dotnet-hosting-5.0.6-win Microsoft.  
 
Le remède le plus simple et efficace pour corriger ça c'est de passer le hostingModel de InProcess à OutOfProcess dans le web.config de l'appli.
Mais c'est pas très propre et ça oblige à une manip en plus.
 
Ca me le fait sur plusieurs applis et plusieurs serveurs, mais pas systématiquement, ça doit venir d'un truc dans l'install de IIS.
Le bundle "Hosting bundle" sur https://dotnet.microsoft.com/download/dotnet/5.0 est sensé faire tout (x86, x64, hosting bundle IIS) ou il lui manque un truc ?
 
Ca vient d'où ce machin ?
 
Merci

En .net core 3.1, déploiement par copie, c'est suffisant en tout cas (et je suis en inprocess). Tu peux tenter passer ton app en self-contained pour voir si ça débloque. Surtout que le gros avantage de dotnet 5 c'est justement le trimming (cf. https://blog.ndepend.com/net-5-0-ap [...] progress/)

"par copie" tu veux dire juste mettre les fichiers qui vont bien dans le répertoire IIS ?  
Ici ils aiment les lignes de commande et msdeploy c'est pratique.  
 
J'ai pas du tout cherché à jouer sur le trimming.  
Je publie en framework-dependant, pas en self-contained ("autonome" en français il me semble), ne serait-ce que pour garder une appli qui fait 5Mo et pas 80Mo.

 
Pas tout à fait, je fais un dotnet publish en mode répertoire puis copie via pwsh / ssh vers le serveur cible, ce qui marche très bien avec les CI/CD/Ansible/docker etc, alors que msdeploy :
- Est chiant à configurer sur les serveurs
- Demande des ouvertures de ports non standard
- Je ne sais même pas si c'est possible de l'exécuter depuis le conteneur docker du SDK dotnet
 

Il faut en effet compter sur un surplus de 50/60Mo en self-contained / trimmed. Mais c'est surtout pour voir si c'est un problème de hosting bundle. Sinon tu as la liste de checks habituels (pool non partagé, architecture du pool à x64), mais je suppose que tu as déjà vérifié.

C'est pas du deploy en remote, juste un .bat à exécuter directement sur la machine cible. Donc pas de problème de port et cie.
 
Le pool est celui créé "par défaut" lorsque tu ajoutes un nouveau site, avec juste "Aucun code managé" de changé. Rien changé d'autre dessus. Donc déjà x64 normalement et pas de partage.

 
J'ai déjà eu des 500 dans IIS sur du 3.1, le pb était dû à des sections du web.config dont l'apphost interdisait l'override (autour de l'upload, maxRequestLength etc..).

Il est tout vide mon web.config

C'est un bot ?

Non car il a déjà des messages au compteur sur d'autres sections. Mais vu que son message n'a ni queue ni tête, je l'ai viré

De ce,que j'ai regardé, ses autres messages ont majoritairement aucun sens à part 2 ou 3 topics, du copier-coller de définitions mal traduites
Mis merci pour le clean

De mon point de vue si tu utilises Dapper et pas Entity, c'est pour avoir le max de perfs. En partant de là avoir des méthodes semi-dupliquées n'est pas déconnant, tu auras plus de contrôle que si tu construis ta requête à la volée.
 
Pour l'archi, avec un bon Repository séparé et de l'IoC, ça reste largement propre et testable.

 
Déjà, avec une archi hexagonale (oui, j'aime la placer sous ce nom ):
 
https://github.com/HajiMirzaei/Clea [...] WithDapper
 
Dans cet exemple, avec la classe "générique" RepositoryBase, tu gères facilement tous les CRUDS (ici, de la manière dont c'est fait,ça implique que tes entités portent le nom de la table, ça pourrait être amélioré mais le concept est là). Ensuite pour chaque repository, là où tu as besoin de requetage spécifique, tu implémentes les méthodes qui vont bien (StudentRepository.cs, qui hérite de RepositoryBase, donc du CRUD mais qui expose également une méthode GetStudentWithRegisteredCourses qui fait appel à une proc stock, mais qui pourrait très bien être remplacé par une requete SQL perso avec jointure etc...)
 
Avec une base comme ça, tu part plutôt bien normalement
 
Ici, c'est pour du .NET Core, mais le concept reste valable en .NET Std
 

Salut à tous,
 
J'ai une problématique de sérialisation à vous exposer.
 
Là, j'ai un package NuGet qui contient tout un ensemble de modèles. La sérialisation des propriétés de ces modèles est décrite à l'aide de la lib Newtownsoft.Json. De plus, notre lib est intégrée à de nombreux projets et continue d'évoluer (quelques fois par an).
 
Dans le cadre de nouveaux projets, j'utilise exclusivement System.Text.Json. J'aimerai pouvoir réutiliser des modèles de notre package NuGet, mais je me retrouve bien évidemment avec des incohérences de sérialisation puisque les attributs de Newtownsoft.Json (principaleent JsonProperty et JsonIgnore) ne sont pas reconnus par System.Text.Json.
 
Quelle approches appliqueriez-vous ?

Si la séparation peut se faire sur la version de framework (genre tes nouveaux projets sont en net standard) je ferais du multi-target  de tes projets modèle avec donc compilation avec preprocesseur.

Dans le cas contraire j'aurais doublé les annotations.

C'était mon idée, mais vu qu'on a eu du portage de projets de .Net Framework vers .Net Core tout en gardant Newtownsoft, ce n'est pas possible.

C'est une idée aussi, facile à mettre en place. Par contre elle nécessite d'importer les deux libs dans les clients et ça, ça me dérange aussi
 
Il y a probablement la possibilité de faire une abstraction des serializers également, mais je ne suis pas certain d'avoir envie de me lancer là-dedans.
 
Pour répondre à mon problème là à très court terme, j'ai cloné la seule classe qui m'intéresse dans un NuGet "Common" propre aux 4 solutions de mon projet actuel, et mis à jour les attributs.
 
Autres solutions envisagées :
-> fork le projet NuGet "Cogip.Common.Models" en "Cogip.Common.Models.Newtownsoft" et "Cogip.Common.Models.SystemTextJson" (j'ai même envisager de tokeniser la lib, en faire un template pour assurer le maintient des deux branches)
-> faire une nouvelle version majeur de "Cogip.Common.Models" v3 (aujourd'hui on est en v2.x.y) qui sera une version System.Text.Json exclusivement, mais là je ne peux pas prendre cette décision en solo en l'abscence des deux autres lead-dev
 
Si vous avez d'autres idées, n'hésitez pas !

Il y en a parmi vous qui auraient une petite expérience des wiki open source en C# ?

J'en cherche un mais j'ai pas trop trouvé de contenu actuel, ça renvoie plutôt à de vieux projets plus maintenus (ex : https://github.com/roadkillwiki/roadkill ...), qui sont peut être très bien cela dit .

Mes souhaits :
- Supporte le markdown (avec images)
- Hébergement SQL Server / IIS / Windows Server 2008 R2, oui je sais c'est vieux et plus supporté .
- Gratuit

C'est pour faire une espèce de base documentaire, avec des snippets de code, etc.

Merci

Il y a une dizaine d'années, j'ai bossé chez un client pour lequel on a installé un "ScrewTurn Wiki"
C'était un site IIS, pluggé à une base SQL Server, et en dehors de ça c'était 100% gratuit.
Il me semble que c'était édité par Microsoft.
 
J'imagine que ça n'existe plus, que ça a été racheté / repris, mais voilà si ça peut te donner une piste.

 
ScrewTurn wiki !!! j'avais fais une adaptation pour le faire tourner sur Oracle chez Axa en 2010 (et une autre pour Sqlite pour une PME)

Merci ! Ca faisait parti des noms qui sont sortis quand j'ai regardé en vitesse, il est mort il y a genre 12 ans je crois .

 
Déjà quand on l'a implémenté, il me semble qu'il était question d'une reprise par Microsoft, pour passer sous une marque à eux (SharePoint ?)

Je vais donner sa chance à Roadkill je crois. Le projet est assez simple, j'ai fait joujou avec pendant 1h mais j'ai trouvé plein de bugs, si ça intéresse quelqu'un voilà ce que j'ai noté (les notes étaient pour moi à la base si je dois en comparer plusieurs ) :

Roadkill :
Avantages :
.Net 4.5, Razor
Installation très rapide, bdd simple

Inconvénients :
Projet inactif depuis plusieurs années
Pas de login même pour l'accès lecture seule : non, il y a une option "Public site" à décocher dans les paramètres
Pas de confirmation à la suppression d'une page et la suppression est définitive (y compris en bdd) !
Pas de menu / ToC du contenu ?
Nombreux bugs ?

Bugs :
- Les boutons de mise en forme de l'éditeur RTF font un POST de la page au lieu de générer la balise attendue
- Le plugin syntax highlighter ne semble pas fonctionner
- Les tags ne sont pas sauvegardés à la création ou l'édition d'une page
- Bug à la sauvegarde des paramètres ("The ViewData item that has the key 'DatabaseName' is of type 'System.String' but must be of type 'IEnumerable<SelectListItem>'" )

Pourtant j'ai juste fait un build / déploiement des dernières sources, je suis surpris de tant de bugs évidents sur un projet stabilisé depuis des années.

edit : ça concernait https://github.com/roadkillwiki/roadkill , pas https://github.com/roadkillwiki/roadkill_new qu'il faudrait que j'évalue aussi.

Bon, pour les bugs c'est le compilo TypeScript et la minification qui déliraient. Je me doutais bien qu'il y avait un truc.
Les paramètres TypeScript dans le .csproj ont bougé dans VS depuis la version utilisée à l'époque pour le projet, donc même si j'avais ce qu'il fallait sur le poste ça ne marchait pas. J'ai rafistolé ça approximativement (même si je ne comprend pas tous les machins que j'ai coché et que je ne sais pas pour quelle version le truc était fait à la base ).

Mais ça ne minifie pas par contre, il y a un gruntfile.js à la racine du projet, va falloir que je regarde comment ça marche. Tout ce que je connaissais c'est bundleconfig.json mais j'imagine que c'est la même chose en différent

Grunt... le builder js satanique... quelle horreur  

C'est mal grunt ?

De toute façon je vais juste voir pour rafistoler la minification, pas m'attarder dessus. En l'état Roadkill fait à peu près ce qu'il me faut, même si j'ai identifié quelques évols (pas chiantes) que je ferai probablement dessus dans quelques mois.

Y en a qui trouvent que .Net c'est compliqué, mais vu la multitude de frameworks et d'outils, je trouve que le dév web front c'est une foutue jungle
J'ai l'impression qu'il y a 50 trucs pour faire ce genre de choses, c'est un domaine qui ne m'intéresse pas du tout (en gros j'en suis encore à jQuery et bundleconfig, même si j'ai fait des incursions dans Vue).

Perso, je ne touche plus à aucune UI (en tant que dev), qu'elles soient web ou lourdes. Full "back" / data. J'ai mis un point d'honneur à convaincre tous mes clients (depuis 2012/2013 je pense) qu'ils gagneraient à séparer les dev front et back. On ne dialogue plus qu'avec des contrats que l'on design avant même de commencer les dev.
Après, je ne bosse que sur des architecture client-serveur (même avant quand j'étais chez un éditeur logiciel)
 
Le dev front - et plus particulièrement le dev web - est un métier à part entière ! Ne touchez pas à leurs front, ne les laissez pas toucher à vos back !

Je suis du même avis. Mais selon les boîtes et les projets c'est pas toujours facile

Perso j'étais clair sur mon refus de dev du front quand j'étais en SSII. Puis en CDI aussi. Maintenant je suis indep et reste clair sur mes intentions
Après, refuser une mission c'est pas la mort même si t'es débutant (sauf si t'es dans une zone a faible emploiement )

Vivement les architectures micro frontend  

Rigole, mais dans mon ancienne boite, c'était le cas
Chaque application était minimaliste et autonome. Les clients pouvaient souscrire "à la carte" à nos services qui dans ce cas pouvaient communiquer entre eux. Ils pouvaient aussi bien souscrire aux UI qu'aux services purement back (API Rest, bus de messages...)

Ah oui tout à fait, des sites comme Amazon ou Facebook fonctionnent comme ça. Ca permet à chaque équipe de bosser sur son propre front, et d'assembler tous les bouts ensemble à la fin

Hello,
J'aimerais vos avis sur un vieux débat :
Quel framework de log entre NLog et Serilog préférez vous ?

J'ai utilisé pendant des années NLog, et globalement j'en ai toujours été super content : configuration souple en XML ou JSON, toutes les fonctionnalités que je veux, grosse communauté et facilement extensible.

Là depuis 6 mois je suis chez un client qui a du Serilog sur tous ses projets, donc j'ai naturellement suivi la mode locale et essayé cette solution, mais depuis le début je passe mon temps à lui trouver des défauts :
- Configuration interminable dès qu'on a besoin de faire des trucs un peu complexes, syntaxe souvent tordue (obligé de passer par des trucs super alambiqués pour configurer un truc qui semble basique)
- Plein de packages à ajouter pour avoir chaque fonctionnalité (notamment dans la conf) : Expressions, Sinks.*, Enrichers.*, Formatting.*, Destructurama.*...
- Quasiment aucun contrôle sur les noms de fichiers générés (pas de variable ou de constantes, pas de gestion du format de date, etc). J'ai eu beau chercher, y a rien, il y a même des gens qui ont tenté de faire des PR (refusées) pour tenter d'améliorer le truc, ou alors il faut faire ses propres classes, on dirait que c'est comme ça depuis des années.
Par exemple j'aimerais bien générer des noms de fichier du genre "Logs/{applicationName}/log-{dateTime:ddMMyyyy}.log", ce genre de truc.
- Lorsqu'un message est sur plusieurs lignes (ex : un json), ça va émettre plusieurs entrées de logs distinctes sur la sortie (ça c'est super chiant pour Azure).

Evidemment le côté logging structuré (et toute les possibilités de configuration qui vont avec) est le gros point fort de Serilog, mais on retrouve maintenant la même chose (à peu près) dans NLog.

Si vous avez comparé les deux, pourquoi l'un plutôt que l'autre ?
Merci

J'avoue que j'ai énormément de mal à comprendre l'engouement pour Serilog dont j'avais pourtant entendu beaucoup de bien, donc je m'interroge.

Je suis passé de log4net à serilog en passant en .Net Core. Je n'ai jamais accroché NLog. Pour Serilog, c'est justement le choix de packages de petites taille que j'aime. Après son vrai plus était justement les logs structurées, mais aussi très facile à mettre en place. Je n'ai jamais eu trop de difficulté à faire mes propres extensions où en trouver déjà dispo.
 
Par contre j'ai toujours été très dubitatif de la nécessité, dans certaines boites, de faire des fichier de config de log compliqué. Après, ça fait 3 ans que je n'y ai pas touché car sur mes dernières missions, il y avait toujours des packages d'abstraction de logger afin de normaliser ce que l'on écrivait (avec centralisation dans CloudWatch, Splunk, Datadog)

"Je n'ai jamais accroché NLog." : pourquoi ?
 
Pour ce qui est des logs centralisés ou dont la conf est "distribuée" faudrait mettre ça en place, c'est sur la roadmap pour 2030, comme tous les trucs indispensables

C'est du JS grunt, ça suffit pour résumer tout le bien que j'en pense... (et accessoirement, en toute objectivité, c'est de la merde )

Bonjour, certains d'entres vous travaillent avec une certification LNE ou la marque NF 525 ?
 
Existe-il ou pourriez vous m'orienter vers des solutions existantes universelles ?
 
Ce serait pour réaliser un logiciel spécifique d'encaissements et de facturations sans qu'il est lui même besoin de certification.
 
Ce logiciel transmettrait en interne ces données converties à ce "module certifié de certifications".
 
L'idée est d'avoir un logiciel indépendant de la nature des données nécessaires au "module". Ce qui permet d'avoir la structure de données souhaitée dans le logiciel et même d'en changer si besoin. Pour l'utilisateur du logiciel ce module devrait rester invisible.  
 
Evidemment les solutions que je cherche doivent dans tous les cas respecter les exigences légales  
 
D'ailleurs pourriez vous aussi me conseiller un livre pour les nulles concernant la facturation ? J'aimerai vraiment comprendre toutes les subtilités avec exemples concrets, choses possibles (pourquoi?), choses impossibles (pourquoi?), changer de nom sur une facture (quelles conditions ?)
 
   
 

Connais pas, mais ca a l'air ennuyeux
Chez mon client actuel, ils ne sont déjà pas foutus de pondre un cahier des charges ou une spécification fonctionnelle, du coup la seule norme qu'on suit c'est   https://www.la-rache.com/

Y a pas des formations spécialisées ?
Bon courage

Je le conçois très bien
 
Sinon savez-vous où je pourrais poser ma question ? Car je fréquente seulement ce forum et celui de developpez.net.  
Et j'ai bien l'impression qu'ils n'ont pas su fédérer les nouvelles générations. Ils sont quasi morts pour des questions techniques.
 
Qu'est ce qu'utilise les jeunes informaticiens pour poser des questions  ?    

Certains utilisent Discord.