Problem using the shell function in a service.

[dave m]

I have a small application that launches an application via the shell
function when a listening socket receives data from another PC. This works
fine using a WinForms environment.

However, I want this listing app to run in the background as a service.
When debugging the service, the line -

ID = Shell("C:\TestApp.exe", AppWinStyle.NormalFocus)

returns a PID value, executes without errors, but the program "TestApp.exe"
doesn't start. Task manager show TestApp as a running process, but it
really didn't because it would have incremented a value in a database.

Once again the code runs fine in WinForms but not as a service.

Any suggestions would be greatly appreciated.

Dave M

 

[Herfried K. Wagner [MVP]]

I have a small application that launches an application via the shell
function when a listening socket receives data from another PC. This
works fine using a WinForms environment.

However, I want this listing app to run in the background as a service.
When debugging the service, the line -

ID = Shell("C:\TestApp.exe", AppWinStyle.NormalFocus)

returns a PID value, executes without errors, but the program
"TestApp.exe" doesn't start. Task manager show TestApp as a running
process, but it really didn't because it would have incremented a value in
a database.

This doesn't work "by design". Services can even run if no user is logged
on and thus cannot have access to the desktop. I suggest to rethink whether
a service is the right choice. Maybe an application which gets started when
the user logs on is a viable alternative.

 

[CMM]

Not sure this is correct, Herfried . 1) The user doesn't mention "the
desktop" does he? 2) In any case, Services can for sure interact with the
current desktop (if it's loaded) if they so wished. Why do you say they
cannot?

Anyway... Dave M,
1) you mention a "database." Services are typically set to run under the
Local System account and are limited in their network access. Have you tried
running your service under a different user account (you can configure this
in Windows' Computer Management console). But that brings up another
question....
2) I'm not sure if processes spawned using "Shell" inherit the environment
of the caller program if the caller is a service. They probably do. I'm
almost sure of it. But you may need to look into Process.Start (and possibly
ProcessStartInfo if you need fine-grained control) to spawn your process and
get it to work right with the right privileges.

 

[Herfried K. Wagner [MVP]]

Not sure this is correct, Herfried . 1) The user doesn't mention "the
desktop" does he? 2) In any case, Services can for sure interact with the
current desktop (if it's loaded) if they so wished. Why do you say they
cannot?

Services can interact with the desktop, but this is neither recommended nor
a suitable solution when starting other applications, IMO. Be aware that
the OP wanted to start the application in a way that its windows are visible
on the currently logged on user. Even starting the application under a
different user account using impersonation won't fix the problem.

 

[Chris Dunaway]

And I recall reading somewhere that in Windows Vista, services will *no
longer* be able to interact with the desktop so if the OP plans to
migrate to Vista when it comes out in January, it would be best to
avoid it.

 

[Herfried K. Wagner [MVP]]

And I recall reading somewhere that in Windows Vista, services will *no
longer* be able to interact with the desktop

That's IIRC true.

 

[CMM]

the OP wanted to start the application in a way that its windows are

visible on the currently logged on user.

I misunderstood the OP in that case. You are right that if his intention is
to (eventually) launch an interactive app, it only makes sense to add his
"service" to "HKLM\...\Run" in the registry rather than have it run as a
service.

 

[CMM]

I highly doubt that. Service accounts may be "hardened" by default in Vista
but I can't see this functionality being completely taken away as it would
break stuff like the secondary logon services and RunAs... unless MS hides
the functionality for themselves which would violate almost every Anti-trust
ruling again it. I'm sure other 3rd party services might possibly break as
well (iPod watcher comes to mind as a possibility).

 

[Herfried K. Wagner [MVP]]

I highly doubt that. Service accounts may be "hardened" by default in Vista
but I can't see this functionality being completely taken away as it would
break stuff like the secondary logon services and RunAs... unless MS hides
the functionality for themselves which would violate almost every
Anti-trust ruling again it. I'm sure other 3rd party services might
possibly break as well (iPod watcher comes to mind as a possibility).

I don't think this change would pose such a big problem. Impersonation will
still be possible in Vista, and services which require user interaction
can/should be split up into the service and a separate application which
runs on the user's desktop once the user logs on and then communicates with
the service. This approach has already been recommended by Microsoft for
some time now:

<URL:http://groups.google.de/group/micro...entwickler.dotnet.csharp/msg/628a30f8d007de44>

 

[dave m]

Thanks for taking the time to reply.! I see the errors of my ways and you
saved me alot of time and frustration!

Dave M