C# Windows Service

[dm3281]

Hello --

I plan on writing a C# service using VS2005.

If I want my service to have a tray icon, is this typically done from within
my service or do/should I create a controller application and have that run
separately from my service?

 

[Jeroen Mostert]

If I want my service to have a tray icon, is this typically done from
within my service or do/should I create a controller application and
have that run separately from my service?

The latter. Services should not interact with any user, and indeed by
default they cannot (they run in a separate non-interactive window station).

Services typically run with elevated privileges, so design the interface
between your service and the controller application carefully. In
particular, the controller application should not enable a lower-privileged
user to compromise the system by interacting with the service in an
uncontrolled manner.

Also, consider the idea of having a tray icon in the first place carefully.
Is your service really both important enough to warrant an icon *and* so
often in need of adjustment that you need a permanently accessible icon for
it? A simple on-demand application may do just as well.

I currently have two services on my system that work with tray icons, and
I'm happy that Windows allows me to hide these icons, because I sure never
need them... Only one of these offers me the option of removing the tray
icon, but this is only good for the current session -- at the next logon it
will cheerfully pop up again. Take care not to bother the user with things
they're not interested in.

 

[Mr. Arnold]

Hello --

I plan on writing a C# service using VS2005.

If I want my service to have a tray icon, is this typically done from
within my service or do/should I create a controller application and have
that run separately from my service?

Sure, you can have a exe application that sits in the job trey that controls
the Windows service. About the only thing the program should be doing is
starting or stopping the service.

 

[Mudassar Hassan]

you can create tray icon from your service or you can create a seperate exe
that integrate/works with your service.


Regards,
Mudassar Hassan
http://mudassarhassan.spaces.live.com/

 

[Jeroen Mostert]

you can create tray icon from your service or you can create a seperate exe
that integrate/works with your service.

I reiterate that services should not and by default cannot interact with
users. From Windows Vista onwards, there is not even a way to allow it
anyway as there was with previous versions of Windows
(http://msdn.microsoft.com/library/bb126610.aspx).

 

[Mr. Arnold]

I reiterate that services should not and by default cannot interact with
users. From Windows Vista onwards, there is not even a way to allow it
anyway as there was with previous versions of Windows
(http://msdn.microsoft.com/library/bb126610.aspx).

You want to show some kind of standard here to say that a Windows Service
should not interact with the user. Where does it say that? I am going to
assume that you are not talking about an UI exe in communications with a
Windows Service.

And what is that link suppose to be showing about Vista?

 

[Jeroen Mostert]

You want to show some kind of standard here to say that a Windows
Service should not interact with the user. Where does it say that?

Is http://support.microsoft.com/kb/327618 good enough?

I am going to assume that you are not talking about an UI exe in
communications with a Windows Service.

And what is that link suppose to be showing about Vista?

Ha, good catch. I managed to copy the wrong link somehow... The linked
article is interesting if you're interested in Domain-Specific Languages,
but won't tell you much about Vista and interactive services. I wanted this
one: http://msdn.microsoft.com/library/ms683502.aspx

 

[Mr. Arnold]

Is http://support.microsoft.com/kb/327618 good enough?

That link doesn't indicate what you are talking, and the only thing it
indicates is the statement below, which a Windows service doesn't have to
run with System rights.

<copied>

Important We strongly recommend that services do not run as interactive
services if the services run in an elevated security context such as SYSTEM.

<copied>

Your advise doesn't seem to be correct for all situations here.

Heck, even in the MCSD MSPress Certification book for Windows desktop
solutions in C# and VB back for VS 2003 had a whole application exercise
that was using a Windows form base solution that was in communications with
a Windows service on the backend and passing data to/from each other.

Ha, good catch. I managed to copy the wrong link somehow... The linked
article is interesting if you're interested in Domain-Specific Languages,
but won't tell you much about Vista and interactive services. I wanted
this one: http://msdn.microsoft.com/library/ms683502.aspx

I don't know man. If I wanted to communicate interactively with a Windows
service from a Windows desktop solution on Vista, I would be using .Net
Remoting, MSMQ, or (WCF using a Named Pipe or MSMQ) locally if I had to go
that route.

You can also use this too on Vista for cross process communications,
locally.

http://www.codeproject.com/KB/dotnet/XDMessaging.aspx

Maybe we are talking two different things in going into communications with
a Windows service from a desktop solution interactively.

 

[Jeroen Mostert]

That link doesn't indicate what you are talking, and the only thing it
indicates is the statement below, which a Windows service doesn't have
to run with System rights.

<copied>

Important We strongly recommend that services do not run as interactive
services if the services run in an elevated security context such as
SYSTEM.

<copied>

Your advise doesn't seem to be correct for all situations here.

A service is an always-on, background process. For this reason alone it's
fundamentally flawed to have it interact with the desktop: there need never
be anyone sitting in front of the computer, so what exactly is the service
trying to achieve with that?

Second, services usually run with elevated credentials. It needn't be SYSTEM
-- that's just the worst-case scenario. The point is that a service will
usually run under credentials that allow it to do things any other logged-on
user can't do directly, as that's often the point of having a service in the
first place (though admittedly not always). For example, SQL Server can run
under limited credentials, but even in this setup those are usually the only
credentials with file system access to the database, for obvious reasons.

All interactive services open themselves up to shatter attacks, and there's
not much they can do against it. It's a security vulnerability, which is why
Microsoft closed it off altogether.

Heck, even in the MCSD MSPress Certification book for Windows desktop
solutions in C# and VB back for VS 2003 had a whole application
exercise that was using a Windows form base solution that was in
communications with a Windows service on the backend and passing data
to/from each other.

And there's nothing wrong with that -- I assume it wasn't the *service* that
was displaying UI.

I don't know man. If I wanted to communicate interactively with a
Windows service from a Windows desktop solution on Vista, I would be
using .Net Remoting, MSMQ, or (WCF using a Named Pipe or MSMQ) locally
if I had to go that route.

Sure, all fine solutions. All these channels are securable and provide
isolation.

You can also use this too on Vista for cross process communications,
locally.

http://www.codeproject.com/KB/dotnet/XDMessaging.aspx

Maybe we are talking two different things in going into communications
with a Windows service from a desktop solution interactively.

Let's be clear here: there's nothing wrong with communicating with a service
in a cross-process scenario. What's strongly discouraged is your *service*
interacting with the desktop *directly*.

 

[Mr. Arnold]

Let's be clear here: there's nothing wrong with communicating with a
service in a cross-process scenario. What's strongly discouraged is your
*service* interacting with the desktop *directly*.

All my experience with Windows services have been with unattended execution
for backend processing. in a queuing scenario.

If I had to go into communications with a Windows Service from the UI, then
it would be based on what I have discussed with you, which is program and
cross-process isolation.

Maybe, the OP will read all of the posts between you and I and has learned
something.

You take care now, yeah hear.