Hello William,
Thanks for posting in the group.
Service applications function differently from many other project types in
several ways:
1) The compiled executable file that a service application project creates
must be installed on the server before the project can function in a
meaningful way. You cannot debug or run a service application by pressing
F5 or F11; you cannot immediately run a service or step into its code.
Instead, you must install and start your service, and then attach a
debugger to the service's process. For more information, see Debugging
Windows Service Applications.
2) Unlike some types of projects, you must create installation components
for service applications. The installation components install and register
the service on the server and create an entry for your service with the
Windows Services Control Manager. For more information, see Adding
Installers to your Service Application.
3) The Main method for your service application must issue the Run command
for the services your project contains. The Run method loads the services
into the Services Control Manager on the appropriate server. If you use the
Windows Services project template, this method is written for you
automatically. Note that loading a service is not the same thing as
starting the service. See Service Lifetime below for more information.
4) Windows Service applications run in a different window station than the
interactive station of the logged-on user. A window station is a secure
object that contains a clipboard, a set of global atoms, and a group of
desktop objects. Because the station of the Windows Service is not an
interactive station, dialog boxes raised from within a Windows Service
application will not be seen and may cause your program to stop responding.
Similarly, error messages should be logged in the Windows event log rather
than raised in the user interface.
5) The Windows Service classes supported by the .NET Framework do not
support interaction with interactive stations, that is, the logged-on user.
The .NET Framework also does not include classes that represent stations
and desktops. If your Windows Service must interact with other stations,
you will need to access the unmanaged Windows API. For more information,
see Window Stations and Desktops in the Platform SDK documentation.
6) The interaction of the Windows Service with the user or other stations
must be carefully designed to include scenarios such as there being no
logged on user, or the user having an unexpected set of desktop objects. In
some cases, it may be more appropriate to write a Windows application that
runs under the control of the user.
7) Windows Service applications run in their own security context and are
started before the user logs into the Windows computer on which they are
installed. You should plan carefully what user account to run the service
within; a service running under the system account has more permissions and
privileges than a user account.
So I think there are several things that you need also consider: security
context, interaction, installation method.
Does that answer your question?
Best regards,
Yanhong Huang
Microsoft Online Partner Support
Get Secure! -
www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
!Subject: Console vs Service Application
!From: William Bartholomew <
[email protected]>
!Message-ID: <
[email protected]>
!User-Agent: Xnews/5.04.25
!X-Archive: yes
!Newsgroups: microsoft.public.dotnet.framework
!Date: Sat, 13 Sep 2003 16:23:20 -0700
!NNTP-Posting-Host: m013-145.nv.iinet.net.au 203.217.13.145
!Lines: 1
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
!Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework:53655
!X-Tomcat-NG: microsoft.public.dotnet.framework
!
!I'm writing an application that needs to run every x minutes, read in some
!data from a log file and then write it out to a database.
!
!Originally I was going to write it as a service but the more I think about
!it I feel it would work just as well as a console application that is
!scheduled using the Windows scheduler.
!
!I'm just curious as to whether there are any other advantages to using a
!service that I might not have thought of?
!
!Here are some reasons why I thought a console application would be
!acceptable:
!
!1. It is easier to schedule the console application using the Windows
!scheduler or 3rd party scheduling applications, using a service I would
!need to write scheduling code into it
!
!2. It doesn't matter if the application is manually run between scheduled
!periods
!
!3. It could be handy to write output to the console so if someone manually
!runs it that can see what is happening
!
!Any thoughts would be greatly appreciated.
!
!
!William D. Bartholomew
!
