Le modèle de message doit être constant de temps de compilation

Ceci est une caractéristique du Serilog, non? L'utilisez-vous ou ont-ils introduit la journalisation structurée dans .NET 5? Il pourrait être bon de clarifier en tout cas.

---

Yamaç Kurtuluş, j'utilise nlog , du moins pour le moment. Je suppose que l'équipe IntelliJ conserve une liste de cadres soutenant une journalisation structurée quelque part pour savoir quand activer cet avertissement (ou peut-être qu'ils ont un algorithme plus sophistiqué - il doit y avoir un Lot d'effort et de code derrière Beaucoup d'avertissements que leurs outils génèrent).

---

Pour moi, la solution (que les créateurs de Rider / MS / C # proposent?) N'a pas de sens, il peut induire le code induit en erreur puisque les arguments nommés sont juste des arguments commandés - aucune correspondance de nom, donc le code logger.logdebug ("hey { Foo}, hi {bar} ", bar, foo); loga hey bar, hi foo , encore plus de variables de renommée bar et foo fera du code étrange ... ("hey {foo}, hi {bar}", big, bang); - Rider / Resharper ne prend pas en charge la renommée dans {} également atm .

---

@svonidze L'utilisation de {} dans la chaîne peut simplement être considérée comme la même que ce que vous utiliseriez pour string.format () . Vous pouvez ajouter des variables nommées pour le rendre plus facile à lire, mais vous pouvez tout aussi bien faire logger.logdebug ("hey {0}, hi {1}", bar, foo) - serons les mêmes. Gardez cela à l'esprit, cela pourrait vous aider.

---

@NewteqDeveloper Il est clair, c'est ce que je voulais dire sous "Les arguments nommés sont juste des arguments ordonnés - pas de correspondance de nom", il ne remplace pas la beauté et la clarté de l'interpolation des cordes

---

Oh oui, je comprends. Je suis d'accord avec vous - il ne remplace pas la clarté que l'interpolation de chaîne fait, cependant, comme le répondant mentionné, il aide une tonne avec la journalisation structurée. Si vous n'allez jamais écrire des journaux au format de chaîne dans un fichier texte, je dirais que vous pouvez complètement ignorer cet avertissement. Après tout, c'est juste un avertissement. Mais, pour permettre la journalisation structurée, cela aidera à réparer l'avertissement comme mentionné.

---

@svonidze C'est absolument critique, si vous êtes un développeur de bibliothèque, que vous n'ignorez pas cet avertissement, car vous inonderas les systèmes de journalisation en aval avec des messages qui ne peuvent pas être correctement élidés ou compressés. La question de savoir si elle est "plus propre" n'est pas pertinente dans ce cas, car les modèles non constants sont erronés lors de l'utilisation d'un cadre de journalisation structuré.

---

Cela fonctionne-t-il avec quelque chose comme logger.logInformation ("L'état du serveur est {server.state}.", Server.state); ? J'espère que c'est le cas, parce que j'ai changé beaucoup de lignes comme celle-ci;) Le compilateur ne se plaint pas, je me demande si les chaînes seront interpolées correctement dans le journal.

---

@Ekw "éludé" ??

---

@tharenediad Merriam-webster.com/dictionary/elide

---

@Harry J'essaierais d'éviter la ponctuation des variables (et des messages, vraiment). Aucune garantie que l'objectif du journal prendra en charge cela. Si vous utilisez SEQ, je ne sais pas si ce n'est pas étayé, mais vous finiriez probablement par vous retrouver avec une requête comme SELECT * dans le flux où server.state = 'foo' et 'server.state' = 'bar'

---

J'avais un journal comme celui-ci _logger.logInformation ($ "Traitement des notifications pour le client {client.ChompanyName} et user {user.userid}"); mais tout en débogue Notifications pour le client {client.companyName} et user {user.userid} . Cela ne se souciait pas de remplacer les valeurs correctes.

---