Launching and Monitoring Executables

[Water Cooler v2]

I have a Windows Service I am writing in C# and a set of, let us say
three, other executables written in C# (mostly console applications).

I want that the Windows Service must do so every few seconds:

Check to see if each of the other executables are running or not. If
they are not running, it should load them.

For this purpose, I am planning the following:

I'll take a timer object and set it to an appropriate interval. In the
timer's timer/elapsed event, I will check if the other executables are
running or not. For checking that, I can use either of the following
approaches:

1. Use OpenProcess/CreateProcess with LP_SECURITY_ATTRIBUTES set to
NULL and with PROCESS_INFO. This will give me everything I need to
know, like, the threadID, the processID, in order to determine if the
process is running or not. The processID will be constant throughout
the life of each process. This will help me check if a process is
running or not.

2. ShellExecute/ShellExecuteEx - I am not sure if this is the right
approach. If I am assuming correctly, ShellExecuteEx only sets
GetLastError and returns a bool/int indicating success or failure. This
may not be the approach I might want to take as this will not give me
any information as to the status of the executable I have launched.
Besides, even semantically, this method might not be suited for the
purpose I have at hand, which is not to "launch documents in their
associated application."

3. Create a new app domain for each process I want to launch, add all
the appDomains to the same process, call ExecuteAssembly the
Application Domain for each executable I want to launch.

However, with the third approach, my knowledge of application domains
is still limited. I have a couple of questions in this regard.

a. Given that all this checking will be performed by a Windows Service,
which is not really a Win32 process, like ordinary Windows PE files or
executables, whether managed or unmanaged, what are the implications of
creating appdomains from within a Windows service? Is it an alright
thing to do to launch other Win32 processes from within a Windows
service?

b. Would it be possible for me to monitor the lifetime of an executable
which I execute inside an application domain? Remember that my main
purpose is to monitor in a timer if an application is running or not,
and if not, to launch it again.

c. What is the difference between System.AppDomain.Load() and
System.AppDomain.ExecuteAssembly()? Sorry, I am being lazy here, but it
is easier to ask a forum. I'm on my way to the MSDN, anyway. But kindly
oblige.


Thanks very much for your thoughts.

 

[Rob R. Ainscough]

What I've discovered down this long ugly road of Windows Services under .NET
using Diagnostic.Process approach.

1. Interact with Desktop is required for any shelled process with an
interface (even the most simple interfaces)
2. You can only go one level deep on the shell under a service and retain
"Interact with Desktop" -- not inherited if you run a service that shells to
another program which in tern shells to another program -- you'll be left in
limbo non UI state.
3. Many Windows programs/tools don't work reliably when shelled from a
service (i.e. MSIEXEC for example)
4. Diagnostic.Process is the better way to go over WMI and/or Shell, you
can track, wait, timeout etc.
5. just avoid using a service that has an interface or anything that shells
that might have an interface -- just too many problems with the bubble gum
nature of the OS that could send you into a spiral of R&D as to why
something isn't working as expected
6. Not sure Diagnostic.Process can report back on processes that are
hidden.

Since you might be launching documents and/or their associate apps, you
really are better off NOT using a service to do this since the OS is
severely "lacking" in this area. What you might want to consider is
standard windows app with a timer that installs in the Startup -- you'll
have to workout the details on Starting/Stoping and if the user trys to
termiante the app (this is why we like to code for a service, but
Microsoft's security problems and poor assumptions have left us with few
options).

IMHO, All services should be permitted to have an interface that works
reliably under all contexts because even if a user has not logged in, there
is STILL an interface. I'm guessing Microsoft wanted to go this restricted
route simply because it is a easy solution for them to make a mass blanket
restriction even if not conceptually valid. Frustrating isn't it -- more
half-ass implementations from M$

Rob.