Starting a windows app from a service

[Steve Long]

Hello,
I hope this question isn't too fundamental. I have a feeling it is. I'm
trying to start a winform app from a windows service written in C#. I
created a class and used it from a windowsforms application and all was
well. But when I try to use the class in the OnStart method of a windows
service, the process I'm trying to start runs but the window never shows up.
Like I said, this may be fundamentally impossible/illogical to do but here's
the basic code I'm using:

public class AppServer
{

public void StartService()
{
string path;
string app;
ProcessStartInfo psi;

string[] settings =
System.Configuration.ConfigurationSettings.AppSettings.GetValues("app");
for (int i = 0; i <= settings.GetUpperBound(0); i++)
{
path = settings.Substring(0, settings.LastIndexOf("\\"));
app = settings.Substring(settings.LastIndexOf("\\") + 1);
Directory.SetCurrentDirectory(path);
psi = new ProcessStartInfo(app);
psi.CreateNoWindow = false;
psi.WindowStyle = ProcessWindowStyle.Normal;
psi.WorkingDirectory = path;
Process.Start(psi);
}
}
}

Any comments much appreciated.

Thanks
Steve

 

[Nicholas Paldino [.NET/C# MVP]]

Steve,

You can do it, but I would recommend against it. You would have to go
to the properties for the service and check "allow service to interact with
the desktop". However, I strongly recommend against this. If you need to
communicate to a service, then have a separate application which uses a
technology like remoting to get information from it.

Hope this helps.

 

[Chris Dunaway]

Firstly, check that the service is set to allow interaction with the
desktop. You can right click the service in the SCM and check it that
way.

Secondly, since the service is probably loading under the LocalSystem
account, it may not have the necessary priveleges to run the app. You
might try having the service start up as a different user.
Hope this gives you some ideas.

 

[Willy Denoyette [MVP]]

Hello,
I hope this question isn't too fundamental. I have a feeling it is. I'm
trying to start a winform app from a windows service written in C#. I
created a class and used it from a windowsforms application and all was
well. But when I try to use the class in the OnStart method of a windows
service, the process I'm trying to start runs but the window never shows
up.
Like I said, this may be fundamentally impossible/illogical to do but
here's
the basic code I'm using:

public class AppServer
{

public void StartService()
{
string path;
string app;
ProcessStartInfo psi;

string[] settings =
System.Configuration.ConfigurationSettings.AppSettings.GetValues("app");
for (int i = 0; i <= settings.GetUpperBound(0); i++)
{
path = settings.Substring(0, settings.LastIndexOf("\\"));
app = settings.Substring(settings.LastIndexOf("\\") + 1);
Directory.SetCurrentDirectory(path);
psi = new ProcessStartInfo(app);
psi.CreateNoWindow = false;
psi.WindowStyle = ProcessWindowStyle.Normal;
psi.WorkingDirectory = path;
Process.Start(psi);
}
}
}

Any comments much appreciated.

Thanks
Steve

You shouldn't launch interactive processes from Windows Services, they are
designed to run even when there is no interactive session available.
The reason is simple, each service runs in an invisible secured desktop
environment (called a Winstation), programs launched from this share the
same desktop environment, so their UI is invisible to the user.
Note that you can flip the "Enable service to interact with desktop" service
attribute, but this should only be considered as a debugging aid .

Willy.

 

[Steve Long]

Very good feedback everybody. You might be right that it would be a bad idea
since the primary reason for me doing this is so that the service can launch
a desktop app without the server having to be logged into by someone. The
app in question, is by design, a windowed app and therefore can not really
run as a service. It does however, serve up some intensive data and it takes
a several seconds to load the app, which is why it must be running all the
time. Can't really add the load up time to the time it takes to perform the
spatial queries. Others communicate with this application via a .aspx page
that I set up which in turn communicates with the desktop app via .NET
remoting.
So, let's say I check the option to allow the service to interact with the
desktop, allowing this app to be started up without actually logging into
the server. What are the pitfalls with this course of action?

Steve

 

[Willy Denoyette [MVP]]

Very good feedback everybody. You might be right that it would be a bad
idea
since the primary reason for me doing this is so that the service can
launch
a desktop app without the server having to be logged into by someone. The
app in question, is by design, a windowed app and therefore can not really
run as a service. It does however, serve up some intensive data and it
takes
a several seconds to load the app, which is why it must be running all the
time. Can't really add the load up time to the time it takes to perform
the
spatial queries. Others communicate with this application via a .aspx page
that I set up which in turn communicates with the desktop app via .NET
remoting.
So, let's say I check the option to allow the service to interact with the
desktop, allowing this app to be started up without actually logging into
the server. What are the pitfalls with this course of action?

Steve

If it's designed to be a windowed application, it expects some form of human
interaction.
That means it is free to show dialog (modal as well a modeless) boxes (in
normal cases or in case of failures), dialog boxes that don't get closed as
there is no-one available to click a button or press a key.
It also expects the user profile to be available and accessible, which is
not the case as it runs in the context of a non interactive user
(LocalSystem).
It also expect to have access to the HKCU registry hive, which again is not
the case as the hive is not loaded.
These are some of the potential problems, but there could be more, for
instance what resources (local and remote) is the application (running as
LocalSystem) required to have access to.

Willy.