Le développement d'application type "Console" ne se fait plus de trop. On a plus tendance à développer des clients lourds WinForms classique voire WPF. Cependant, il est parfois nécessaire de disposer d'une sortie de ce que fait l'application en "live".

Vous me direz qu'il est possible de compiler l'application WinForm classique en un exe type console et d'utiliser un bon vieux Console.WriteLine pour tracer ce qui se passe. Mais tout développeur VB que je suis, j'aime bien le petit Application Framework de mon projet VB. Il n'est pas disponible en mode console. D'autre part, ce n'est pas très propre de livrer une application qui démarre avec une console noire. Il faut donc trouver une combine. Et c'est dans les API Windows que nous allons trouver une réponse.

En effet, Windows offre la possibilité d'attacher une console à une application 100% WinForm. Il faut pour cela passer par du P/Invoke, mais comme vous allez le voir, rien de bien compliqué.

Comme on passe par du P/Invoke, il faut déclarer la méthode de l'API Windows que nous allons utiliser :

Private Declare Function AllocConsole Lib "kernel32" () As Boolean

Ensuite, un simple appel à cette méthode va se charger de créer l'écran noir tant désiré et relier tous les flux de sortie de l'application vers elle.

If AllocConsole() Then
    Console.WriteLine("Console liée")
End If

Il faut cependant bien faire attention au moment où vous vous attachez à la console. En effet, la moindre sortie vers la console avant que celle-ci ne soit attaché à votre application provoquera le non affichage de la sortie. J'ai passé un bon moment à le comprendre et je cherche toujours à savoir comment récupérer l'affichage dans une telle situation. Si vous avez la solution, n'hésitez pas ;)

Et voici le résultat :

Il existe une autre méthode pour vous attacher les services d'une console pour débuger votre application WinForm, mais elle est un peu plus compliquée. Il faut passer par la fonction AttachConsole mais, dans ce cas, il vous faudra créer une instance de la console (ou utiliser la console dont vous vous servez pour lancer l'application) et passer le numéro de Process (PID) à la méthode pour qu'elle s'y attache. L'inconvénient ce cette méthode, c'est que vous devez vous occuper de la destruction de la console quand vous quittez l'application.

Pensez aussi à passer par une trace de type ConsoleTraceListener pour vous laisser libre d'activer la sortie ou non, et surtout de pouvoir switcher rapidement vers une autre destination de log des activités de vos applications via le fichier de configuration.

Dans les deux cas, il ne peut y avoir qu'une console attachée à une instance de l'application en question.

Maintenant, plus de raison de ne plus traquer les bugs de vos applis !