C#-SERVICE: ...Excel.Application.Workbooks.Open fails when called from a Service

[robertgregson]

Using C#, .NET3.5, Visual Studio 2008 and WCF on Windows VISTA SP1, I have written a service, service host (as a C# console application) and a client.

The service uses Microsoft.Offic e.Interop.Excel .Application to access an Excel file on the local hard drive, opens it (using Application.Wor kbooks.Open), reads out some data and the provides said data to the client.

Everything works perfectly when the Service Host is a C# console application. That is, the client invokes the call, the service host duly invokes the service, which in turn reads the Excel file and returns the expected data.

However, when the Service is wrapped as a Windows Service (so all the code is identical), Application.Wor kbooks.Open fails to open the file; debugging the service indicates that Excel returns an error "Cannot access the file...".

My original guess was that the Windows service was running in a lower trust situation. However, I have tried running the service under my own administrator account, allowed interaction with the desktop, granted the Service Full Trust (from VS 2008 and reinstalled the service), added a strong name key and anything else I can think of. But to no avail.

I even added code to the Service that opens a binary .dat file from the hard drive (not in Isolated Storage) and reads in some arbitrary values - this works fine under the console application and Windows Service, thereby proving the Windows Service has elevated trust.

When running with access to the desktop, I also set the Application.vis ible attribute to true, so I could interact with Excel and try to figure out what's going on. Sure enough, under the Windows Service, the Excel application starts, but all I can do is create a New workbook and type in it. The application won't let me Save it nor Open an existing workbook (hence, the Application.Wor kbooks.Open method fails from within the Windows Service).

In conclusion, the Windows Service itself clearly has elevated trust, as it can open, read, write and save to a local file on the hard drive (not in Isolated Storage). However, when the Windows Service calls Application.Wor kbooks.Open to interact with Excel, said COM object does not have the ability to do any file operations.

Guessing wildy, I imagine that the COM object that Excel.Applicati on uses to interact with Excel is perhaps under-the-hood being run in a separate thread that has lower priority.

Essentially I'm stuck at this point and would appreciate any guidance that is on offer.

Thanks in advance,

Robert

[sachit1979]

Me also facing the same issue. Pls reply if anybody has got any solution for it.

[davidnelson]

Robert,

Did you ever figure this issue out? I am having the same problem with Visio

David

[MasterEvilAce]

Wondering if you have solved this issue yet.

Unsure of vista specifically... but my research shows that automation is an issue with Windows Server 2008, specifically the 64-bit version.
The 32bit version works, as well as windows 2003 32/64bit.
I'm unsure as to whether it affects only SERVICES or APPLICATION automation as well..
We use a service for our tasks.

Recently we have run into this problem, and it's pretty important. We do some high dollar work using excel automation, and have recently obtained a new system running windows server 2008, just to find out there seems to be a bug/issue that prevents our application from doing its core work.
We get the same issue... excel loads, you go to open a workbook, and it errors out. Would appear to be a security / permissions bug, but have tried running under numerous accounts that have access to the file, and nothing.

If you have found a solution please let me know.

[Frinavale]

I don't know if this will help but have you seen this article on how to create a service account?

[davidnelson]

I have "kind of" solved this problem. If you use "dcomcnfg" to change the account to launch the excel application to a user account or "interactiv e user" the excel launched from the service starts in that account and it now can access the file system.

The problem is this is a global setting. If you use:
* "this User": then excel ALWAYS opens with that user AND always opens up with no UI in session 0, even for interactive use of excel. IE its always invisible.
* "Interactiv e User": Now excel always launches in the interactive user accout which I don't think will work for a service which will launch on bootup with NO interactive user.

There must be some security setting on this. I hope others have other ideas.

[rusidoitu4]

Having the same issue. If the code is run from a desktop app it works fine. It can't open the file in the windows service. Procmon doesn't show any errors or anything. I've tinkered with the Microsoft Excel Application DCOM permissions and identity and nothing has worked (or changed). The OS is Server 2008 64 bit. Excel is 2007. I've also tinkered with all the params to the Workbooks.Open call to no avail.

This is a showstopper for us. Running out of ideas.

Rus

[downsie]

Automation fails at the DCOM level.

To resolve this issue follow these steps
1. Login to the server as a administrator.
2. Go to "Start" -> "Run" and enter "taskmgr"
3. Go to the process tab in task manager and check "Show Processes from all users"
4. If there are any "Excel.exe" entries on the list, right click on the entry and select "End Process"
5. Close task manager.
6. Go to "Start" -> "Run" and enter "services.m sc"
7. Stop the service automating Excel if it is running.
8. Go to "Start" -> "Run" and enter "dcomcnfg"
9. This will bring up the component services window, expand out "Console Root" -> "Computers" -> "DCOM Config"
10. Find "Microsoft Excel Application" in the list of components.
11. Right click on the entry and select "Properties "
12. Go to the "Identity" tab on the properties dialog.
13. Select "The interactive user."
14. Click the "OK" button.
15. Switch to the services console
16. Start the service automating Excel
17. Test you application again.

