Où Console.WriteLine va-t-il dans ASP.NET?

Question

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

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

Je suis ne demande pas si je devrais me connecter ici (j'utilise log4net), mais où va la sortie? Mes meilleures informations proviennent de ce discussion où ils disent Console.SetOut() peut changer le TextWriter, mais il n'a toujours pas répondu à la question sur ce que la valeur initiale de la console est, ou comment le configurer dans config/en dehors du code d'exécution.

Answer 1

Si vous regardez la classe, vous trouverez dans Console.NET Reflector, que si un processus n'a pas une console associée, Console.Out et Console.Error sont soutenus par Stream.Null (enveloppé dans un TextWriter), qui est une mise en œuvre fictive de Stream qui ignore fondamentalement toutes les entrées et ne donne aucune sortie.

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

En outre, en dehors de l'appel SetOut, il est impossible de configurer la valeur par défaut.

Answer 2

Dans une application ASP.NET, je pense qu'elle va à la fenêtre Sortie ou Console qui est visible pendant le débogage.

Answer 3

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

Answer 4

Il n'y a simplement pas d'écoute de console par défaut. En mode de débogage, il y a une console connectée, mais dans un environnement de production c'est comme vous le pensiez, le message ne va nulle part parce que rien n'écoute.

Answer 5

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.

Answer 6

J'ai trouvé cette question en essayant de changer la sortie Log du DataContext dans la fenêtre de sortie. Donc, à quelqu'un d'autre d'essayer de faire la même chose, ce que je l'ai fait était de créer 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; } 
    } 
} 

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

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

Answer 7

L'objet TraceContext dans ASP.NET écrit à l'DefaultTraceListener qui sort au processus d'accueil standard output. Plutôt que d'utiliser Console.Write(), si vous utilisez Trace.Write, la sortie ira à la sortie standard du processus.

Vous pouvez utiliser l'objet System.Diagnostics.Process pour obtenir l'ASP.Processus NET pour votre site et surveillez la sortie standard à l'aide de l'événement OutputDataRecieved.

Answer 8

System.Diagnostics.Debug.WriteLine(...); obtient dans la fenêtre immédiate dans Visual   studio   2008.

Aller au menu Debug ->de Windows ->immédiate:

Answer 9

Si vous utilisez IIS Express et lancez-le via une invite de commande, il laissera la fenêtre DOS ouverte, et vous verrez Console.Write déclarations là.

Ainsi, par exemple obtenir une fenêtre de commande ouverte 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 à C: \ Projects \ Website1. Il va démarrer IIS Express et servir les pages dans votre répertoire de site Web. Cela laissera les fenêtres de commande ouvertes, et vous verrez des informations de sortie là. Disons que vous avez un fichier là, default.aspx, avec ce code en elle:

<%@ 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> 

Arrangez vos fenêtres de navigateur et de commande de sorte que vous pouvez les voir à la fois sur l'écran. Maintenant, tapez dans votre navigateur: http://localhost:1655/. Vous verrez Hello! 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 fait simple en ayant le code dans un bloc de code dans le balisage, mais toutes les déclarations de la console dans votre code-behind ou partout ailleurs dans votre code montrera ici aussi.

Answer 10

Si vous regardez dans la fenêtre de débogage, vous verrez console.writelines.

Answer 11

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

Pour l'instant, vous pouvez simplement ajouter loggerFactory.AddDebug (LogLevel.Debug); dans votre section Configure et il vous montrera au moins vos logs dans la fenêtre Debug Output.

bonnes nouvelles CORE 2.0 tout cela sera en train de changer: https://github.com/aspnet/Announcements/issues/255