¿Dónde está Console.WriteLine en ASP.NET?
https://stackoverflow.com/questions/137660
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
En una aplicación J2EE (como una que se ejecuta en WebSphere), cuando uso System.out.println () , mi texto pasa a la salida estándar, que el administrador de WebSphere asigna a un archivo consola.
En una aplicación ASP.NET (como una que se ejecuta en IIS), ¿a dónde va la salida de Console.WriteLine () ? El proceso de IIS debe tener un stdin, stdout y stderr; pero ¿está stdout asignado a la versión de Windows de / dev / null o me estoy perdiendo un concepto clave aquí?
No estoy preguntando si debo iniciar sesión allí (uso log4net), pero ¿a dónde va la salida? Mi mejor información provino de esta discusión donde dicen < code> Console.SetOut () puede cambiar el TextWriter , pero aún no responde la pregunta sobre cuál es el valor inicial de la consola, o cómo configurarlo en config / fuera del código de tiempo de ejecución.
Solución
Si observa la clase 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 (incluido 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 ágil: no se realiza ninguna E / S real con el dispositivo nulo.
Además, aparte de llamar a SetOut , no hay manera de configurar el valor predeterminado.
Otros consejos
Si usa System.Diagnostics.Debug.WriteLine (...) en lugar de Console.WriteLine () , entonces puede ver los resultados en Ventana de salida de Visual Studio.
He encontrado esta pregunta al intentar cambiar la salida del registro del DataContext a la ventana de salida. Así que 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 resultados (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-multiple -los escritores
Si está utilizando IIS Express y lo inicia a través de un símbolo del sistema, dejará el DOS ventana abierta, y verá las declaraciones de Console.Write allí.
Entonces, por ejemplo, abre una ventana de comando y escribe:
"C:\Program Files (x86)\IIS Express\iisexpress" /path:C:\Projects\Website1 /port:1655
Esto supone que tiene un directorio de sitios web en C: \ Projects \ Website1. Iniciará IIS Express y servirá las páginas en el directorio de su sitio web. Dejará abiertas las ventanas de comando y verá información de salida allí. Digamos que tenía un archivo allí, default.aspx, con este código:
<%@ 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>
Organice su navegador y las ventanas de comando para que pueda verlas 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 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 simplifiqué al tener el código en un bloque de código en el marcado, pero cualquier declaración de consola en su code-behind o en cualquier otro lugar de su código también se mostrará aquí.
Simplemente no hay consola de escucha por defecto. Al ejecutarse en modo de depuración, hay una consola adjunta, pero en un entorno de producción es como sospechaba, el mensaje simplemente no llega a ningún lado porque no hay nada que escuche.
System.Diagnostics.Debug.WriteLine (...); lo introduce en la Ventana Inmediata en Visual & nbsp; Studio & nbsp; 2008.
Ir al menú Depurar - > Windows - > Inmediato :
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 de tipo de depuración que se puede activar y desactivar en la producción.
El objeto TraceContext en ASP.NET se escribe en el DefaultTraceListener que se envía al proceso del host ' salida estándar . 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 monitorear la salida estándar usando el evento OutputDataRecieved .
Si usó NLog en su proyecto ASP.net, puede agregar un Destino del depurador :
<targets>
<target name="debugger" xsi:type="Debugger"
layout="${date:format=HH\:mm\:ss}|${pad:padding=5:inner=${level:uppercase=true}}|${message} "/>
y escribe los registros en este destino para los niveles que deseas:
<rules>
<logger name="*" minlevel="Trace" writeTo="debugger" />
ahora tienes salida de consola como Jetty en " Salida " ventana de VS, y asegúrese de que está ejecutando en modo de depuración (F5).
Esto es confuso para todos cuando se trata de IISExpress. No hay nada para leer los mensajes de la consola. Así, por ejemplo, en las aplicaciones de ASPCORE MVC se configura mediante appsettings.json, que no hace nada si está utilizando IISExpress.
Por ahora, solo puedes agregar loggerFactory.AddDebug (LogLevel.Debug); en su sección Configurar y al menos le mostrará sus registros en la ventana de resultados de depuración.
Buenas noticias CORE 2.0 todo esto cambiará: https://github.com/aspnet / Anuncios / números / 255
En una aplicación ASP.NET, creo que va a la ventana Salida o Consola que está visible durante la depuración.
