Office Interop with 64bit Windows in ASP.NET

Question

I\'m trying to do office 2003 interop using C# ASP.NET on a server running Windows 2003 64 bit (I\'m running IIS in 32bit mode though) and getting error messages like:

Answer 1

Like John Saunders says, licensing issues aside you just won't get Office automation working properly server-side.

Check out the OpenXML SDK, which you might be able to leverage to achieve the same end result. DocumentReflector in particular will help you with this.

http://blogs.msdn.com/alspeirs/archive/2008/12/09/generating-documents-with-c-open-xml-and-the-document-reflector.aspx

http://www.microsoft.com/downloads/details.aspx?FamilyID=c6e744e5-36e9-45f5-8d8c-331df206e0d0&DisplayLang=en

Answer 2

As the others mentioned, using COM Interop in a server environment is not supported by Microsoft.

Having said that, you did not specify whether you are talking about ASP.NET, WinForms, a Console Application or ???. You might find that it will work if you build a console application and set the target CPU in the Visual Studio configuration manager to x86 instead of Any CPU. This will force your application to run in 32 bit mode on the 64 bit server. Of course, there are still a number of other problems you may run into such as permission issues.

SpreadsheetGear for .NET is tested and supported in W2K3 64 bit and W2K8 64 bit environments.

Disclaimer: I own SpreadsheetGear LLC

Answer 3

None of the Office applications work properly when called from a server environment. Their COM interfaces are meant for desktop automation, not automation from a server application. Anything you do to try to make them work will involve hacks built upon hacks, and is doomed to failure.

This leaves aside the fact that you are not licensed to run them from a server application.

---

Correction: The KB article Considerations for server-side Automation of Office does indeed say that you are licensed for server-side automation of Office products for use only if the clients are all licensed:

Besides the technical problems, you must also consider licensing issues. Current licensing guidelines prevent Office applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA).

On the other hand, that KB article lists a large number of reasons to never do this. They include:

• User Identity
• Interactivity with the desktop
• Reentrancy and scalability
• Resiliency and stability
• Server-side security

I recommend this KB article to anyone considering server-side automation of Office products.

Answer 4

I've found the answer. Search for the problem guid in regedit. You'll then come across a key that contains two values - the name of the component and it's guid in component services.

Answer 5

Try to run AppPool under more priveleged Indentity (Right click on AppPool and select Identity tab).