pantagruel
8/5/2008 6:06:00 AM
Ok, long story:
I have a Windows Service that works on my machine, and that runs on
another machine but does not result in the expected output. The
service was installed with Installutil in both locations, as the
service didn't seem to need an installer. The access to the other
machine has been via Remote Desktop, not sure if that can be affecting
some of what happens.
On my machine I do not set it to use local account with enable access
to desktop instead I log in with a particular username. It has a
hardware profile.
This service gets files from either local or remote locations. If I
have it running in the local account I can't get files from remote
locations (not sure why that is, I've read about the issues somewhere
but can't find it now, if someone has a good link to explanation of
issues I would be grateful)
It sends these files to other processes that convert them to other
formats, for example I send a pdf and express that it should be
converted to tif,txt, and word and I give it explicit locations in the
file system to write these files.
On the new machine it does not work (in that conversions do not come
out), but the service runs and reports that the called process did not
result in a conversion.
so looking at my service settings of the new machine I noticed that it
did not have a hardware profile, in fact it doesn't even have the form
field on the Service tab where one normally sees the list of possible
hardware profiles to enable or disable, I was wondering if this could
be causing the problem and exactly how I should solve that - is there
a command line tool to give a hardware profile to a service.
As noted before I run the service with a specific username and
password, these don't have a hardware profile in the service panel.
The username has administrator level permissions however.
For testing of the service I have a process that should always work,
that is to say it just creates a file with the name you want where you
want it. It doesn't work if I use the specific username, but if I
switch to using local account and enabling interact with Desktop it
does, unfortunately local account and interaction with Desktop does
not work with getting the remote files and passing them to the local
processes. The getting of the remote files is done via UNC paths and
not via mapped drives, we don't want to use mapped drives that would
be unacceptable for the application.
Is it possible that the giving of a hardware profile to the faulty
service will cause it to behave well? or should this not have any
effect? If it is a possibility then how to add the hardware profile?
finally, the code I am using to start the process is:
public static int processtarter(string pArgs, string pName)
{
Process nProcess = new Process();
nProcess.StartInfo.LoadUserProfile = true;
nProcess.StartInfo.WindowStyle =
ProcessWindowStyle.Normal;
nProcess.StartInfo.CreateNoWindow = false;
nProcess.StartInfo.UseShellExecute = false;
nProcess.StartInfo.Arguments = pArgs;
nProcess.StartInfo.FileName = pName;
nProcess.Start();
return nProcess.Id;
}
Is there something in the way I am starting the process that causes it
not to output in the situation described, it doesn't seem likely but
just in case. I've tried it with and without LoadUserProfile.
thanks