¿A dónde va Console.WriteLine en ASP.NET?

En una aplicación J2EE (como una que se ejecuta en WebSphere), cuando uso System.out.println() , mi texto va a la salida estándar, que está asignada a un archivo por la consola de administración de WebSphere.

En una aplicación ASP.NET (como una que se ejecuta en IIS), ¿dónde va la salida de Console.WriteLine() ? El proceso de IIS debe tener un stdin, stdout y stderr; pero está stdout mapeado a la versión de Windows de / dev / null o me falta un concepto clave aquí?

No estoy preguntando si debería iniciar sesión allí (uso log4net), pero ¿a dónde va la salida? Mi mejor información vino de esta discusión donde dicen que Console.SetOut() puede cambiar el TextWriter , pero aún no respondió la pregunta sobre cuál es el valor inicial de la consola, o cómo configurarlo en configuración / fuera del tiempo de ejecución código.

Si observa la clase de la Console en .NET Reflector , encontrará que si un proceso no tiene una consola asociada, Console.Out y Console.Error están respaldados por Stream.Null (envuelto dentro de un TextWriter ), que es una implementación ficticia de Stream que básicamente ignora todas las entradas y no da salida.

Por lo tanto, es conceptualmente equivalente a /dev/null , pero la implementación es más racional: no hay E / S real teniendo lugar con el dispositivo nulo.

Además, además de llamar a SetOut , no hay forma de configurar el valor predeterminado.

Si usa System.Diagnostics.Debug.WriteLine(...) lugar de Console.WriteLine() , puede ver los resultados en la ventana de resultados de Visual Studio.

He encontrado esta pregunta al tratar de cambiar la salida de Log del DataContext a la ventana de salida. Entonces, para cualquier otra persona que intente hacer lo mismo, lo que hice fue crear esto:

 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; } } } 

Y después de eso: dc.Log = new DebugTextWriter () y puedo ver todas las consultas en la ventana de salida (dc es el DataContext).

Eche un vistazo a esto para obtener más información: http://damieng.com/blog/2008/07/30/linq-to-sql-log-to-debug-window-file-memory-or-multiplewriters

Si está utilizando IIS Express y lo inicia mediante un símbolo del sistema, dejará la ventana de DOS abierta, y verá allí las instrucciones Console.Write .

Entonces, por ejemplo, abra una ventana de comando y escriba:

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

Esto supone que tiene un directorio de sitio web en C: \ Projects \ Website1. Iniciará IIS Express y publicará las páginas en el directorio de su sitio web. Dejará abiertas las ventanas de comandos y verá allí la información de salida. Supongamos que tiene un archivo allí, default.aspx, con este código:

 <%@ Page Language="C#" %>   
Hello! <% for(int i = 0; i < 6; i++) %> <% { Console.WriteLine(i.ToString()); }%>

Organice su navegador y ventanas de comandos para que pueda verlos en la pantalla. Ahora escriba en su navegador: http://localhost:1655/ . Verás ¡Hola! en la página web, pero en la ventana de comandos verá algo así como

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

Lo hice simple al tener el código en un bloque de código en el marcado, pero cualquier statement de consola en su código subyacente o en cualquier otro lugar en su código se mostrará aquí también.

Simplemente no hay consola escuchando por defecto. Al ejecutar en modo de depuración hay una consola conectada, pero en un entorno de producción es como sospechabas, el mensaje simplemente no funciona porque no hay nada escuchando.

A menos que estés en una aplicación de consola estricta, no la usaría, porque realmente no puedes verla. Usaría Trace.WriteLine () para la información del tipo de depuración que se puede activar y desactivar en producción.

System.Diagnostics.Debug.WriteLine(...); lo lleva a la ventana Inmediato en Visual Studio 2008.

Ir al menú Depurar -> Windows -> Inmediato :

Ingrese la descripción de la imagen aquí

El objeto TraceContext en ASP.NET escribe en DefaultTraceListener que se envía al resultado estándar del proceso de host. En lugar de usar Console.Write() , si usa Trace.Write , la salida irá a la salida estándar del proceso.

Puede usar el objeto System.Diagnostics.Process para obtener el proceso ASP.NET para su sitio y supervisar el resultado estándar utilizando el evento OutputDataRecieved .

Esto es confuso para todos cuando se trata de IISExpress. No hay nada para leer los mensajes de la consola. Entonces, por ejemplo, en las aplicaciones ASPCORE MVC se configura usando appsettings.json que no hace nada si está usando IISExpress.

Por ahora, puede agregar loggerFactory.AddDebug (LogLevel.Debug); en su sección Configurar y al menos le mostrará sus registros en la ventana de Salida de depuración.

Buenas noticias CORE 2.0 todo esto cambiará: https://github.com/aspnet/Announcements/issues/255

En una aplicación ASP.NET, creo que va a la ventana de Salida o Consola que está visible durante la depuración.

Si miras en la ventana de depuración, verás console.writelines.