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

Bamberger

You say it was working fine on a 32-bit server, but that's not accurate. it appeared to be working fine, but it was simply a hack that hadn't yet broken in a manner that identified the hack as the problem. – Ravioli

Answer 1

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.

Bamberger

Please don't try to deploy a solution based on what you're doing here - it's a hack, and a bad one at that. – Presentationism

Really. See support.microsoft.com/default.aspx/kb/257757 before you continue. – Ravioli

This was written years ago and hack now trumps apparently non-existant alternative. If you know one, please let me know at #1039951 – Bamberger

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.

Ravioli

you are licensed if the client has an office license – Bamberger

Please post a link to where it says that. It was my understanding there is no server license for the Office products, not even a CAL. – Ravioli

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

Presentationism

Answer 4

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

Budget

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

Tanga