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.
Related
We have an application which has been around for some time and which uses the Excel Interop library. The project references the Microsoft.Office.Interop.Excel and it's pointed at the default path in Visual Studio.
Recently I was asked to add some functions to this project based on Word interop. This all went fine in development. I add a reference to the Word interop dll at the same location (C:\Program Files (x86)\Microsoft Visual Studio 12.0\Visual Studio Tools for Office\PIA\Office15).
Both Word and Excel are installed on the server. However, while the Excel interop continues to function, trying to use the Word functions throws this error:
System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
References to this error suggests it's due to a 32/64 bit clash, which I find quite surprising. The dll is 32-bit and the project build target is "Any CPU". And besides, it runs the 32-bit Excel interop without complaint.
As far as I can tell, neither Word on Excel have interop dll's installed in the registry on the server.
What gives here? Is this really down to an architecture mismatch? And if not, why is my application able to utilise the installed Excel interop but not the Word one?
Interop files shouldn't be registered on the server, they are not COM servers. Instead, I'd suggest re-installing Office applications (repairing them) to make sure all the required windows registry keys for COM servers were created and exist at the time when you try to automate them.
Otherwise, you have faced with a well-known issue... 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 Open XML SDK or just any other third-party components designed for the server-side execution.
This is a difficult problem as the scenario is not supported by Microsoft. Reference: Considerations for the server-side automation of office .
Try changing the setting of "Embed Interop types" in the properties for the refrence to the Office library. That makes the code independent of the PIAs of any specific application version and could work-around whatever is the problem with the server-side installation.
PInvoke (GetType.InvokeMember) also makes the solution independent of the application version and it could be used throughout. This is more work, though, since you don't get Intellisense.
There are a few known issues with this embedding interop types, as there are a couple of "hiccups" in how the embedded interop types embed the information (differently than how the PIAs are constructed). In this case, it might be necessary to use PInvoke for the problem methods/properties. The two approaches can be combined.
I have recently developed a small tool that uses Microsoft.Office.Excel.Interop, and according to my References folder I have added the reference to the Microsoft Excel 14.0 Object Library. I should also mention that I have MS Office 2010 on my machine, so the tool works just fine there.
However I have a client user that is trying to install the tool on his machine (apparently he has MS Office 2003 installed) and is getting an error message.
I was wondering, would there be any issues if I download the Microsoft Excel 12.0 Object Library and also add its Reference into my tool so that I have references to both, MS Excel 14 and MS Excel 12? ... would doing that even make sense?
Again, I'm fairly new to .NET and my programming experience is purely empirical, as in no school. Just a heads up in case this is a stupid question.
EDIT:
I found something that seems to solve this problem. I had my client download the file from this link: http://www.microsoft.com/en-us/download/details.aspx?id=3508
Then just follow the instructions at the bottom, and this apparently solved the problem. He was able to install the tool and run it without issues.
The best solution I have found is to use a virtual machine as a build machine that has the oldest version of the office Interop libraries installed that I care to support. I did run into a number of issues trying to develop with multiple interop versions on my development machine.
Microsoft does provide guidance on building clients for multiple office versions but I found that too cumbersome for my particular use case.
http://support.microsoft.com/default.aspx?kbid=244167
You also might consider skipping Interop entirely by using an alternative library, such as the open source EP Plus. I have not personally tried that one yet, but it looks promising.
http://epplus.codeplex.com/
There are some differences between the versions of the Interops. If you will use some members that were added in the newer version then the older versions won't work. For example here is a list of what all was added in Interop version 14:
http://msdn.microsoft.com/en-us/library/office/ff194938(v=office.14).aspx
If you use any of those your application won't work in older versions since these members were not available in older versions.
I use Microsoft.Office.Interop.Excel.dll COM to export excel. I distribute my application to clients. It runs well on my computer but on another computer, it cause a error.
I wonder that application package should be included Microsoft.Office.Interop.Excel.dll and the computer must be installed Microsoft Excel. Thanks.
P/S: My application is C# .net 2.0.
UPDATE: I am having a problem. I don't know the excel's version on the client computer. So, which version of PIA I will use?
If I build my application with Microsoft.Office.Interop.Excel.dll version 11 (suitable with Office 2003), but what problem will happen if the client computer have Office 2007. It will run or no? How to use only one Microsoft.Office.Interop.Excel.dll which run well on any client computers which have one of office 2003, 2007 or 2010.
Thanks.
Did you deploy the other necessary DLL's?
Interop.Microsoft.Office.Core.dll
Microsoft.Vbe.Interop.dll
EDIT:
You should see two references in your project: Microsoft.Office.Core and VBIDE. Click on these references and set the property "Local Copy" to true.
A complete refrence to installing and deploying the PIA can be found here: http://msdn.microsoft.com/en-us/library/aa159923%28office.11%29.aspx
On that website is also a link to a redistributable file you can include and run from your installer to install the PIA into the GAC.
If you want to use Office Automation you should always have Office installed. That's because the interop classes will create an instance of excel in the background and run all your actions on that instance.
If there is no office installed, it will thus not run properly. Please also keep in mind that using office automation on a server isn't the way to go (due to security issues and so on).
Are they using the same version of Excel? you could look into the PIA (Primary Interop Assembiles) to deploy with your app.
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 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.