Windows Service accessing Excel file :(

[emibt08]

Hello fellow programmers.
I am working on a project that is a windows service. It should open an excel file and read it and it worked good on WinXP SP2 w/ Office 2003. Now the customer upgraded to Windows Vista 32-bit w/ Office 2007 and keep getting the following error:
--------------------------------------------------------------------------------------------------
SOURCE: Microsoft Office Excel
MESSAGE: Microsoft Office Excel cannot access the file 'C:\ProgramData \DataProcApplic ation\DataFile. xls'. There are several possible reasons:

• The file name or path does not exist.
• The file is being used by another program.
• The workbook you are trying to save has the same name as a currently open workbook.
--------------------------------------------------------------------------------------------------

i made sure the file exist and is in the correct folder. I gave admin privileges to the file and the folder, i run the service as admin and nothing seems to work. Now, i am sure the problem isn't in the file itself, since it's there. I also save some other binary files in that folder which the service can read/write to. As i assigned admin privileges, i can successfully read/write to a file in another path (not just isolated storage) like c:\somefile.txt .
So, i'm pretty sure the problem is with the excel interop, just cant really get it. This is the function that throws exception:

Workbook wb =
                excelApp.Workbooks.Open(
                    path,
                    2,      // UpdateLinks 1, 2, 3
                    true,   // True to open the workbook in read-only mode.
                    1,      // If Microsoft Excel is opening a text file, this argument specifies the delimiter character, as shown in the following table. If this argument is omitted, the current delimiter is used.
                    null,   // Password string
                    null,   // WriteResPassword string
                    true,   // IgnoreReadOnlyRecommended
                    XlPlatform.xlWindows,   // Origin
                    ";",    // Delimiter
                    false,  // Editable for add ins?
                    false,  // Notify
                    1,      // Converter ???
                    false,  // AddToMru
                    true,   // Local
                    Microsoft.Office.Interop.Excel.XlCorruptLoad.xlNormalLoad); // CorruptLoad
 

I've been trying to solve this all day long and trying to find a solution online with no luck. I saw posts with the same question though, but no answer. So, if anyone have a solution for this, please help me out.

Any help is greatly appreciated.
Cheers

[balabaster]

I think the issue is likely that you are trying to open an Excel 2007 workbook using an older workbook object - i.e. from Excel 2003. It's not possible to open an xlsx file using the older Excel objects. You need to update your application references to point to the new Excel 2007 objects. In order to do this, the application will need to be compiled on a machine that either has Excel 2007 installed or has the correct DLL loaded onto it...

[emibt08]

I think the issue is likely that you are trying to open an Excel 2007 workbook using an older workbook object - i.e. from Excel 2003. It's not possible to open an xlsx file using the older Excel objects. You need to update your application references to point to the new Excel 2007 objects. In order to do this, the application will need to be compiled on a machine that either has Excel 2007 installed or has the correct DLL loaded onto it...

Thanks for the reply balabaster, but that is not the problem. If you see the code, you can see that i am opening an excel 2003 workbook (xls file). However, i have updated the references to interop with Excel 2007, as i have Office 2007. Before the error started to show up, the service was running on Windows XP SP2 with Office 2003 with no problems and later on Windows XP SP3 with Office 2007. There were no problems with those systems. Once the OS was changed to Windows Vista 32-bit with Office 2007 the error came up. The references have been updated ever since the service was deployed at a system with Office 2007 and was working flawlessly. So, my guess is that it has something to do with Vista. However, as i said on internet i see the same question on many sites and forums. But i see no answer though :(

[balabaster]

Hmm... with this service, when you upgraded to Vista - did you make sure the service itself still has permission to interact with the desktop?

[emibt08]

Hmm... with this service, when you upgraded to Vista - did you make sure the service itself still has permission to interact with the desktop?

Thanks for the reply. But again no luck. I haven't set that though and i did with checking that options in the Administration tools -> Services before messing with the registry and ServiceInstalle r options. But i don't think it would help anyway since it's different in Vista. But i tried anyways. Then i created a console application that would do all of the Excel-related work. I called that app from another console and GUI app to check it out and everything if fine. But once i opened it from the service... again no luck. The same error message:

Exception: Microsoft Office Excel cannot access the file 'C:\TestExcelFi les\TestBook1.x ls'. There are several possible reasons:

• The file name or path does not exist.
• The file is being used by another program.
• The workbook you are trying to save has the same name as a currently open workbook.

Then i called that console app with CreateProcessAs User to elevate some privileges and impersonate and again the same error (although i got a console window this time, which i don't need anyway).
So, i've been working on this issue for about 2-h straight and i'll keep up until it's solved, it just drives me nuts.

Please, if anyone has any suggestion about this post me.

[davidnelson]

Any resolution on this? I am having the same problem.

[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.

[PRR]

Try the following
1. Install your service using latest version of installutil..." \WINDOWS\Micros oft.NET\Framewo rk\version"
2. Try installing the following ....Download details: 2007 Microsoft Office System Update: Redistributable Primary Interop Assemblies
3. Check on "MasterEvil Ace" tip .. "my research shows that automation is an issue with Windows Server 2008, specifically the 64-bit version"
4. Finally ...Office automation is not recommended.... .MS Office requires active user and start as interactive process... Also see if the office components are "initialize d" when you are tryin to automate opening excel file... There may be some dependency.... Make sure some user has already logged in?
Also check on vista service account : session 0 thing....from what i know vista services run under Session 0.... session 0 does not have access to graphics or UI....
Also try explicitly giving file system rights n other rights to your service....

Let us know if you find the solution .....

[davidnelson]

vote down


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.

[emibt08]

I kind of get a little frustrated with this kind of problem while working on a solution. Besides, there was not really any pointer to the right direction, and i needed the solution fast. So, i still believe it's a Vista issue, just didn't have enough time to spend on this issue.
However, this is how i solved it and made it work. I made another small application which would do all Office (read Excel) related stuff. Then, i spawn that application in the isolated storage of my service and communicate to it through named pipes (although i could use other methods of IPC). And then i just pass parameters to it and get results from it. So, the problem is definitely related to the service, not the user not having enough permissions etc. And since the service is starting/stopping the other application, it runs under the same user account as the service, just it's not a service. However, the issue might be due to the fact pointed out by DeepBlue, that the services in Vista run under session 0.
However, i don't exclude the possibility that it might be another M$ bug. Just need some time to do more research on the subject, but with the everchanging security models in Windows i don't even know if it's worth it. And then, is it gonna run on Windows 7, or maybe when it comes out and my customers upgrade will call to let me know that it again stopped working. It's just a real mess. Sometimes i wish that the Raymond Chen camp have won the battle inside M$. At least we would have the backward compatibility.

Cheers