Windows Service or Console application

[Krish]

I want to develop and application that run periodically in the server
machine. Now Should I go for a windows service or just create a Console
application and schedule it using the windows Task Scheduler.

What are the advantages and disadvantages of each approach.
Thanks
Krish

 

[Vadym Stetsyak]

Hello, Krish!

services are there to run for a long time and before any user logged in.

IMO it would be far more simple to do this via console application

You wrote on 19 Dec 2006 04:13:02 -0800:

K> I want to develop and application that run periodically in the server
K> machine. Now Should I go for a windows service or just create a
K> Console
K> application and schedule it using the windows Task Scheduler.

K> What are the advantages and disadvantages of each approach.
K> Thanks
K> Krish


With best regards, Vadym Stetsyak.
Blog: http://vadmyst.blogspot.com

 

[Oliver Sturm]

Hello Vadym,

services are there to run for a long time and before any user logged in.

IMO it would be far more simple to do this via console application

In many ways you may be correct in saying that it's simpler to use a
console applications. But writing applications is often not about the
simplest approach, but rather about satisfying criteria.

What you're saying first is important: services run when nobody is logged
in. As the OP was talking about a "server machine", I assume that this
could very well be an important feature.

In my experience, the best way to go is this:

* Pull out the core functionality of your service into a class library assembly

* Create a console application that utilizes the functionality in the library. This application can easily be debugged and tested, without the additional requirements and complications of the service.

* Create a Windows service that utilizes the functionality of the library as well. Deploy this, or maybe deploy both this and the console application - sometimes both can make sense.

The overhead of creating two different executables is typically minimal,
if you do a good job of moving all actual functionality into the library
assembly. Each of the executables usually ends up having just a very small
number of lines of code, for example to parse command line options or to
set up logging options.


Oliver Sturm

 

[Krish]

So you mean .. for windows scheduled task to run someone should be
logged in to the to server, but for the service it will run even if
there is no user logged in?

The advantake I see for the scheduled task is, it is easier to change
the schedule from the UI unlike a service(you may have to use config
file for the same).

 

[Krish]

Hello Oliver

I was planning to do this way only. But as this is an admin
functionality If I host this as a windows service the admin will ask
for a UI to change the schedule as desired. If we are using the windows
scheduler, then a separate UI is not required.

What do you say?
Regards
Krish

 

[John Timney \(MVP\)]

It depends on what its trying to do - things with interfaces or network
calls for example are really tricky as services so I tend to use them when
the remit of whats its doing is really quite simple, like monitoring
something locally. Windows services are harder to work with, debug and test
and limited by the account they run under where a scheduled service can very
easily be switched to any account in the scheduler interface. Console is
usually the easier of two approaches if theres little difference between
them as it costs less in time and effort to create, and inevitably will be
easier to support.
--
Regards

John Timney (MVP)
VISIT MY WEBSITE:
http://www.johntimney.com
http://www.johntimney.com/blog

 

[Oliver Sturm]

Hello Krish,

I was planning to do this way only. But as this is an admin
functionality If I host this as a windows service the admin will ask
for a UI to change the schedule as desired. If we are using the windows
scheduler, then a separate UI is not required.

Fair enough, I take your point.

I have implemented that kind of interface in the past and it wasn't too
hard, and it can also be a good thing because I find that the requirements
of scheduling in server software are often not really covered by the
Windows scheduler. Implementing my own interface allows me to have exactly
the right functionality covered, which helps reduce confusion. That said,
of course it takes time - no question about that.


Oliver Sturm