Well the first thing to note, is that office interop is not supported server side by Microsoft, due to both licensing and stability/reliability issues:
Microsoft does not currently recommend, and does not support,
Automation of Microsoft Office applications from any unattended,
non-interactive client application or component (including ASP,
ASP.NET, DCOM, and NT Services), because Office may exhibit unstable
behavior and/or deadlock when Office is run in this environment.
Still, many people do this/try to do this, and run into similar problems as you did. Generally this appears to be caused by permission issues (security context and the DCOM security configuration). For which different potential solutions have been described, such as
How to make IIS7 play nice with Office Interop With a 2 different solutions, one of which is mentioned several times elsewhere:
- Open Windows Explorer
- Depending on whether you installed a 32bit or
64bit version of office you will need to do one (or both) of the
following:
- 32bit Office installation: Navigate to
C:\Windows\System32\config\systemprofile
- 64bit Office installation:
- Navigate to C:\Windows\SysWOW64\config\systemprofile
- Verify the folder
"Desktop" exists (create it if it's not there)
- Right click > Properties
- On the security tab: Add the account under which the site
is running (eg: Network Service) with default permissions (Read &
execute; List folder contents; Read)
RPC failure opening an excel document. Listing the following solution:
Type Dcomcnfg.exe in Run which opens the dcomconfig utility.
In the dcomconfig utility,
go to Component Services --> Computers --> My Computer --> DCom Config
--> Microsoft Excel Application (and Powerpoint)
Right click it and go to properties. Go to security tab. Under
Security
1) Launch & Activation Permissions --> Choose customise and click
Edit. Add User Network Service and check everything under Allow for
it.
2) Do the same for Access Permissions and Configuration Permissions.
Then click Apply and close everything.
Another one using Windows Server 2003, with a different solution
It turns out that there was some kind of permission that the COM
Object needed. Setting the AppPool (for the site) on the Win2003
server to "SYSTEM" fixed the problem. For some reasion (by Default)
the ASPNET account has permission to whatever the COM object was
trying to access.
Perhaps one of these solutions will work for you.
The reason it sometimes works for you and not other times, may be related to the contents of the specific excel file, e.g. whether it contains any VBA scripts or references any (specific) modules. So that is something you should look into.