Console.WriteLine 在 ASP.NET 中的位置在哪里？答案

【问题标题】：Where does Console.WriteLine go in ASP.NET?Console.WriteLine 在 ASP.NET 中的位置在哪里？
【发布时间】：2010-09-13 08:27:54
【问题描述】：

在一个 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 中设置它的问题运行时代码。

【问题讨论】：

它实际上会转到 ASP.NET Worker 进程的 STDOUT。这是指向哪里，我不确定。
这是个问题 - STDOUT 去哪儿了？
显然没有人知道，但每个人都在他们的例子中使用它。 wtf
如果您正在寻找调试目的，我会参考下面的@Greg Bernhardt 回复。
@KevinHakanson FWIW 这么多年过去了，任何进程的标准输出都是由其父进程选择的，即启动它的进程。在这种情况下，父级将是 IIS。 This might point you in the right direction.

标签： asp.net iis console.writeline

【解决方案1】：

如果您使用System.Diagnostics.Debug.WriteLine(...) 而不是Console.WriteLine()，那么您可以在Visual Studio 的输出窗口中看到结果。

【讨论】：

我会问和凯文一样的问题，但这是我一直在寻找的答案。
还有一点小提示；如果要打印格式化字符串，请使用 Debug.Print 而不是 Debug.WriteLine 以避免参数冲突（请参阅social.msdn.microsoft.com/Forums/ar/Vsexpressvcs/thread/…）。
请注意，需要附加调试器才能在“输出”窗口中显示消息。
这对本地 IIS 或其他东西不起作用吗？尽管我是从 F5 开始的（因此附加了调试器），但我似乎无法在我的一生中写入输出。我知道我的代码正在执行，因为我可以很好地写入文件。
@Kat 确保您尝试查看的更改实际上是在您期望的时候发回服务器。我遇到了同样的问题，直到我意识到当我尝试将ddl.selectedvalue 写入输出窗口时，我没有将下拉列表设置为autopostback="true"。

【解决方案2】：

如果您查看.NET Reflector 中的Console 类，您会发现如果进程没有关联的控制台，Console.Out 和Console.Error 由Stream.Null 支持（包装在TextWriter)，这是 Stream 的虚拟实现，基本上忽略所有输入，不给出输出。

所以它在概念上等同于/dev/null，但实现更加精简：没有实际的 I/O 发生在 null 设备上。

另外，除了调用SetOut，没有办法配置默认。

2020-11-02 更新：由于这个答案在 2020 年仍在收集投票，可能应该注意的是，在 ASP.NET Core 下，通常是附加控制台。您可以通过stdoutLogEnabled 和stdoutLogFile 设置将ASP.NET Core IIS Module 配置为将所有stdout 和stderr 输出重定向到日志文件：

<system.webServer>
  <aspNetCore processPath="dotnet"
              arguments=".\MyApp.dll"
              hostingModel="inprocess"
              stdoutLogEnabled="true"
              stdoutLogFile=".\logs\stdout" />
<system.webServer>

【讨论】：

如果您确实希望将某些内容写入“输出”窗口（调试时可以查看），请使用 System.Diagnostics.Debug.WriteLine()。

【解决方案3】：

我通过尝试将 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）。

【讨论】：

既然您要包装完全静态的方法，为什么不直接使用静态包装器呢？为什么还要扩展TextWriter？
你也可以使用dc.Log = s => Debug.WriteLine(s);。
Application_Start: System.Console.SetOut(new DebugTextWriter());
更好的是，Console.SetOut(new DebugTextWriter());

【解决方案4】：

如果您使用 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 或代码中的任何其他位置中的任何控制台语句也会显示在此处。

【讨论】：

+1 为此，我在开发时总是使用 IIS Express。控制台输出非常宝贵，在后端使用，就像前端的 javascript 控制台一样。与使用基于文件的服务器日志相比，可以节省大量调试时间。您不必重写“友好”的异常处理 - 保留漂亮的“oops”浏览器页面，只需将异常输出到控制台，易于查看。

【解决方案5】：

System.Diagnostics.Debug.WriteLine(...); 将其放入 Visual Studio 2008 中的即时窗口。

转到菜单调试 -> Windows -> 立即：

【讨论】：

在我的 Visual Studio 2012 中，我按照您所说的进行操作，但字符串出现在 Output 中，除了 Immediate Window 谢谢！

【解决方案6】：

默认情况下根本没有控制台监听。在调试模式下运行时附加了一个控制台，但在生产环境中，正如您所怀疑的那样，消息不会去任何地方，因为没有人在监听。

【讨论】：

【解决方案7】：

除非您在严格的控制台应用程序中，否则我不会使用它，因为您无法真正看到它。我会使用 Trace.WriteLine() 来获取可以在生产中打开和关闭的调试类型信息。

【讨论】：

是的，这是一个很好的起点：msdn.microsoft.com/en-us/library/x5952w0c.aspx

【解决方案8】：

ASP.NET 中的TraceContext 对象写入DefaultTraceListener，后者输出到主机进程'standard output。如果使用Trace.Write，而不是使用Console.Write()，输出将转到进程的标准输出。

您可以使用System.Diagnostics.Process 对象为您的站点获取ASP.NET 进程，并使用OutputDataRecieved 事件监控标准输出。

【讨论】：

【解决方案9】：

如果你碰巧在你的 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）下运行。

【讨论】：

【解决方案10】：

当谈到 IISExpress 时，每个人都会感到困惑。没有什么可以读取控制台消息的。因此，例如，在 ASPCORE MVC 应用程序中，它使用 appsettings.json 进行配置，如果您使用的是 IISExpress，它什么也不做。

现在你可以添加 loggerFactory.AddDebug(LogLevel.Debug);在您的配置部分，它至少会在调试输出窗口中显示您的日志。

好消息 CORE 2.0 这一切都将发生变化：https://github.com/aspnet/Announcements/issues/255

【讨论】：

【解决方案11】：

Mac，在调试模式下，有一个用于输出的选项卡。

【讨论】：

【解决方案12】：

使用 console.Writeline 对我不起作用。

有什么帮助是放置一个断点，然后在调试时运行测试。当它到达断点时，您可以观察返回的内容。

【讨论】：

【解决方案13】：

尝试像我们在节点控制台中所做的那样，附加某种“后端调试器”以将您的消息或数据记录到控制台或输出窗口。

System.Diagnostics.Debug.WriteLine("Message" + variable) 而不是Console.WriteLine()

这样您就可以在输出窗口（即 Visual Studio 的控制台）中看到结果。

【讨论】：

【解决方案14】：

在 ASP.NET 应用程序中，我认为它会转到在调试期间可见的输出或控制台窗口。

【讨论】：