I am currently writing an application that will perform automation in Excel. I have MS Office (2007) installed on my work computer and the application is working fine referencing the the Microsoft Excel 12.0 Object Lirary.
The target machine has the Office installed but not registered. It is one of those preinstalled editions. Attempting to run the application on the target machine I get an error saying Office is not installed?
I'm assuming then you have to have a registed Office to use the object libraries? Is there anyway around this as I do not have a Office license key lying around and its quite expensive?
See if you can run Excel manually on that machine. If you can do this, you should be able to automate it as well. If you cannot, don't expect to be able to somehow miraculously (and legally) to make it work through automation. Automating Office through its object library is no different than using it through the UI. You need to have a licensed and properly installed copy of Office in order to be able to use it.
Nothing comes for free.
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
What are you trying to automate/achieve? Don't you think OpenOffice would be of any use?
Related
I am trying to create excel files using interop library, but below is the error I get:
Creating an instance of the COM component with CLSID {00024500-0000-0000-
C000-000000000046} from the IClassFactory failed due to the following error: 8001010a
The message filter indicated that the application is busy.
(Exception from HRESULT: 0x8001010A (RPC_E_SERVERCALL_RETRYLATER)).
I looked into lots of resources out there on the net, which broadly can be categorized into following:
Interop libraries are specifically built for desktop applications, and using them in a server side web application such as wcf is highly not recommended.
Permission issues related to interactive user or DefaultAppPool.
so and and so forth.
Well, here's the caveat, I cannot change the server side application and everything works everywhere else. Few days ago, office 2016 got pushed on my machine from IT, and things stopped working (with above error) on my local machine. Now I can't go and change a legacy code, but see if I can fix the issues on my local to do further development.
Here's what I did, please note that everything was working on this machine (when office 2013 was there):
Got office 2016 Uninstalled, and re-installed office 2013, same issue, hence reverted back to office 2016. Currently MS-Office 2016 32 Bit is installed.
Verified permissions on various sections of security tab of Microsoft Excel Application, have added IIS AppPool\DefaultAppPool user, IIS_IUSRS, Interactive User with full control permission, (shouldn't the error be "Access denied", had permissions been wrong?)
Created a new sample web application, to quickly debug, ran it in all combinations of cpu platform i.e. x86, AnyCpu, x64 - same issue.
Interestingly enough, it works if I point my sample application to IIS Express instead of Local IIS.
Added latest version of interop assembly available (Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1000) - still same issue
Added Microsoft Office 16.0 Object Library (2.8) to the project - still same issue
It's an age old question and its probably better to get away with interop, but I wanted to understand what might be going wrong - all the direct results for the error above suggest implementing IMessageFilter or what not, but I cannot change server side code, below line should simply work as it used to few days ago:
Microsoft.Office.Interop.Excel.Application l_ExcelApp =
new Microsoft.Office.Interop.Excel.Application();
but it doesn't, so what changed? what might have gone wrong?
Also, if it helps - ApplicationID listed in dcomcnfg (/32) is : 00020812-0000-0000-C000-000000000046}, but error has a different one.
Where to look? I hope answer to this question can guide lost souls for ever about this issue.
I'd recommend using the Open XML SDK for dealing or generating open XML documents on the server-side, see Welcome to the Open XML SDK 2.5 for Office for more information. Or just use any third-party components designed for the server-side execution.
As you already noticed, the Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
Finally I was able to resolve my issue. Following works:
Web Application hosted in IIS, creating excel documents.
So it turns out, apart from the permissions, it is also very important that the application architecture should be similar i.e. my application was 64bit (running as Any CPU on 64bit OS). Whenever you run into such an issue, make sure following also (apart from setting right permissions to right user):
Make sure the architecture of the two applications i.e. (your own and excel) are in sync. One quick way to know whether your excel is 64bit or 32 bit is by looking into Task Manager running programs. If excel is listed as EXECEL.EXE*32 then your office is 32 bit.
When you install a new version of excel, make sure you completely remove previous versions (and not just uninstall, but also removal of dcomconfig office entries i.e. by deleting any registry entry you can find in regedit for the involved office applications guid, specially excel).
I made it work by removing Office 2016 completely as described in 2, afterwards installing Office 2013 and fixing Microsoft.Office.Core reference accordingly in my code.
Permissions that I assigned was following:
Application Identity - Interactive User
And inside Security tab, added IIS AppPool\DefaultAppPool user to all sections and gave full permission.
My app runs in ApplicationPoolIdentity inside IIS.
If doing all the above, still doesn't fix your problem, then God be with you, and more power to you for your journey towards open XML.
I am writing an application that do Excel 2013 Interop.
My first step was to add the reference using the add reference > com panel. But the build on my jenkins failed because Office is not installed on the server.
It is out of the question to install Office on the server but I looked for Office 2013 PIA (like suggested on this post and so many other on the internet), but I could not find it.
So I ended up installing the nuget package for it. It was fine except that it does not install the Microsoft.Office.Core dll required for example to add picture to a worksheet... And I need that feature...
Do you know where I can find the Microsoft.Office.Core.dll or the
Office 2013 PIA?
Or do you have any other solution that could do the trick without
rewriting all the code that currently works?
Recommend you to use OpenXml, which is easy-to-use and will not require you to install Office.
You could add agents (one or more) that are Windows machines with the necessary libraries installed, then configure the master node to only run builds that are specifically assigned to it.
Then you don't need to install the Excel 2013 development environment on your server, and your build environment will more closely represent the user environment.
Refer to How to set up new Jenkins slave (where "slave" is the out of favor term for an agent)
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
As a possible workaround you may consider using the Open XML SDK if you deal with open XML documents only, see Welcome to the Open XML SDK 2.5 for Office. Or just any third-party component designed for the server-side execution (for example, Aspose).
I've built a windows application that retrieves information from an Excel Worksheet. I've tested and had it working on a computer with Microsoft Office Package installed.
I have a little problem now, I will be deploying this program to multiple workstations but they have OpenOffice installed. My issue is, do these workstations need have Microsoft Office installed or would it work regardless?
Thank you all.
If you're referencing the MS Office object library, then they need to have it installed.
Edit: You can probably install Open Office on your machine, write a similar call for that object library, and have it choose based on the installed program(s).
We created an application that uses Office 2007 (Excel 2007) to read in data from an Excel worksheet. However. I noticed that when I want to deploy the application on a system with Office 2003 installed, it crashes because other PIA's (and other dll's) need to be referenced for this version of office.
Do I need to compile different versions of my application to be able to support different versions of Office or is there a more elegant solution for this problem?
I use Visual Studio 2010 (C#) and the .Net 4.0 platform.
As you're using .NET 4, you can use "embedded" PIAs (aka "No PIA"). Change the option on the Office reference so that "Embed Interop Types" is True.
So long as you only use features of Office which are supported on the machine you deploy on, you should be fine.
It also means that:
- You don't need to worry about the PIA itself not being present on the target machine
- Any methods or properties which are of the VARIANT type in the original COM interface are now represented using dynamic in your code, which can make your life simpler
Depending on whether you have any other requirements (you say reading data from excel), you can use the OLEDB driver to connect to the excel file and query it in a SQL manner.
Example:
http://codehill.com/2009/01/reading-excel-2003-and-2007-files-using-oledb/
You can reference the PIA's for multiple versions of office, and figure out at runtime which to route your calls from.
I have been using Office 2007 PIA's to run PowerPoint files in my C# application.
I know that this requires Office 2007 to be installed on the machine.
I wanted to know, can the same set up be run with OpenOffice.org installed instead of Microsoft Office?
Note: I am using a Qindows machine.
While OpenOffice does have an Automation Bridge which allows you to access OpenOffice applications in Automation (a proper subset of COM which in turn you can access through COM Interop), the API profile is most definitely not the same.
That being said, any code that you write which uses the Office 2007 PIAs will not be compatable with the Automation model provided by OpenOffice.
Granted, you can probably do many of the same things that you could do in Office, it's just the way you would go about doing them (the methods you call) would be completely different.
In a word, No.
The PIAs contain mapping information specific to the DLL that they wrap, in your case MS Office application DLLs.