在 J2EE 应用程序(如在 WebSphere 中运行的应用程序)中,当我使用 System.out.println()
时,我的文本将转到标准输出,它由 WebSphere 管理控制台映射到一个文件。
在 ASP.NET 应用程序(如在 IIS 中运行的应用程序)中,Console.WriteLine()
的输出到哪里去? IIS进程必须有stdin、stdout和stderr;但是 stdout 是否映射到 /dev/null 的 Windows 版本,还是我在这里遗漏了一个关键概念?
我不问我是否应该在那里登录(我使用 log4net),但输出到哪里去了?我最好的信息来自这个 discussion,他们说 Console.SetOut()
可以更改 TextWriter
,但它仍然没有回答控制台的初始值是什么,或者如何在 config/outside 中设置它的问题运行时代码。
如果您使用 System.Diagnostics.Debug.WriteLine(...)
而不是 Console.WriteLine()
,那么您可以在 Visual Studio 的 Output 窗口中看到结果。
如果查看 .NET Reflector 中的 Console
类,您会发现如果进程没有关联的控制台,则 Console.Out
和 Console.Error
由 Stream.Null
支持(包装在 TextWriter
),它是 Stream
的虚拟实现,它基本上忽略所有输入,并且不给出输出。
所以它在概念上等同于 /dev/null
,但实现更加精简:没有实际的 I/O 发生在 null 设备上。
此外,除了调用 SetOut
之外,无法配置默认值。
2020-11-02 更新:由于这个答案在 2020 年仍在收集投票,可能应该注意的是,在 ASP.NET Core 下,通常附加一个控制台。您可以配置 ASP.NET Core IIS Module 以通过 stdoutLogEnabled
和 stdoutLogFile
设置将所有 stdout 和 stderr 输出重定向到日志文件:
<system.webServer>
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
hostingModel="inprocess"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout" />
<system.webServer>
我通过尝试将 DataContext 的 Log 输出更改为输出窗口发现了这个问题。所以对于其他试图做同样事情的人来说,我所做的就是创建这个:
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; }
}
}
之后:dc.Log = new DebugTextWriter() 我可以在输出窗口中看到所有查询(dc 是 DataContext)。
看看这个以获取更多信息:http://damieng.com/blog/2008/07/30/linq-to-sql-log-to-debug-window-file-memory-or-multiple-writers
TextWriter
?
dc.Log = s => Debug.WriteLine(s);
。
如果您正在使用 IIS Express 并通过命令提示符启动它,它将使 DOS 窗口保持打开状态,您将在那里看到 Console.Write
语句。
例如,打开一个命令窗口并输入:
"C:\Program Files (x86)\IIS Express\iisexpress" /path:C:\Projects\Website1 /port:1655
这假设您在 C:\Projects\Website1 有一个网站目录。它将启动 IIS Express 并为您的网站目录中的页面提供服务。它将打开命令窗口,您将在那里看到输出信息。假设您在那里有一个文件 default.aspx,其中包含以下代码:
<%@ 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>
安排浏览器和命令窗口,以便您可以在屏幕上看到它们。现在在您的浏览器中输入:http://localhost:1655/
。你会看到你好!在网页上,但在命令窗口中,您会看到类似
Request started: "GET" http://localhost:1655/
0
1
2
3
4
5
Request ended: http://localhost:1655/default.aspx with HTTP status 200.0
我通过将代码放在标记中的代码块中来简化操作,但您的 code-behind 或代码中的任何其他位置中的任何控制台语句也将在此处显示。
System.Diagnostics.Debug.WriteLine(...);
将其放入 Visual Studio 2008 中的 即时窗口。
转到菜单调试 -> Windows -> 立即:
https://i.stack.imgur.com/yq68G.png
Immediate Window
旁边的 Output
中,谢谢!
默认情况下根本没有控制台监听。在调试模式下运行时附加了一个控制台,但在生产环境中,正如您所怀疑的那样,消息不会去任何地方,因为没有人在听。
除非您在严格的控制台应用程序中,否则我不会使用它,因为您无法真正看到它。我会使用 Trace.WriteLine() 来获取可以在生产中打开和关闭的调试类型信息。
ASP.NET 中的 TraceContext
对象写入 DefaultTraceListener
,后者输出到主机进程的 standard output。如果您使用 Trace.Write
,而不是使用 Console.Write()
,输出将转到进程的标准输出。
您可以使用 System.Diagnostics.Process
对象为您的站点获取 ASP.NET 进程并使用 OutputDataRecieved
事件监视标准输出。
如果您碰巧在您的 ASP.net 项目中使用了 NLog,您可以添加一个 Debugger target:
<targets>
<target name="debugger" xsi:type="Debugger"
layout="${date:format=HH\:mm\:ss}|${pad:padding=5:inner=${level:uppercase=true}}|${message} "/>
并将日志写入此目标以获得所需的级别:
<rules>
<logger name="*" minlevel="Trace" writeTo="debugger" />
现在你有控制台输出,就像 VS 的“输出”窗口中的 Jetty 一样,并确保你在调试模式(F5)下运行。
当涉及到 IISExpress 时,这让每个人都感到困惑。没有什么可以读取控制台消息的。因此,例如,在 ASPCORE MVC 应用程序中,它使用 appsettings.json 进行配置,如果您使用的是 IISExpress,它什么也不做。
现在你可以添加 loggerFactory.AddDebug(LogLevel.Debug);在您的配置部分,它至少会在调试输出窗口中显示您的日志。
好消息 CORE 2.0 这一切都将发生变化:https://github.com/aspnet/Announcements/issues/255
https://i.stack.imgur.com/ZFU1Q.png
使用 console.Writeline 对我不起作用。
有什么帮助是放置一个断点,然后在调试时运行测试。当它到达断点时,您可以观察返回的内容。
尝试以我们在节点控制台中执行的方式附加有点“后端调试器”以将您的消息或数据记录到控制台或输出窗口。
System.Diagnostics.Debug.WriteLine("Message" + variable)
而不是 Console.WriteLine()
通过这种方式,您可以在 Visual Studio 的输出窗口(即控制台)中看到结果。
在 ASP.NET 应用程序中,我认为它会转到在调试期间可见的输出或控制台窗口。
ddl.selectedvalue
写入输出窗口时没有将下拉列表设置为autopostback="true"
。