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).
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 Visual Studio 2012 professional edition, and i want to add a reference for "Microsoft Outlook 15.0 Object Library" inside my web project, but i can not find it inside the COM, here is a screen shot from my Visual Studio:-
so can anyone advice how i can add the "Microsoft Outlook 15.0 Object Library" to my visual studio 2012 ?
how i can add the "Microsoft Outlook 15.0 Object Library" to my visual studio 2012
Looks like you just need to install Outlook first.
Anyway, 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 workaround you may consider using a low-level API on which Outlook is based on - Extended MAPI. Or just use any third-party wrappers around that API.
If you deal only with Exchange account you may also consider using EWS or Outlook REST API, see EWS Managed API, EWS, and web services in Exchange for more information.
Well, if Outlook is not installed, how can you expect its type library to be present? You can of course create the interop dll on a machine where Outlook is installed, but your code still won't run without Outlook being present.
Worse than that, Outlook (just like any Office app) cannot run in a service (such as IIS). You can use Extended MAPI (C++ or Delphi) to edit the OFT files, but doing that in C# is far from trivial. And you will still need to install Outlook to have the Extended MAPI system present. In C#, you can try to use Redemption (I am its author) - it still requires the MAPI system, but unlike OOM, its RDO family of objects can be used in a service. In your case, you can call RDOSession.GetMessageFromMsgFile (it works with both MSG and OFT files), modify the Subject property of the returned RDOMail object, then call RDOMail.Save.
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 a newbie to asp.net , and I'm using microsoft.office.interop.word dll for displaying word document, and it shows error as
Cannot embed interop type 'Microsoft.Office.Interop.Word.WdMailSystem'
found in both assembly
'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET
Files\root\d5b13769\135f0cf9\assembly\dl3\8de2cc60\9bee7a13_f7a7d001\microsoft.office.interop.word.DLL'
and
'c:\Windows\assembly\GAC\Microsoft.Office.Interop.Word\12.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Word.dll'.
Consider setting the 'Embed Interop Types' property to false.
and it will be helpfull if anyone helps me , thank you
There is no need to use the Embed Interop Types property for Office interops libs.
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 in MSDN.
You may consider using the Open XML SDK, see Welcome to the Open XML SDK 2.5 for Office for more information. Or just find any third-party components designed for the server-side execution.
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?