在Visual Studio 2012中找不到“ Microsoft Outlook 15.0对象库”

Question

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 ?

Answer 1

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 - 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 .

Answer 2

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.