8
votes

.NET: Comment supprimer Tracesource Header ("Sourcename Traceeeventtype: ID:")?

J'ai un objet tracesource que j'utilise pour enregistrer l'initialisation d'une application VB.NET. Il a plusieurs tracelistes attachés:

  • consoleTraCelistener li>
  • TextwriterTraCelistener Li>
  • EventLogTraCelistener Li> ul>

    Pour les deux premiers, je souhaite que la sortie d'entrée soit "RAW" - c'est-à-dire sans i> l'en-tête standard: p>

    Sourcename TRACEEVENTTTYPE: ID: code> p>

    J'ai implémenté une enveloppe qui le fait que cela lorsque le traceeventtType est défini sur Verbose: P>

    For Each listener As TraceListener In _traceSource.Listeners
        If listener.GetType Is GetType(ConsoleTraceListener) OrElse listener.GetType Is GetType(TextWriterTraceListener) Then
            listener.Write(_buffer.Text)
        Else
            listener.TraceEvent(Nothing, _traceSource.Name, _buffer.EventType, id, _buffer.Text)
        End If
    Next
    
    • écrire () li>
    • Writeeline () Li>
    • tracedata () li>
    • TRACEEVENT () LI>
    • TRACETRANSFER () LI> ul>

      Les 3 derniers permettent de fournir un tracenteventtType (qui étiquette correctement les entrées EventLog, mais la sortie résultante de la console et le fichier journal inclut ensuite les préfixes et finit comme ceci (par exemple): p>

      bootstrapper Avertissement: 0: Échec de la validation de l'assemblage CODE> P>

      est un moyen de remplacer la manière dont la consoleTraCelistenerer et le TextWrrartRacelistener formatent leur sortie pour ne pas inclure cet en-tête, tandis qu'à Le même temps pouvant étiqueter les entrées avec un tracenteventtype (pour l'événement)? P>

      C'est le meilleur que j'ai monté jusqu'à présent: P>

      If _buffer.EventType = TraceEventType.Verbose Then
          For Each listener As TraceListener In _traceSource.Listeners
              listener.Write(_buffer.Text)
          Next
      Else
          _traceSource.TraceEvent(_buffer.EventType, id, _buffer.Text)
      End If
      


0 commentaires

3 Réponses :


0
votes

Regardez sur le UKADC.Diagnostics Projet sur CodePlex. C'est un addon à System.Diagnostics qui vous permet de former votre sortie de journalisation / de traçage, mais vous souhaitez (semblable à ce que vous pouvez faire avec Log4Net et Nlog). Vous l'utilisez via la configuration, votre code ne prendra pas une dépendance directe sur la bibliothèque. La bibliothèque est livrée avec des objets configurables pour la mise en forme et les tracelistes personnalisés requis pour tirer parti du formatage. La bibliothèque vous permet également d'écrire votre propre formatage de "jetons" et de votre propre tracelistener.

Par exemple, vous pouvez configurer l'Ukadc.Diagnostics consoleTraCelistener pour utiliser une déclaration de formatage quelque chose comme ceci: P>

{DateTime} {Source} {EventType} {Message}


10 commentaires

Merci, je vais regarder (bien que je préfère ne pas utiliser les addons externes, pour une raison quelconque). Et maintenant j'ai aussi fait mon propre système de traçage où je peux faire des choses similaires. Ma classe fonctionne de la même manière à Tracesource, mais il a deux collections d'auditeur. Celui qui fonctionne de la manière standard, à l'aide de traceeevent () et l'autre utilise la fonction d'écriture «brute» (). Chaque message enregistré est poussé à tous les auditeurs des deux catégories (en fonction de certains drapeaux, etc.), vous pouvez donc ajouter les auditeurs qui nécessitent l'étiquetage EventType dans un, et ceux avec une mise en forme plaine / personnalisée de l'autre. Fonctionne bien.


Je pense que la bibliothèque est vraiment cool, alors allez-y et essayez-la, vous pourriez aimer cela. Une façon, votre flux de travail pourrait aider votre flux de travail, mais vous pouvez utiliser le même ensemble de classes de tracelistener, mais changer ce qui est réellement écrit via la configuration. Ainsi, vous pourriez avoir un format "brut" associé à certains auditeurs (console et textwriter) et un format "événement" associé aux autres (EventLog). Si vous décidez la semaine prochaine ou le mois suivant que vous souhaitez ajouter ou supprimer certaines informations du format, vous devez simplement modifier le format dans l'app.config. Aucun changement de code. Bonne chance!


