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.
Related
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 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 am working with Windows Service written in C#. Through this Windows Service I am automating Excel in a programmatic way.
Excel.Application excel = Excel.Application();
This code was working fine with all versions of Excel (2003, 2007, 2010, 2013).
Recently I have installed Office 365 in my machine. Suddenly I am getting below exception when I automate the Excel using above call:
Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
Can anyone let me know, is there any special consideration should be taken when automating the Office 365 Excel via Windows Service?
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.
You may consider using the Open XML SDK instead, see EWS Managed API, EWS, and web services in Exchange for more information. Or any third-party components designed for the server-side execution.
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 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.