Cannot access excel file

Question

I'm developing a windows service, generating a report. This report has a template. This template is prepared in an excel file. This file is copied to the output folder.

While developing I launched the service like a console application and had no problems accessing this file.

Then I prepared a service installer. The service is installed under Local System account. So this excel template file is marked as content and copied to the installation directory together with the executable as well.

But when the service is launched excel appears to have no access to this file. The service is installed to c:\Program Files (x86)\Our Company\Service Name\. The target OS is Windows Server 2008. While testing I use Windows 7 and run into the same issue.

I use the following code to access excel.

using Excel = Microsoft.Office.Interop.Excel;    
//...
Excel.Application xlApp = new Microsoft.Office.Interop.Excel.Application();
//the following line throws an exception
Excel.Workbook xlWorkBook = xlApp.Workbooks.Open(@"path"); 

I also tried to copy the excel template file to some temporary directory (where the service has the right to write - this is tested) and tryed to open it from there, but to no success (while this variant works good in a console application as well).

The error message sais:

Microsoft Office Excel cannot access the file /path/. There are several possible reasons:

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

How can I make the windows service access this excel template file? Or is there another alternative?

Answer 1

I just faced the same problem.

I have made a .bat file where I called the .exe file.

finally, I called the .bat file from the task scheduler actions.

It just works fine.

Answer 2

To safety run Office applications (Excel and others) under user service with Local system account you must know two important things: 1) In Windows Server 2008/2008 R2 you must manually create two folders: C:\Windows\system32\config\systemprofile\desktop
C:\Windows\SysWow64\config\systemprofile\desktop (for x64 version only) Without this folders you cannot correct run office Applications from Local SystemAccount

2) If you service is configured without desktop interaction then in the first time launched office application (Excel for example) freeze on user credentials dialog - you cannot see this window in this mode - to resolve this enable desctop interacting, switch to office window after you service run it and manually enter credeentials.

Other information there(use google translater to read).

Answer 3

There is a detailed MS knowledge base article titled Considerations for server-side Automation of Office. Some key excerpts:

• User Identity: Office applications assume a user identity when the applications are run, even when Automation starts the applications. The applications try to initialize toolbars, menus, options, printers, and some add-ins based on settings in the user registry hive for the user who launches the application. Many services run under accounts that have no user profiles (such as the SYSTEM account or the IWAM_[servername] accounts). Therefore, Office may not initialize correctly on startup. In this situation, Office returns an error on the CreateObject function or the CoCreateInstance function. Even if the Office application can be started, other functions may not work correctly if no user profile exists.

• Interactivity with the desktop: Office applications assume that they are being run under an interactive desktop. In some circumstances, applications may need to be made visible for certain Automation functions to work correctly. If an unexpected error occurs, or if an unspecified parameter is needed to complete a function, Office is designed to prompt the user with a modal dialog box that asks the user what the user wants to do. A modal dialog box on a non-interactive desktop cannot be dismissed. Therefore, that thread stops responding (hangs) indefinitely. Although certain coding practices can help reduce the likelihood of this issue, these practices cannot prevent the issue entirely. This fact alone makes running Office Applications from a server-side environment risky and unsupported.

Obviously, as has been pointed out in the comments, using the SYSTEM account is a mistake. You would need to run the service under an account that has a user profile.

But even when you fix that, the other bullet point will kill you. Office applications do indeed assume they are running under an interactive desktop. My advice is to abandon attempting to automate Office from a service. Use a library like Aspose instead. Or run the process on an interactive desktop.