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.
Related
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).
As stated in the title, I need to do some C# coding from a Web Application that will auto-generate a Word document. So far, targeted towards Office 2007 and above users.
My question would be, is using the Interop library the recommended way of doing this? Isn't there some issues with using it between different versions (e.g. 2007 -> 2010 -> 2013)? What are its advantages and disadvantages? And finally, are there any better alternatives?
On the contrary, Microsoft's advice is very much not to use it:
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.
There are various libraries available in managed code (OpenXML SDK, Aspose Words etc.)
As Charles metnioned, Microsoft doesn't recommend automating Office applications on the server (from any unattended client). Instead, I'd suggest using the Open XML SDK for buiding open XML file format Office files. See Welcome to the Open XML SDK 2.5 for Office for more information.
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 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?
i wrote a app for reading excel files.i had to add some references to Microsoft office Com Objects.
it worked good in my system,but when i wanted to use it in other system in which does`t had ms office installed ,
i encounter a problem.i also carried dll files that has been added to project . what should i do ?
In order to use the relevant object libraries you'll have to make sure that Office (Excel in your case) is installed on your client machine. If you have the option I'd suggest to switch to the Open Office XML format anyways. I recently had a similar problem with MS Word and the +work to switch to the new format has def. payed of.
Check MS Open XML SDK
Performace++ and not depending on Office installed...
The Office COM objects depend on Office. You should either arrange for Office to be installed on the other systems, or use a component for reading Excel files that doesn't need Excel installed, such as the ODBC Excel driver or a third-party Excel file reader.