What is an acceptable template for an application that can be run as a service or console application

Question

I have a project that is being deployed as a Windows service. However, for local development purposes, it would be useful to run it as a console application. At the moment, I have a Called ReportingHost class that provides my main functionality, and a class called ReportingServiceHost, which inherits from ServiceBase and allows me to run the application as a service. There is also a program class with a main method that calls ServiceBase.Run in my ReportingServiceHost.

I think I need to write a ReportingConsoleHost class that allows me to run functionality in the console. Then I need to change my Main in order to respond to the command line switch and select one or the other. These are the two bits that I encountered.

I looked over this one and tried to use this code, but my application will exit immediately, it does not display the console window and it does not wait for Enter before closing.

Part of the problem is that I don’t have a deep understanding of how this works. the final template for sharing my functionality, two different ways to use this functionality, and the main method that selects one of these methods based on a command line argument is what I hope to achieve.

Answer 1

I suspect your test project was configured as exe windows, not console exe. With the exe window, Console.ReadLine will immediately return.

To have a console exe that works both as a service and on the command line, run it as a service project (in Visual Studio) and add a check for Environment.UserInteractive - i.e.

 static void Main() { if(Environment.UserInteractive) { // code that starts the listener and waits on ReadLine } else { // run the service code that the VS template injected } } 

Of course, you can also use the command line switch. I have an example on microsoft.public.dotnet.languages.csharp that acts like:

• installer / uninstaller
• service
• console application

depending on the switches

Answer 2

I did this earlier by running a regular Windows service (by retrieving from ServiceBase), but putting the check in the main method to check the command line argument.

If the arguments contain /console , start the console version; otherwise, start the service.

Something like that:

 internal class MyService : ServiceBase { internal static void Main(string[] args) { if (args.Length == 0) { // run as a service.... ServiceBase[] servicesToRun = new ServiceBase[] {new MyService()}; Run(servicesToRun); } else { // run as a console application.... } } } 

Answer 3

My advice? Put all your logic for your service in a separate assembly. (Class library or DLL.) Then create one project as a service that references your class library and puts the code as services. Create a second console project that also references your class library, but which makes it available as a console application. In the end, you will have three different projects, but this will allow you to keep things aside. In fact, this would expand your service in several other forms. For example, you can create a 4th project as a web service and, thus, call your service from a web browser in the client system. Because software logic is separate from usage logic, you get a lot of control over it.

Remember that a service can work with more restrictions than a console application. In general, services do not have network access by default, do not have a monitor assigned to them for displaying error messages, and in general with a limited user account or system account. Because of this, your service may work as a console, but because of this it does not work.

Answer 4

There are already two good answers above, but I thought I posted a link to Browan Noise's "Debugging Self-Service Windows Service Project blog post - it talks about WCF, but should apply to any" Windows service. "

The best code example is if you can't figure out where the examples above fit, take the whole project and see how it works. Thanks Brian !