422,949 Members | 1,000 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 422,949 IT Pros & Developers. It's quick & easy.

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

P: 1
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.Office.Interop.Excel.Application to access an Excel file on the local hard drive, opens it (using Application.Workbooks.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.Workbooks.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.visible 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.Workbooks.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.Workbooks.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.Application 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
Jul 9 '08 #1
Share this Question
Share on Google+
22 Replies


P: 1
Me also facing the same issue. Pls reply if anybody has got any solution for it.
Sep 1 '08 #2

P: 4
Robert,

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

David
Jan 8 '09 #3

P: 2
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.
Jan 9 '09 #4

Frinavale
Expert Mod 5K+
P: 9,731
I don't know if this will help but have you seen this article on how to create a service account?
Jan 9 '09 #5

P: 4
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 "interactive 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.
* "Interactive 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.
Jan 9 '09 #6

P: 2
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
Jan 15 '09 #7

P: 2
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.msc"
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.
Feb 24 '09 #8

P: 2
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-
Expand|Select|Wrap|Line Numbers
  1.                 switch ( Path.GetExtension( Filename ).ToLower() ) {
  2.                     case ".xlsx":
  3.                         connString =
  4.                             "Provider=Microsoft.ACE.OLEDB.12.0;" +
  5.                             "Data Source=" + Filename + ";" +
  6.                             "Extended Properties=\"Excel 12.0 Xml;HDR=NO;IMEX=1\"";
  7.                         break;
  8.                     case ".xlsm":
  9.                         connString =
  10.                             "Provider=Microsoft.ACE.OLEDB.12.0;" +
  11.                             "Data Source=" + Filename + ";" +
  12.                             "Extended Properties=\"Excel 12.0 Macro;HDR=NO;IMEX=1\"";
  13.                         break;
  14.                     default:
  15.                         // assume traditional .xls
  16.                         connString =
  17.                             "Provider=Microsoft.Jet.OLEDB.4.0;" +
  18.                             "Data Source=" + Filename + ";" +
  19.                             "Extended Properties=\"Excel 8.0;HDR=NO;IMEX=1\"";
  20.                         break;
  21.                 }
Feb 24 '09 #9

P: 1
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?
Jul 1 '09 #10

P: 2
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.
Jul 20 '09 #11

P: 2
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...US;q257757#kb2
http://blogs.msdn.com/winsdk/archive...and-later.aspx
http://www.codeproject.com/KB/vista-...px?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'let you know.
Thx
Sep 28 '09 #12

P: 2
Thanks to H Ogawa...here is the solution...
This solution is ...

・Windows 2008 Server x64

Please make this folder.

C:\Windows\SysWOW64\config\systemprofile\Desktop

・Windows 2008 Server x86

Please make this folder.

C:\Windows\System32\config\systemprofile\Desktop

...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/For...6-44421818ef91
Sep 28 '09 #13

P: 1
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.!
Sep 22 '10 #14

P: n/a
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.
Oct 1 '10 #15

P: n/a
Thanks Gira..u r rockstar..!!!!!!
Oct 8 '10 #16

P: n/a
Thanks Downsie. I've been stuck on this for months. I just keep going back to it now and again without success.
Oct 20 '10 #17

P: 1
I have Win 7 ,32-bit on my computer-and do not understand how is placeing some folder on some location answer on my problem.Do i have to place my excell on that location->>??
Feb 3 '12 #18

P: 1
@downsie
thank very much for everything. your post helped me a lot. my problem was resolved
Apr 11 '12 #19

P: 1
Gira, I know that it's been more than 3 years, but anyway thank you so much! You saved the day :) It was such an easy fix for a unsolvable looking problem!
Apr 5 '13 #20

P: 1
@downsie
It works!!! Thank you!!!
Apr 21 '13 #21

P: 1
@downsie, thank you!)
But I had to switch user to mentioned user and use my admin account(the service is working under my admin account too). In case of interactive user it didn't work.
Oct 14 '13 #22

P: 1
I'm necroing this thread because this seemed like such a unique and rare thing that i was trying to do that there wouldn't be any help to do it. I thought, "Really, adding a folder will fix this annoying issue? Fine, i might as well try, i've tried everything else." Then it worked and i cried. Yes, i made an account just to express to Gira my appreciation for his solution almost 10 years ago. THANK YOU SIR's, for all your help!
May 11 '18 #23

Post your reply

Sign in to post your reply or Sign up for a free account.