Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

DebugView : voir les traces de son application sans debugger

Lorsque l'on debug une application, nous avons besoin d'informations sur le contenu des variables, l'endroit où le programme se situe etc ...

Généralement, on utilise un débuggeur que l'on attache à notre programme afin de visualiser ce genre d'informations. Dans certains cas, on ne peut pas attacher un debuggeur : application en production, debuggeur qui modifie le comportement de l'application, debuggeur beaucoup trop long à se lancer, etc ...

On peut alors écrire nos infos de debug dans un fichier ... Ce n'est pas très propre ! Il existe une solution beaucoup plus propre : utiliser Debug.Write / Trace.Write.

static void Main(string[] args) { Debug.WriteLine("Avec Debug"); Trace.WriteLine("Avec Trace"); }

Si vous avez un debuggeur attaché, alors vous retrouverez ces informations dans la console Output lors du debug.

image

Si vous n'avez pas de debugger attaché, vous pouvez configurer des listeners au niveau du fichier de config afin de récupérer ces messages et les renvoyer où vous le souhaitez. Vous pouvez également utiliser l'application DebugView de SysInternals

image

Comment cela fonctionne ?

DebugView affiche tous les messages envoyés à la méthode OutputDebugString de Kernel32.dll. Lorsque l'on fait un Debug.Write ou Trace.Write, le framework .net utilise en interne cette API.

Quelle différence entre Debug.Write et Trace.Write ? Quasiment aucune !

public sealed class Debug { [Conditional("DEBUG")] public static void Write(string message) {} } public sealed class Trace { [Conditional("TRACE")] public static void Write(string message) {} }

La seule différence se situe au niveau de l'attribut ConditionalAttribute, cet attribut permet de compiler les lignes utilisant ces méthodes seulement si le compiler possède les constantes requise.  

Dans notre cas, les appels à Debug.Write seront compilés seulement si la constante DEBUG est définie. Par défaut la constante DEBUG est définit lorsque l'on compile en mode "debug" et la constante TRACE est définit lorsque l'on compile en mode "debug" et "release".

On peut modifier ce comportement dans les propriétés du projet.

image

DebugView possède de nombreuses options, je n'ai pas testé toutes les fonctionnalités, la plupart sont orienté debug de code natif. Parmi les options interessantes pour un développeur .net, il y a la possibilité d'attraper les messages d'une application s'exécutant sur une machine distante.

Posted: samedi 6 décembre 2008 17:52 par cyril
Classé sous : , , ,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

Statyk7 a dit :

Pour plus de fléxibilité, l'utilisation d'un framework de logging apporte beaucoup de possibilités.

Pour ma part, j'utilise Log4Net (http://logging.apache.org/log4net/index.html), il est très facile de choisir où les logs/traces seront dirigés : Debug Console, Fichier, Email, SQL...

Et pour visualiser les messages de façon plus conviviales, j'utilise Log2Console (www.codeplex.com/log2console), un outils que j'ai réalisé. Il est aussi possible de visualiser les messages sur une machine en remote (cela utilise .NET Remoting).

Mais dans tous les cas, c'est une bonne pratique d'avoir des logs/traces quand on développe, aussi utile en Debug qu'en Release. Alors même l'utilisation de DebugView est une très bonne chose !

# décembre 7, 2008 18:38
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- [ #Yammer ] From Mailbox to Yammer and back / De votre messagerie vers Yammer et retour ! par Le blog de Patrick [MVP SharePoint] le 09-15-2014, 11:31

- [ #Office 365 ] New service settings panel / Nouveau panneau de paramétrage des services par Le blog de Patrick [MVP SharePoint] le 09-11-2014, 08:50

- Problème de déploiement pour une démo SharePoint/TFS? par Blog de Jérémy Jeanson le 09-10-2014, 21:52

- [ #Office365 ] Delve first impressions / Premières impressions sur Delve par Le blog de Patrick [MVP SharePoint] le 09-09-2014, 16:57

- [ #Office365 ] How to change Administration console language ? / Comment changer la langue de la console d’administration ? par Le blog de Patrick [MVP SharePoint] le 09-09-2014, 08:25

- [ #SharePoint 2013 ] Suppression de bases de données en état “Pas de Réponse” par Le blog de Patrick [MVP SharePoint] le 09-04-2014, 14:10

- Changer l’adresse d’une ferme Office Web Apps associée à SharePoint par Blog de Jérémy Jeanson le 09-01-2014, 22:21

- Une ferme #SharePoint 2013 dans @Azure en quelques clics (1ère partie) ! par Le blog de Patrick [MVP SharePoint] le 08-28-2014, 18:52

- SharePoint 2013: Préparation de la migration - Création des site Templates dans 2010 et 2013 par Blog Technique de Romelard Fabrice le 08-20-2014, 16:31

- [ #Yammer ] How to change interface language ? Comment changer la langue de l’interface ? par Le blog de Patrick [MVP SharePoint] le 08-20-2014, 14:21