VB .Net Windows 服务控制台消息
我有一个 .Net 控制台应用程序，每分钟在控制台上显示数千行。我想将其转换为 Windows 服务，但我仍然需要一种查看这些消息的方法。消息太多，无法将其写入事件日志甚至标准日志文件。我想知道是否有一种方法可以编写一个系统托盘应用程序，可以简单地拦截来自服务的这些消息并将它们显示在控制台窗口中。我不需要保存旧消息，我只需要查看当前活动。
I have a .Net Console application which displays thousands of lines on the console each minute. I want to convert it to a Windows Service, however I still need a way of viewing these messages. There are far too many messages to write them to the event log or even a standard log file. I was wondering if there were a way to write a systray app that could simply intercept these messages from the service and display them in a console window. I have no need to save older messages, I only need to see current activity.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
该服务需要写入某种类型的共享内存，以便与显示输出的另一个程序进行通信。我认为最好的选择是输出到 SQL 表或其他表并清除旧条目，这样表中一次的记录永远不会超过 1000 条。然后在查看器应用程序中每秒对表执行几次 ping 操作，并显示输出的流视图。
The service will need to write to shared memory of some sort in order to communicate with another program that displays the output. I think your best bet is to output to a SQL table or something and clear out older entries so there is never more than, say, 1000 records in the table at a time. Then ping the table a couple times a second in the viewer app and display a streaming view of the output.
听起来 System.Diagnostics.Trace 类型非常适合这种情况。分两个阶段实施您的更改：
对于第 1 阶段，您将 ConsoleTraceListener 添加到您的应用程序，并将所有当前对 Console 的调用转换为写入 Trace。这只会维持您现有的行为，但它可以让您轻松更改新的输出。
对于第 2 阶段，您实现一个可以附加的新 TraceListener，而不是 ConsoleTraceListener，它可以对消息执行任何您想要的操作。这可能包括侦听来自您建议的系统托盘或控制台应用程序的连接。更好的是，我敢打赌，谷歌搜索一下就会向您展示一个已经完成您想要的功能的 TraceListener。
至于传达消息的实际机制，我的建议是使用标准的 SysLog 方法。这具有为客户端使用现有软件的优点，使您更有可能找到 现有的 TraceListener，以及许多现有的 syslog 客户端将带来一些自动数据挖掘作为奖励。
Sounds like the
System.Diagnostics.Tracetype would be perfect for this. Implement your changes in two phases:For phase 1, you add a ConsoleTraceListener to your app, and convert all of your current calls to Console to write to Trace instead. This will only maintain your existing behavior, but it sets you up to easily make the change to your new output.
For phase 2, you implement a new TraceListener you can attach instead of the ConsoleTraceListener that does whatever you want with the messages. This might include listening for a connection from your proposed systray or console app. Even better, I bet a bit of googling will show you a TraceListener that already does what you want.
As for the actual mechanism for communicating the message, my recommendation is to use the standard SysLog approach. This has the advantages of working existing software for the client, makes it more likely you'll find an existing TraceListener, and many of the existing syslog clients will bring along some automated data mining as a bonus.