Où va Console.WriteLine dans ASP.NET?

313

Dans une application J2EE (comme celle qui s'exécute dans WebSphere), lorsque j'utilise System.out.println(), mon texte passe à la sortie standard, qui est mappée à un fichier par la console d'administration WebSphere.

Dans une application ASP.NET (comme celle qui s'exécute dans IIS), où va la sortie de Console.WriteLine()? Le processus IIS doit avoir un stdin, stdout et stderr; mais stdout est-il mappé à la version Windows de / dev / null ou manque-t-il un concept clé ici?

Je ne demande pas si je dois me connecter là-bas (j'utilise log4net), mais où va la sortie? Ma meilleure information est venue de cette discussion où ils disent Console.SetOut()peut changer le TextWriter, mais cela n'a toujours pas répondu à la question sur la valeur initiale de la console, ou comment la définir dans config / en dehors du code d'exécution.

Kevin Hakanson
la source
Il irait en fait à la STDOUT du processus de travail ASP.NET. Là où cela est indiqué, je ne suis pas sûr.
FlySwat
2
Telle est la question - où va STDOUT?
Kevin Hakanson
35
apparemment, personne ne le sait, mais tout le monde l'utilise dans ses exemples. wtf
Jason
si vous cherchiez à des fins de débogage, je vous renvoie la réponse @Greg Bernhardt ci-dessous.
Ram
1
@KevinHakanson FWIW toutes ces années plus tard, la sortie standard de tout processus est choisie par son parent, le processus qui l'a démarré. Dans ce cas, le parent serait IIS. Cela pourrait vous orienter dans la bonne direction .
jpaugh

Réponses:

197

Si vous regardez la Consoleclasse dans .NET Reflector , vous constaterez que si un processus n'a pas de console associée Console.Outet qu'il Console.Errorest soutenu par Stream.Null(enveloppé à l'intérieur de a TextWriter), qui est une implémentation factice deStream qui ignore fondamentalement toutes les entrées, et ne donne aucune sortie.

Il est donc conceptuellement équivalent à /dev/null, mais la mise en œuvre est plus rationalisée: il n'y a pas d'E / S réelles ayant lieu avec le périphérique nul.

De plus, à part appeler SetOut, il n'y a aucun moyen de configurer la valeur par défaut.

Ruben
la source
18
Utilisez System.Diagnostics.Debug.WriteLine () si vous voulez réellement que quelque chose soit écrit dans la fenêtre de sortie, que vous pouvez afficher lors du débogage.
Ε Г И І И О
743

Si vous utilisez System.Diagnostics.Debug.WriteLine(...)au lieu de Console.WriteLine(), vous pouvez voir les résultats dans la fenêtre Sortie de Visual Studio.

Greg Bernhardt
la source
45
J'aurais posé la même question que Kevin, mais c'est la réponse que j'aurais cherché.
Zasz
11
Encore un petit indice; si vous imprimez une chaîne formatée, utilisez Debug.Print au lieu de Debug.WriteLine pour éviter un conflit d'arguments (voir social.msdn.microsoft.com/Forums/ar/Vsexpressvcs/thread/… ).
Nicholas Riley
12
Notez que le débogueur doit être attaché pour que les messages soient affichés dans la fenêtre Sortie.
Cosmin
4
Cela ne fonctionne-t-il pas pour IIS local ou quelque chose? Je n'arrive pas à pouvoir écrire sur la sortie pour la vie de moi, malgré le fait que je commence cela avec F5 (donc le débogueur est attaché). Je sais que mon code est en cours d'exécution car je peux écrire dans un fichier très bien.
Kat
@Cosmin À quel .exe exact dois-je m'attacher dans VS?
Grace
26

J'ai trouvé cette question en essayant de changer la sortie du journal du DataContext dans la fenêtre de sortie. Donc, pour quiconque essaie de faire de même, j'ai créé ceci:

class DebugTextWriter : System.IO.TextWriter {
   public override void Write(char[] buffer, int index, int count) {
       System.Diagnostics.Debug.Write(new String(buffer, index, count));
   }

   public override void Write(string value) {
       System.Diagnostics.Debug.Write(value);
   }

   public override Encoding Encoding {
       get { return System.Text.Encoding.Default; }
   }
}

Et après cela: dc.Log = new DebugTextWriter () et je peux voir toutes les requêtes dans la fenêtre de sortie (dc est le DataContext).

Jetez un œil à ceci pour plus d'informations: http://damieng.com/blog/2008/07/30/linq-to-sql-log-to-debug-window-file-memory-or-multiple-writers

Artur Carvalho
la source
Pourquoi ne pas simplement utiliser un wrapper statique, étant donné que vous encapsulez des méthodes entièrement statiques? Pourquoi prendre la peine de s'étendre TextWriter?
Kat
1
Vous pouvez également utiliser dc.Log = s => Debug.WriteLine(s);.
Rudey
1
Application_Start: System.Console.SetOut (new DebugTextWriter ());
Stefan Steiger
Encore mieux, Console.SetOut (nouveau DebugTextWriter ());
Alde
18

Si vous utilisez IIS Express et que vous le lancez via une invite de commande, il laissera la fenêtre DOS ouverte et vous verrezConsole.Write instructions.

Ainsi, par exemple, ouvrez une fenêtre de commande et tapez:

"C:\Program Files (x86)\IIS Express\iisexpress" /path:C:\Projects\Website1 /port:1655

Cela suppose que vous disposez d'un répertoire de site Web dans C: \ Projects \ Website1. Il démarrera IIS Express et servira les pages de votre répertoire de site Web. Cela laissera les fenêtres de commande ouvertes et vous y verrez les informations de sortie. Disons que vous aviez un fichier, default.aspx, avec ce code dedans:

<%@ Page Language="C#" %>
<html>
<body>
    <form id="form1" runat="server">
    Hello!

    <% for(int i = 0; i < 6; i++) %>
       <% { Console.WriteLine(i.ToString()); }%>

    </form>
</body>
</html>

Organisez votre navigateur et vos fenêtres de commande pour pouvoir les voir tous les deux à l'écran. Maintenant , tapez dans votre navigateur: http://localhost:1655/. Vous verrez Bonjour! sur la page Web, mais dans la fenêtre de commande, vous verrez quelque chose comme

Request started: "GET" http://localhost:1655/
0
1
2
3
4
5
Request ended: http://localhost:1655/default.aspx with HTTP status 200.0

Je l'ai rendu simple en ayant le code dans un bloc de code dans le balisage, mais toutes les instructions de la console dans votre code-behind ou n'importe où ailleurs dans votre code s'afficheront également ici.

Chris
la source
+1 J'utilise toujours IIS Express lors du développement pour cette raison. La sortie de la console est inestimable, utilisée à l'arrière comme la console javascript à l'extrémité avant. Enregistre des tas de débogage de temps, par opposition à l'utilisation d'un journal de serveur basé sur des fichiers. Vous n'avez pas à remplacer la gestion des exceptions "conviviale" - conservez la belle page du navigateur "oups", et affichez simplement l'exception sur la console, facile à voir.
ingrédient_15939
9

System.Diagnostics.Debug.WriteLine(...);l'obtient dans la fenêtre immédiate de Visual Studio 2008.

Allez dans le menu Debug -> Windows -> Immediate :

Entrez la description de l'image ici

Nik
la source
Dans mon Visual Studio 2012, j'ai suivi ce que vous avez dit mais la chaîne est apparue dans le Outputjuste à côté du Immediate WindowMerci!
WTFZane
6

Il n'y a tout simplement pas de console qui écoute par défaut. En cours d'exécution en mode débogage, une console est attachée, mais dans un environnement de production, c'est comme vous le soupçonniez, le message ne va nulle part parce que rien n'écoute.

Craig Tyler
la source
5

À moins que vous ne soyez dans une application console stricte, je ne l'utiliserais pas, car vous ne pouvez pas vraiment la voir. J'utiliserais Trace.WriteLine () pour les informations de type débogage qui peuvent être activées et désactivées en production.

Charles Graham
la source
Oui, voici un bon point de départ: msdn.microsoft.com/en-us/library/x5952w0c.aspx
Zhaph - Ben Duguid
3

L' TraceContextobjet dans ASP.NET écrit dans le DefaultTraceListenerqui sort dans la sortie standard du processus hôte . Plutôt que d'utiliser Console.Write(), si vous utilisezTrace.Write , la sortie ira à la sortie standard du processus.

Vous pouvez utiliser l' System.Diagnostics.Processobjet pour obtenir le processus ASP.NET pour votre site et surveiller la sortie standard à l'aide de l' OutputDataRecievedévénement.

Brian Griffin
la source
1

s'il vous arrivait d'utiliser NLog dans votre projet ASP.net, vous pouvez ajouter une cible de débogueur :

<targets>
    <target name="debugger" xsi:type="Debugger"
            layout="${date:format=HH\:mm\:ss}|${pad:padding=5:inner=${level:uppercase=true}}|${message} "/>

et écrit des journaux sur cette cible pour les niveaux souhaités:

<rules>
    <logger name="*" minlevel="Trace" writeTo="debugger" />

vous avez maintenant la sortie de la console comme Jetty dans la fenêtre "Sortie" de VS, et assurez-vous que vous exécutez en mode débogage (F5).

Mickey
la source
0

C'est déroutant pour tout le monde quand il s'agit d'IISExpress. Il n'y a rien pour lire les messages de la console. Ainsi, par exemple, dans les applications ASPCORE MVC, il est configuré à l'aide de appsettings.json qui ne fait rien si vous utilisez IISExpress.

Pour l'instant, vous pouvez simplement ajouter loggerFactory.AddDebug (LogLevel.Debug); dans votre section Configurer et il vous montrera au moins vos journaux dans la fenêtre Sortie de débogage.

Bonne nouvelle CORE 2.0, tout cela va changer: https://github.com/aspnet/Announcements/issues/255

Chris Go
la source
0

Mac, en mode débogage, il y a un onglet pour la sortie. entrez la description de l'image ici

Thushara Buddhika
la source
-3

Dans une application ASP.NET, je pense que cela va dans la fenêtre Sortie ou Console qui est visible pendant le débogage.

Leon Tayson
la source