D7samurai, connaissez-vous le notinventedhere-antipattern?


@ M.Stramm - Non, je n'étais pas. Mais il y a une différence entre cela et ayant des exigences non remplies par les fonctionnalités existantes, sans vouloir dépendances de code externes, gâcher l'orchitecture interne esthétique, etc. Je pense que j'ai une légère tendance OCD en matière de codage, et je réécris habituellement mon Code propre - à partir de zéro - plusieurs fois pendant le développement, pour garder tout ce qui est "soigné", serré et cohérent. Je peux passer des heures à examiner simplement des noms de noms de variables / de nommage pour une application.


@ M.stramm - Notez également que le but de ce projet particulier était de fonctionner comme une bootstraps extrêmement brevetée (fonctionnant en tant que service Windows, maintenant / télécharger de manière dynamique les composants de l'application principale au démarrage).


@ D7Samurai Je l'obtiens, rappelez-vous simplement de ne pas tout réinventer. La peur d'utiliser des bibliothèques externes entrave vraiment le développement et détourne les ressources de l'endroit où elles sont nécessaires. Si les bibliothèques existantes ne peuvent pas fournir ce dont vous avez besoin ou sont trop instables, c'est une autre histoire, mais la journalisation n'est vraiment pas quelque chose que vous devez réinventer. Il a été fait plusieurs fois encore et encore encore


@ M.Stramm je n'essayais pas de réinventer la journalisation. Je voulais que ma journalisation enregistre mes données dans la façon dont je voulais. La question que j'ai posée était de savoir s'il existait un moyen de personnaliser la fonctionnalité de journalisation intégrée pour se connecter en fonction de mes préférences de formatage - c'est simplement la sortie des données du journal sous une manière propre sans données redondantes. C'était à propos de l'esthétique.


@ M.stramm Il n'y avait pas, apparemment, mais bien que des bibliothèques externes fournissent une fonctionnalité de la [personnalisation], ajoutant que BLOQUE et compliquer l'application - surtout Il y avait / sont des moyens de se déplacer (comme je l'ai expliqué). Est-ce une manière ou d'une autre une vertu d'utiliser des bibliothèques externes? Pour une efficacité de ressources pure, le chemin évident serait d'accepter simplement les données d'en-tête supplémentaires dans l'entrée de journal et de passer à autre chose. Mais comme je l'ai dit, j'aime bien que les choses soient propres et, dans ce cas, il s'agissait de savoir s'il y avait un moyen de personnaliser l'existant ou non.


@ D7Samurai Mon point est que cette réponse vous fournit exactement que: une bibliothèque qui vous permet (comme cent autres personnes) d'avoir votre journalisation pour enregistrer vos données comme vous le souhaitez. Oui, il existe une vertu dans des bibliothèques robustes testées de confiance sur vos propres solutions ad-hoc (mais ce n'est pas toujours le bon choix). Quoi qu'il en soit, pourquoi êtes-vous si désireux de défendre votre décision? C'est bon, je n'ai pas essayé de vous attaquer ou de le transformer en une longue discussion.


@ M.stramm. Je comprends ton point de vue. Pour une raison quelconque, vous avez impliqué que j'ai une peur irrationnelle des choses qui ne sont pas faites par moi-même - parce que je ne voulais pas utiliser une bibliothèque externe (pour faire quelque chose que je peux accomplir sans cela, dans une application que la philosophie de conception doit être aussi propre contenait et minimal que possible, même). Mon point, tel que formulé dans la question , était de savoir si la fonctionnalité de journalisation intégrée pourrait être personnalisée à mes préférences. Parfois, la raison que les gens ne veulent pas sortir sous la pluie ne sont pas qu'ils ont peur de se mouiller. Vous avez posé une question. J'explique comment c'est.



2
votes

Un autre projet similaire qui contient des auditeurs formables que vous pouvez utiliser est diagnostics essentiels , qui était en fait inspiré par Ukadc.diagnostiques.

Vous avez toutefois indiqué que vous ne voulez pas que vous ne voulez pas dépendances externes, mais vous avez encore plusieurs options sans ré-écriture des parties du cadre:

(a) Plutôt que de réécrire la traceource, le point d'extension conçu dans le cadre .NET est d'écrire votre propre tracelistener.

Si vous écrivez vos propres écouteurs de trace "ConsolewithoutPrefixListener" et "FileWithOtPrefixListener", vous pouvez remplacer les méthodes TraceeEvent () pour simplement transférer le message à TraceWrite () (et déposez les préfixes).

En fait, ni consoleTraCelistener ni textwratraticelistener ne sont scellés, je pense donc que vous pouvez hériter d'eux et obtenir cela fonctionne avec une indemnité de ligne d'une ligne de la méthode TRACEEVENT () (plus le constructeur).

(b) Une autre alternative serait de quitter EventLogTraCelistener configuré contre la source mais configurez les deux autres auditeurs sous (plutôt que la source de trace).

L'inconvénient de ceci est que, dans votre code, vous devez vous connecter deux fois à chaque fois, par exemple:

_Tracsource.TraceVevent (_buffer.eventtype, id, _buffer.text) Trace.Tracewrite (_buffer.text)

Si vous souhaitez écrire des messages avec des préfixes et certains sans que vous ayez besoin de deux sources de trace: une configurée avec les trois auditeurs et une avec seulement l'auditeur de journal d'événement.

Ensuite, dans votre emballage, écrivez soit à la source A (les trois) ou à la source B + Trace Méthodes statiques.

(c) Personnellement, mes conseils ne seraient de ne pas utiliser de traçage pour écrire dans le journal des événements - si des problèmes sont suffisamment importants pour écrire sur le journal des événements, vous ne voulez généralement pas que l'utilisateur puisse les éteindre via la configuration.

Dans ce cas, votre wrapper écrit directement sur le journal des événements (EventLog.writTentry ou quoi que ce soit), puis votre code écrit à la source de trace et / ou de trace des méthodes statiques pour le fichier et la console.

Notez que pour écrire un journal d'événement fonctionner correctement, vous devez prendre en compte les autorisations. Pour créer une source de journal des événements, vous devez être exécutant en tant qu'administrateur . En tant que développeur, vous avez probablement normalement des autorisations d'administration, vous devez donc tester correctement cela dans le contexte de quelqu'un qui ne le fait pas.

Notez également que ce n'est que la création initiale qui nécessite des autorisations d'administration, ce qui est automatiquement effectué lorsque vous écrivez le premier message, donc si vous l'avez déjà fait sous forme d'administrateur de développeur, vous devez trouver une machine propre à tester sur . omniprésente (ou quel que soit l'équivalent MSI ou autre), qui crée la source de journal des événements lors de l'installation (car l'installation est Fait par un administrateur). Ensuite, lorsque le programme exécute la source existe.

Alors, qu'est-ce que cela a à voir avec l'écriture à des traces - Eh bien, si la seule chose que vous faites est de configurer l'événementLogTacelistener dans votre config puis que des utilisateurs normaux ne fonctionneront pas; Il essaiera d'écrire des événements sur la source (dans l'attribut InitializedAta), qui essaiera ensuite de créer une source et si elle ne fonctionne pas comme administrateur échouera.

Si vous ajoutez un installateur pour la source d'événement, vous avez toujours un problème si une personne modifie le fichier de configuration.

Pour cette raison, je recommanderais que l'EventLoginstaller et EventLog soient créés directement dans le code, pour assurer la correspondance des noms et ne pas passer par l'infrastructure de traçage.


0 commentaires

1
votes

Voici ma solution complète à cela, inspirée par @ sly de la réponse de Sly .

Pour supprimer les informations d'en-tête lors de l'utilisation de la méthode TRACEEEvent () Code> Vous pouvez hériter de consoleTraCelistener code> ou ou ou TextwriterTracelisenerner code> (ou quelle que soit la saveur de l'auditeur requis) comme; p> xxx pré>

nb Lorsque vous essayez de remplacer la méthode EM> code> J'ai remarqué que les informations d'en-tête n'avaient pas été ajoutées à la chaîne de message à ce stade. Au lieu de cela, j'ai choisi de faire taire l'appel à em> écrire (string) code> qui ne semble pas avoir d'autres effets frappants, mais il se sente un peu "hackish", si Toute personne a une «approche plus propre» que je suis ouverte à elle. em> p>

La configuration à utiliser cet auditeur client doit alors regarder quelque chose comme ceci; P>

  <system.diagnostics>
    <sources>
      <source name="AppTrace" switchName="sourceSwitch" switchType="System.Diagnostics.SourceSwitch">
        <listeners>
          <add name="consoleListener"/>
        </listeners>
      </source>
    </sources>
    <switches>
      <add name="sourceSwitch" value="Information"/>
    </switches>
    <sharedListeners>
      <add name="consoleListener" type="Custom.Lib.ConsoleTraceListener, Custom.Lib" initializeData=""/>
    </sharedListeners>
  </system.diagnostics>


0 commentaires