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

- Microsoft Regional Director 2.0 ! par Le blog de Patrick [MVP Office 365] le 02-23-2015, 22:10

- TechDays Paris 2015: Malware unchained par Blog Technique de Romelard Fabrice le 02-12-2015, 22:58

- TechDays Paris 2015: La transformation du SI avec le Cloud Microsoft, quel sera le rôle de la DSI demain, comment le Cloud MS accompagne cette transfo... par Blog Technique de Romelard Fabrice le 02-12-2015, 22:51

- TechDays Paris 2015: L’intranet social avec Office 365 et Yammer - quelles possibilités d’intégration ? par Blog Technique de Romelard Fabrice le 02-12-2015, 22:46

- TechDays Paris 2015: Plenière jour 3 - Vers une technologie invisible et une intelligence omniprésente ? par Blog Technique de Romelard Fabrice le 02-12-2015, 10:59

- TechDays Paris 2015: Geek is in da {new} House par Blog Technique de Romelard Fabrice le 02-12-2015, 01:13

- TechDays Paris 2015: Windows Server vNext - Virtualisation et Stockage par Blog Technique de Romelard Fabrice le 02-12-2015, 00:26

- TechDays Paris 2015: Quoi de neuf dans Windows 10 ? par Blog Technique de Romelard Fabrice le 02-11-2015, 23:37

- TechDays Paris 2015: Réussir sa migration vers Office 365 en formant les uilisateurs par Blog Technique de Romelard Fabrice le 02-11-2015, 14:32

- TechDays Paris 2015: Windows 10 et PowerShell 5.0 par Blog Technique de Romelard Fabrice le 02-11-2015, 13:10