如何从服务C＃捕获控制台输出？
我们有一个部署到远程客户系统的C＃服务。 应用程序将大量“诊断”信息写入控制台（即Console.WriteLine（））。 该服务不是“做它应该做的事”。 我们如何从另一个应用程序中的服务捕获控制台输出？
WinForm版本可以在客户位置加载应用程序。 不幸的是，它正常运作。
更新：
我们可以更改服务的更改，但此时不希望进行重大更改。
我们也登录MSMQ，但仅限于“重要”事件。 此服务确实与MSMQ交互以进行正常操作。 或者，至少，它应该。 当WinForm版本的时候，该服务似乎没有从MSMQ中提取项目。 因此，编写发送到控制台的消息可能会有问题。
你能改变服务代码吗？ 如果是这样，使用Console.SetOut写入文件将是最明显的第一个调用端口。 然后更改为使用适当的日志库为下一个版本:)
通常，应避免将诊断信息直接写入控制台，事件日志，MSMQ或应用程序代码中的其他位置。 而是调用日志API，并使用配置将输出重定向到任何您想要的位置。
例如，您可以通过Trace.WriteLine（*）替换所有Console.WriteLine。 然后，您可以通过修改应用程序配置文件将输出重定向到控制台，文件或其他位置：例如，要输出到控制台，请使用ConsoleTraceListener，例如：
在调试时，您将在控制台上获得输出 – 在客户站点上，您将其配置为将跟踪输出重定向到文件，事件日志或类似内容。
更好的是，使用第三方日志框架（我建议使用Log4Net），它将为您提供比System.Diagnostics.Trace更多的选项。
（*）Trace.Write / Trace.WriteLine与Debug.Write / Debug.WriteLine相同，只是后者仅在定义了DEBUG符号时编译。 如果希望输出在Release版本中可用，则更喜欢Trace to Debug。
你有很多选择; 将控制台输出重定向到文件并使用正确的日志库是两个好的。 这是一个中间选项：写入事件日志。
EventLog log; string logsource = "MyService"; // execute once per invocation if (!System.Diagnostics.EventLog.SourceExists(logsource)) { System.Diagnostics.EventLog.CreateEventSource( logsource, "Application"); } log = new EventLog(); log.Source = logsource; log.Log = "Application"; // replace console logging with this log.WriteEntry(message, EventLogEntryType.Information);
然后在Application事件日志（管理工具 – >事件查看器）中查找Source =“MyService”的条目。
我根本不会从Window Service使用Console.WriteLine。 您应该将这些错误记录到日志文件中。
执行此操作以使多个应用程序可以使用日志的另一种方法是将日志消息发布到MSMQ队列。
使用debug.writeline并使用sysinternals debugview？
我在MSDN上发现了这篇文章 ，它将Console输出绑定到一个富文本框，非常快速，轻松地为我工作。
它会覆盖WriteLine，并且可以扩展以覆盖其他方法。
以下是我查看在Windows 7下运行的服务的控制台输出的方法。如果您无法修改服务的源代码以记录到文件，这可能会有所帮助。
-
运行services.msc并编辑服务的属性。 在“登录”选项卡上，选中“允许服务与桌面交互”
-
使用注册表编辑器修改服务的ImagePath：转到HKEY_LOCAL_MACHINE \ SYSTEM \ ControlSet001 \ services \ [您的服务名称]并编辑ImagePath。 将
cmd.exe /c附加到ImagePath字符串的开头。 因此，如果您的原始ImagePath是c:\myService\myservice.exe新的ImagePath应为cmd.exe /cc:\myService\myservice.exe。 -
开始你的服务。 你应该得到一个标题为“交互式服务检测”的弹出窗口。 选择“查看邮件”。 您的屏幕应切换上下文并显示控制台窗口。 完成后，单击“立即返回”按钮。
-
完成调试后，将ImagePath修改回原始值。 然后取消选中服务属性中的“允许服务与桌面交互”复选框，然后重新启动服务。
警告：我只使用一项服务完成此操作，它对我有用。 我不知道它是否适用于任何服务，或者它是否会导致任何意外结果，因此我强烈建议您只在非生产环境中执行此操作。