I am currently using TopShelf with a Console Application to create a Windows Service. When I run the code as a console application I use a few Console.WriteLine() to output results. Once the code does what it is supposed to do I install the console application as a Windows Service.
Are there any downsides with leaving the Console.WriteLine() code even though a Windows Service can not write to the console? Are there any risks of having unstable code if I leave the Console.WriteLine() in there?
The output will simply be discarded.
In a Windows Service there is no Console so Console.Write* output is discarded. There are a number of alternatives:
- The System.Diagnostics.Trace class has a similar interface to the Console class so you could migrate your code quite easily to this.
- It can then be configured to output to a file. You can use the System.Diagnostics.EventLog class to write to the Event Log which you can then monitor using Event Viewer.
- You can use the third-party open-source log4net library which is very flexible.
No, the console class will safely write to the STDOUT, but you will just not see the output.
If you use the System.Diagnostics.Trace functionality, you can redirect the output using the listeners and switches. If you compile with the TRACE symbol, then code will be included. If you don't add the TRACE, then it won't be compiled into the project.
If you run your services as console for debugging, the Trace will output to the console by default. I've taken to using Trace instead of Debug or Console writes since I can, from the config file, output the trace information to any combination of files, screen, database, etc.
The output was always discarded until Windows Server 2008R2. Leave a console.writeline() in a service installed on that OS, and you'll get an error 1067 when starting/running the service, depending on the position of the writeline().
来源：https://stackoverflow.com/questions/8792978/console-writeline-inside-a-windows-service