Vista, Office Interop not working

Question

Does anyone know how to get the MS Office 2007 .NET C# Interop libraries to work with Vista?

I have a .NET C# application that I have setup to run as a Windows service. This program will open up a Word or Excel template depending on the situation and modify its contents and then save the document back out. All of this worked great when I was doing it on a Windows Server 2003 or XP machine using Office 2007. When I moved everything to a Server 2008 box, everything quit working. In Excel for example, I get a COM exception telling me that the Excel file cannot be opened when the file is clearly there and I can open it just fine when doing it manually. The windows service is running under the same user account that I log into the machine with and that account is an Administrator.

Does anyone have any idea what to do?

Answer 1

Do you have the primary interop assemblies installed on the server? These are usually located in the GAC and not included in the bin directory when you build your program, so they would need to be installed locally on the server.

Answer 2

I did find an interesting article from Microsoft basically saying don't do Office automation.

Answer 3

Get the installables from http://www.microsoft.com/downloads/details.aspx?FamilyID=59daebaa-bed4-4282-a28c-b864d8bfa513&displaylang=en

install it on your system and refer excel dll in your solution and hopefully it should work.

Answer 4

This is just a guess, but it might be UAC. I know that privileged (admin) applications and user applications cannot send messages to each other or communicate in any way. Your service is running as an administrator, but your desktop is running as a regular user under UAC even though they are the same user. I also expect that Office has started up (pre-loaded) parts of itself on startup and that would be running as a regular user.

Try turning off UAC and see if that helps. If so, at least you know what it is.

Answer 5

Do you leave an account logged on to the machine? Office is not a server-side app, and you will get random errors if you try to launch any of the executables without a desktop context.

Answer 6

Something to remember about Office. Its x86 only, so if your creating an application in x64, you will not be able to access the Office underlying COM objects. You will need to compile your application in x86, then it would work.

You can do that by going into the properties of your project, and selecting x86 under the build tab in visual studio.

This is all assuming that your app is being developed/run in a x64 enviroment that is.

Answer 7

You should really avoiding running the Office clients as server side apps. Consider using xml as file format (xlsx for Office 2007, or using the Excel workbook xsd for (somewhat) older versions.) Then you would be freed from using the Excel API on the server.

Answer 8

On Vista and Windows Server 2008, services run in something called Session0. Before Vista, regular programs would run in Session0 alongside services.

This means that Session0 has become a desktop-less wasteland where your services can't even access explorer.exe. I'm pretty sure the problem is that Office applications are expecting to be able to access a few components that are normally on the desktop.

Since Excel, Word, etc. are only supported on a desktop-ed session, you only have a few choices:

1. Set the Desktop checkbox in the LogOn tab of your Service's properties and pray that it appeases the Office gods. (It probably wont.)
   • After trying 1, go through your code and try and remove/work around anything that causes it to crash.
2. Use remoting/WCF to make a server that performs the interop work, and make your service communicate with it.
   • You'll need to have a logged in interactive user and the user needs to start the server application somehow. Perhaps best to use autostart.
   • You can try turning on Automatic login. http://support.microsoft.com/kb/324737
3. Try impersonating a Logged in user using CreateProcessAsUser and friends.
   • Note: I don't know how well this works unless a user is actually logged in, so it might not be any more useful than 2 above, and is much harder to pull off. (Needs P/Invoke)
4. Rewrite your program to use the OpenXML sdk or use something like SpreadsheetGear.