Script Host Client launched from Windows Service

[Guest]

Hello,

I have a client/server application that launches a Script Host application
from a Windows Service. The Script Host application launches Excel and opens
an xls file for processing.

This works on Windows 2000 and Windows XP, but on Vista we get an error from
Excel saying "cannot access the file: C:\foo.xls, there are a number of
possible reasons". The Script Host application works fine on Vista by
itself, but when launched from a Windows Service it does not have permission
to read the xls file.

Does anyone have any ideas as to what the problem may be? What extra things
do I need to do on Vista to get my Windows 2000/XP application to work?

Many thanks,
DavidRF

 

[Alun Jones]

I have a client/server application that launches a Script Host application
from a Windows Service. The Script Host application launches Excel and
opens
an xls file for processing.

This works on Windows 2000 and Windows XP, but on Vista we get an error
from
Excel saying "cannot access the file: C:\foo.xls, there are a number of
possible reasons". The Script Host application works fine on Vista by
itself, but when launched from a Windows Service it does not have
permission
to read the xls file.

Does anyone have any ideas as to what the problem may be? What extra
things
do I need to do on Vista to get my Windows 2000/XP application to work?

I think your problem is most likely to be handled by the Microsoft Office
team by telling you that Office Automation was never designed to be run from
service applications, and must be run in an interactive session.

You may have gotten away with it in the past, simply because services shared
a lot with one of the interactive sessions - I think you will probably have
to find some other way to create your files than to use native Office
Automation.

Alun.
~~~~

 

[Guest]

I think your problem is most likely to be handled by the Microsoft Office
team by telling you that Office Automation was never designed to be run from
service applications, and must be run in an interactive session.

You may have gotten away with it in the past, simply because services shared
a lot with one of the interactive sessions - I think you will probably have
to find some other way to create your files than to use native Office
Automation.

Thanks for the reply.

Just to clarify. The Windows Service process itself does not run
ScriptHost. The Windows Service spawns an independent ScriptHost executable
which reads the Excel file, processes it internally, and writes one or more
tab-delimited files which can be imported natively into our main application.
Its our way of integrated our application with Microsoft Excel, though we
are encountering the same ScriptHost/Automation problem with other programs
as well.

Has anyone run into the same problem? Is there some setting, flag, or
function argument than can be set so that Script Host processes launched by a
Windows Service can open files?

Thanks,
-DavidRF

 

[Alun Jones]

Just to clarify. The Windows Service process itself does not run
ScriptHost. The Windows Service spawns an independent ScriptHost
executable
which reads the Excel file, processes it internally, and writes one or
more
tab-delimited files which can be imported natively into our main
application.

And ... the ScriptHost executable is running in _what_ session? The same
session as the service, with no access to an interactive user or a desktop.
Microsoft has repeatedly dictated that they do not support Office Automation
in anything other than an interactive desktop.

Its our way of integrated our application with Microsoft Excel, though we
are encountering the same ScriptHost/Automation problem with other
programs
as well.

Has anyone run into the same problem? Is there some setting, flag, or
function argument than can be set so that Script Host processes launched
by a
Windows Service can open files?

Every time I've tried to do Office Automation from a service in XP, it's
worked... more or less, most of the time. Every time I've asked Microsoft
for help, they've said "it was never meant to run from a service, that's
unsupported", so I've done it some other way.

That's not to say that there isn't a solution out there - just that I don't
think you'll get any officially sanctioned solutions, and unofficial
solutions have a habit of being wiped out by the next patch, the next
service pack, or the next release, so I avoid them as much as possible.

Alun.
~~~~