[rusidoitu4]

I switched to OLEDB to get the job done. I extract the Excel contents to a tabbed file per worksheet then read those files. Here are the connection strings for any interested-

                switch ( Path.GetExtension( Filename ).ToLower() ) {
                    case ".xlsx":
                        connString =
                            "Provider=Microsoft.ACE.OLEDB.12.0;" +
                            "Data Source=" + Filename + ";" +
                            "Extended Properties=\"Excel 12.0 Xml;HDR=NO;IMEX=1\"";
                        break;
                    case ".xlsm":
                        connString =
                            "Provider=Microsoft.ACE.OLEDB.12.0;" +
                            "Data Source=" + Filename + ";" +
                            "Extended Properties=\"Excel 12.0 Macro;HDR=NO;IMEX=1\"";
                        break;
                    default:
                        // assume traditional .xls
                        connString =
                            "Provider=Microsoft.Jet.OLEDB.4.0;" +
                            "Data Source=" + Filename + ";" +
                            "Extended Properties=\"Excel 8.0;HDR=NO;IMEX=1\"";
                        break;
                }

[sfun28]

Folks - Having the same problem with Windows 2008 64-bit. Exactly as others have described. Setting to Interactive User continues to load Excel in Session 0 and I have the same problems opening/saving workbooks.

Has anyone figured out a solution to this? Is this a bug resolved in the new 2008 SP?

[downsie]

Trust is an issue.. :)

Hi Guys,
It sounds like your automation is having permission issues in accessing local resources, there are two possible issue here;

1. Set the service to run as your admin user, rather than network services. Check 'Allow service to interact' option.

2. See my post from the 24th Feb, at step 14, instead of setting the automation (DCOM) to run as an interactive user, set it to run as the same user as the service.

I have also found that Excel/Visio likes you to have a printer setup for the user that is automating. Even if the printer is just a dummy printer, so long as the app can determine a default paper size.

[gira]

some bad news

Guys I belive this problem is more complex than simple changing the DCOM identity and/or service credentials. This works fine on pre-Vista/Windows2008 but not on Vista and I belive Windows2008 server since they probably share the same architectural concepts. The issue is within the new OS design: the services are now running in complete isolation (session 0) by the interactive desktop (session1), created by the first log-in user. Please have a look at:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257757#kb2

http://blogs.msdn.com/winsdk/archive/2009/07/14/launching-an-interactive-process-from-windows-service-in-windows-vista-and-later.aspx

http://www.codeproject.com/KB/vista-security/VistaSessionsC_.aspx?msg=2065057

Microsoft discourages using Office applications on the server side, and encourages the using of Open Ofiicex Xml model. I've tried to start an console application using the copeproject sample, with eleveted privileges from within the service, with no luck though...I'll try do something different ( some variation on the same ideea) see if I go somewhere...I'l et you know.
Thx

[gira]

Finaly...

Thanks to H Ogawa...here is the solution...
This solution is ...

・Windows 2008 Server x64

Please make this folder.

C:\Windows\SysW OW64\config\sys temprofile\Desk top

・Windows 2008 Server x86

Please make this folder.

C:\Windows\Syst em32\config\sys temprofile\Desk top

...instead of dcomcnfg.exe.

This operation took away office automation problems in my system.

A Desktop folder seems to be necessary in the systemprofile folder to open file by Excel.

It disappears from Windows2008, Windows2003 had the folder,
and I think it cause this error.

I've tested and works fine...I mean tested from within a Windows service...
Here's the link...

http://social.msdn.microsoft.com/Forums/en-US/innovateonoffice/thread/b81a3c4e-62db-488b-af06-44421818ef91

[Johara]

Hi i have done with all these options but still am getting the same error
Is there any other alternative or solutions available.
I'm using windows 7, vs2010, sharepoint 2010 and excel 2010. Is there any issues with this.?
Since in some sites it has been mentioned that it works finer with xp and windows 2003 server. I have tried in windows server 2008 64 bit also. It does not work there also.
Please look into this and provide me help.
Thank you in advance.!

[Jimbo Smithy]

Messaging Admin

Gira and Ogawa, you saved the day! All I did was create that Desktop folder in a Win2008R2 and my PowerShell service which opens and exports Excel files works perfectly now.