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:

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {00024500-0000-0000-C000-000000000046} to the user domain\username SID (S-X-X-XX-XXX-XXXX-XXX-XXXXX). This security permission can be modified using the Component Services administrative tool.

Does anybody know what I need to change to get this working? Thanks if you can help.

EDIT - This was working fine on a 32bit server.

EDIT 2 - Nobody seems to like this but I'm not sure there's any other way given our requirements. If you can think of one, I've opened another question alternative-to-office-interop-for-document-generation

Answer 1

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

Answer 2

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 3

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

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