469,343 Members | 5,478 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,343 developers. It's quick & easy.

Windows Service or Console application

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

Dec 19 '06 #1
6 8336
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:

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

KWhat are the advantages and disadvantages of each approach.
KThanks
KKrish
With best regards, Vadym Stetsyak.
Blog: http://vadmyst.blogspot.com
Dec 19 '06 #2
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).
Vadym Stetsyak wrote:
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:

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

KWhat are the advantages and disadvantages of each approach.
KThanks
KKrish
With best regards, Vadym Stetsyak.
Blog: http://vadmyst.blogspot.com
Dec 19 '06 #3
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
--
http://www.sturmnet.org/blog
Dec 19 '06 #4
Hello Oliver
> * Pull out the core functionality of your service into a class library assembly
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

Dec 19 '06 #5
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
"Krish" <ba****@gmail.comwrote in message
news:11*********************@j72g2000cwa.googlegro ups.com...
>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

Dec 19 '06 #6
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
--
http://www.sturmnet.org/blog
Dec 19 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Hardy Wang | last post: by
7 posts views Thread by Mike | last post: by
9 posts views Thread by SP | last post: by
3 posts views Thread by John Fred | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.