Office Interop with 64-bit Windows in ASP.NET

Question

I am trying to do Office 2003 interaction using C # ASP.NET on a server with a 64-bit version of Windows 2003 (I use IIS in 32-bit mode) and get error messages like:

The default permission settings for the computer do not provide local activation permission for the COM server application with CLSID {00024500-0000-0000-C000-000000000046} in the user domain \ username SID (SXX-XX-XXX-XXXX-XXX-XXXXX). This security permission can be changed using the component services administration tool.

Does anyone know what I need to change to make this work? Thanks if you can help.

EDIT - This works fine on a 32-bit server.

EDIT 2 - I don't like anyone, but I'm not sure there are other ways that meet our requirements. If you can think of one thing, I opened up another alternative-to-office-interop-for-document-generation question

Answer 1

I have found the answer. Find the guid problem in regedit. Then you will come across a key that contains two values ​​- the name of the component and its value in the component services.

Answer 2

None of the Office applications work properly when called from a server environment. Their COM interfaces are designed to automate the desktop, not automation from the server application. Everything you do to try to get them to work will include hacks created on hacks and is doomed to failure.

This leaves aside the fact that you do not have the right to run them from a server application.

---

Correction: KB article. Office Server Automation Considerations Really Say You Are Licensed for Server Automation of Office Products for use only if all clients are licensed:

In addition to technical issues, you should also consider licensing issues. Current licensing rules do not allow Office applications to be used on the server to service client requests, unless these clients have licensed copies of Office. Using server automation to provide Office functionality for unlicensed workstations does not apply to the End User License Agreement (EULA).

On the other hand, this KB article contains many reasons to never do this. These include:

• User ID
• Desktop Interactivity
• Redundancy and Scalability
• Sustainability and stability
• Server Side Security

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

Answer 3

As John Saunders says, side licensing problems, you just won’t get Office automation running on the server side.

Check out the OpenXML SDK, which you can use 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

Try running AppPool under the more privileged Indentity (right-click on AppPool and select the Identity tab).

Answer 5

As mentioned above, using COM Interop in a Microsoft server environment is not supported.

Having said that, you did not indicate whether you are talking about ASP.NET, WinForms, the Console application or ???. You may find that it will work if you create a console application and install the target processor in the Visual Studio configuration manager on x86 instead of Any CPU. This will make your application run in 32-bit mode on a 64-bit server. Of course, there are a number of other problems that you may encounter, such as permissions.

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

Disclaimer: I have SpreadsheetGear LLC