Can VSTO Addins be built without installing MS Office? - c#

I am working on setting up build server for a VSTO Addin project. I am using Jenkins for the same. When I try to build project locally on my machine using MS Build it is building fine. However on server, it gives following error:
Error 10 Cannot find the interop type that matches the embedded interop type 'Microsoft.Office.Core.IRibbonExtensibility'. Are you missing an assembly reference?
I think this should be coming from PIA. Can I install PIA without MS Office installed on machine?
So, my question is it not possible to build VSTO solution without installing the MS Office suite on server?

I think this should be coming from PIA. Can I install PIA without MS Office installed on machine?
Yes, you are free to install PIAs without MS Office. It will allow to build the project, but at runtime you will get exceptions in the code. PIAs are used for marshalling your property and method calls to the unmanaged code, i.e. COM servers represented by Office applications.
is it not possible to build VSTO solution without installing the MS Office suite on server?
You are free to build VSTO add-ins on a machine without MS Office installed.

Related

Office 2016 automation

I have an legacy Excel project that automates Excel 2007 on our server in order to produce overnight user-authored reports. It has worked fine but recently on trying to upgrade to Office 365 (also tried 2016) I came across a problem where it appears to throw COMException 0x800AC472 after creating the Excel.Application object.
I can create the object without error but as soon as I try to call any methods of the Application object it faults.
This is a brand new vanilla server with .Net 4.6 and 3.5 installed and Office 365, nothing else.
The code has been re-linked using COM to reference Office 15.0 Interop. And the same code still works perfectly on the old 2007 server.
Microsoft.Office.Core 16.0
Microsoft.Office.Interop.Excel 16.0
The Error message in full:
System.Runtime.InteropServices.COMException (0x800AC472): Exception from HRESULT: 0x800AC472
at Microsoft.Office.Interop.Excel.ApplicationClass.set_DisplayAlerts(Boolean RHS)
at ExcelReportingService.ExcelJob.ProcessExcelBook(String location, String savePath, String testEmailsOnlyTo, Boolean allowEmptyResultFile, StringBuilder& processResults) in W:\\Group\\VIP\\Services\\ExcelReporting\\Classes\\ExcelJob.cs:line 136
The code has never had an install package and I'm not sure if this is this is the issue? Currently I am just copying the DLLs for the app to the service folder and installing with "sc create". I have not installed any other runtimes or copied any DLLs into the GAC? But I don't do this with the working 2007 server either?
Am I missing a runtime I need to install on the server?
PS: I do recognize the reality that Microsoft has said that server automation is not supported for Office, but this is a legacy project that I need to get working as all servers are being upgraded and Office 2007 will not install on newer servers.

support different Office versions with Office Automation

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.

Error when export Excel using Microsoft.Office.Interop.Excel

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.

Is there a way to automate MS Office applications without license?

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?

Using Office 2007 PIA's against OpenOffice.Org

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.

Categories