Benefits of console app over windows service

Question

I have a .Net console App which using a scheduled event will start, call a mweb service method and the close. This runs every hour/every day. Whilst there is nothing 'wrong' with the implementation I was wondering if there was any benefit to implementing this as a windows service.

Has anyone any views of what would be the best practice in this case?

Answer 1

I Find Windows services hard to debug so I tend to only use them when:

(A) What I am doing is quite complex or

(B) needs to be running all the time(Example: Monitoring something for changes)

I find most things can usually be accomplished with a Console App some command line args and the Windows Scheduler.

Answer 2

A service is different from an application in three ways:

1. It runs without a user logged on to the system
2. It can not have any user interface (the console is a UI too)
3. It can run under elevated rights (SYSTEM account) and thus perform actions that are not allowed for users.

The questions to ask here is: Do you need the different options a service can give you? If the answer is no, then don't use a service.

I am inferring from your question that you need a background application without any user interface (item 2 above). You seem to have no need for items 1 or 3. You can get a pure background app without any window (console or else) by not creating one. Just create a simple Windows application and change

static class Program
{       
    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new Form1());
    }
}

to

static class Program
{       
    [STAThread]
    static void Main()
    {
        // Application.EnableVisualStyles();
        // Application.SetCompatibleTextRenderingDefault(false);
        // Application.Run(new Form1());

        DoWhateverYouWant();
    }
}

Oh yes, and Chris is completely right about debugging services being a real pain!

Answer 3

I think that what you have done is best practise. Nothing I hate more than apps that add their own services just to do something minor periodically. With the updated event log / task scheduler integration in >Vista even fewer apps really need a service any more, and if they do it can be on-demand.

You are making the world better.

:-)

Oh and being a console app makes it so u can run it manually easily if required, which is great for debugability.

To clarify: carry on, you are doing it right.

Answer 4

One important thing to consider is that the System.Drawing namespace is supported in console apps, which means that you can print. It sort of works in Windows Services but it is unsupported and is not completely stable.

Answer 5

Benefit: If your machine reboots (i.e. a server) you don't have to log in to get the thing to start working again.

I agree that debugging windows services SUCKS! It's horrible, and MS should really address the ability to debug a service.

However... there are some freeware tools that help that process out considerably. Anderson Imes has a nice utility that makes writing a windows service just like writing a console app, even during the debugging cycle.

Check out his utilities for service debugging at http://theimes.com/files/

The best part about his implementation is that it is a 1-line change in your code, that you can easily manage with #if DEBUG parameter if you don't want his library in your production instance.

Answer 6

There is a simple workaround for debugging services. You create a combined console/service app.

You check for some command-line argument (such as -debug) and then execute your OnStart code, Wait for keypress, execute OnStop code.

I use the same method to provde an interface to install, uninstall, start and stop my service from the same EXE.