Selecting an API or technology for developing solutions for Outlook

本文說明可用來擴充 Outlook 2013 和 Outlook 2016 的 API 和技術，並協助您決定適合您案例的 API 或技術。

Microsoft supports various APIs and technologies that extend Outlook:

• Starting in Office 2013, the apps for Office platform opens up opportunities to extend Outlook functionality across Outlook clients on the desktop, tablet and smart phone. The platform includes a JavaScript API for Office and a schema for app manifests.

• The object model, the corresponding Outlook Primary Interop Assembly (PIA), and the Messaging API (MAPI) have been the most commonly used APIs in Outlook solutions.

• The auxiliary APIs complement MAPI in a few scenarios.

• Outlook Social Connector (OSC) provider extensibility and the Weather Bar extensibility serve specific scenarios of their niche markets.

This article explains the selection criteria for the Office 增益集 platform, the object model, PIA, and MAPI. Note that Office 增益集 use the JavaScript API for Office and do not call into the object model, and vice versa. Solutions that use the other APIs can use one or more APIs. For example, a COM add-in written in C++ can use the object model, MAPI, and auxiliary APIs in the same solution.

To get the most benefit from this article, you should be familiar with Outlook at the user level and have general software development knowledge. However, you do not need to have a comprehensive understanding of the features that these APIs or technologies support. The article helps answer the following questions:

• If you have only an idea about the goals of your solution, the target market, and available resources, what other criteria should you consider to select an API?

• Why would you consider Office 增益集, and when would you choose to create apps as opposed to add-ins?

• If your solution has to run on earlier versions of Outlook, including Outlook 2003, how does that affect your API choice?

• If your solution has to iterate through Outlook folders that contain thousands of items, and you need to be able to modify those items, which API would work best?

• If your solution relies heavily on Outlook business logic and interacts with other Office applications, is the Outlook object model the best choice?

• What do the object model and MAPI allow you to extend in Outlook?

• If you can use either the object model or MAPI to achieve your task, how should you decide which API to use?

Objective evaluation criteria

This section describes criteria that you can use to compare the Office 增益集 platform, object model, PIA, and MAPI to determine which better meets your needs. Different criteria can be more or less important, depending on your projects and available resources.

The tables in this section define evaluation criteria in the following categories:

• Functional criteria—Describes the things you can and cannot do with the technology.

• Development criteria—Describes the development tools or information you need to use the technology

• Security criteria—Describes the security and permissions issues related to the technology.

• Deployment criteria—Describes the recommended deployment and distribution methods for the technology.

Objective evaluation criteria for the apps for Office platform

Starting in Office 2013, developers can use the Office 增益集 platform to extend web services and content into the context of Office rich and web clients. An Office 增益集 is a web page that is developed using common web technologies, hosted inside an Office client application (such as Outlook), and can run on-premises or in the cloud. Of the few types of Office 增益集, the type that Outlook supports is called mail apps. While the object model, PIA, and MAPI are often used to automate Outlook at an application level, you can use the JavaScript API for Office to interact at an item level with the content and properties of an email message, meeting request, or appointment. You can publish mail apps to the Office 市集 or an internal Exchange catalog.

End users and administrators can install mail apps on an Exchange mailbox, and use mail apps in the Outlook rich client as well as Outlook Web App. As a developer, you can choose to make your mail app available on only the desktop, or also on the tablet or smart phone. Figure 1 shows an example of a YouTube mail app, which is described in detail in 範例: 建立郵件應用程式在 Outlook 中檢視 YouTube 視訊. The YouTube mail app allows end users select a URL for a YouTube video and watch the video within Outlook or Outlook Web App, on the desktop or tablet.

圖 1： YouTube 郵件應用程式適用於選取的郵件，其中包含 YouTube.com 上影片的 URL

After a user installs a mail app, the app is available for use in the app bar when the current context matches the activation conditions that the app specifies. A mail apps allows you to specify rules about the currently selected item that activate a mail app only if certain conditions are met. For example, the YouTube mail app that lets you play a YouTube video within Outlook is relevant only when the selected Outlook item contains a URL to a video on YouTube.com. In this case, you would specify that the app should be active only when the selected message contains such a URL.

The following tables show the evaluation criteria for the Office 增益集 platform.

Functional criteria

Criteria	Mail apps support in apps for Office platform
Application domain	The scope of activity of a mail app is virtually any supported message or appointment item in the user's Exchange mailbox that the user has selected and that satisfies the activation conditions. The permissions of a mail app determine its access to the properties and specific entities (such as an email address or telephone number) that exist for that item. For example, a mail app requesting the read/write mailbox permission can read and write all the properties of any item in the user's mailbox; create, read, and write to any folder or item; and send an item from that mailbox.
Major objects	The JavaScript API for Office provides a few objects at the top level that are shared by all the types of Office 增益集: Office, Context, and AysncResult. The next level in the API that is applicable and specific to mail apps includes the Mailbox, Item, and UserProfile objects, which support accessing information about the user and the item currently selected in the user's mailbox. At the data level, the CustomProperties and RoamingSettings objects support persisting properties set up by the mail app for the selected item and for the user's mailbox, respectively. Item-level objects include the Appointment and Message objects that inherit from Item, and the MeetingRequest object that inherits from Message. These represent the types of Outlook items that support mail apps: calendar items of appointments and meetings, and message items such as email messages, meeting requests, responses, and cancellations. Beyond this level in the API are item-level properties (such as Appointment.subject) as well as objects and properties that support certain known Entities objects (for example Contact, MeetingSuggestion, PhoneNumber, and TaskSuggestion). See Outlook 增益集架構與功能概觀 for a summary of the features supported for mail apps.
Data-access model	The JavaScript API for Office represents the following features as a hierarchical set of objects: the app's runtime environment, user's mailbox and profile, and data about an item.
Threading models	Each mail app executes in its own process separate from the Outlook process.
Application architectures	In Outlook, a mail app is a set of HTML and JavaScript web pages hosted as a separate process inside a web browser control which, in turn, is hosted inside an app runtime process that provides security and performance isolation.
Remote usage	Mail apps use the JavaScript API for Office to access data about the current user, mailbox, and selected item stored on the corresponding Exchange Server. Provided that they have the appropriate permissions and use the appropriate technique for cross-domain access, mail apps can also call Exchange Web Services and other third-party web services to extend their functionality.
Transactions	The JavaScript API for Office does not support transactions.
Availability	The JavaScript API for Office is available for mailboxes on Exchange Server 2013, starting in Outlook 2013.

Development criteria

Criteria	Mail apps support in apps for Office platform
Languages and tools	You can implement mail apps using any common web technology, including HTML5, JavaScript, CSS3, XML, and REST APIs. You can use your preferred web development tool. Alternatively, using Napa, Visual Studio 2012, or a later version of these tools provides conveniences that save you time in development.
Managed implementation	Where appropriate in your scenario, you can use managed .aspx pages to implement server-side code for your mail apps.
Scriptable	The JavaScript API for Office is directly used in scripts.
Test and debug tools	You can use any web development tools you prefer. Napa and Visual Studio provide an integrated development environment that facilitates app testing and debugging. 疑難排解 Outlook 增益集啟用 and 範例: 偵錯 Outlook 項目的屬性 provide further help in troubleshooting and debugging mail apps.
Expert availability	Programmers who have the required level of web development expertise for Office 增益集 are relatively easy to find. The platform is intended for both professional and non-professional developers.
Available information	Information about developing and posting Office 增益集 is available at Build apps for Office and SharePoint. Specific documentation for mail apps is available at Outlook 增益集.
Developer and deployment licensing	Refer to 授權您的 Office 和 SharePoint 增益集 for information about the app license framework for Office 增益集.

Security criteria

Criteria	Mail apps support in apps for Office platform
Design-time permissions	No special permissions are required to develop mail apps.
Setup permissions	By default, end users and administrators can install low-trust mail apps that require restricted or read item permission, and administrators can install high-trust mail apps that require read/write mailbox permission.
Run-time permissions	Mail apps request a specific level of permission that is based on a three-tier permissions model: restricted, read item, and read/write mailbox.
Built-in security features	Office 載入宏運行時間提供下列優點，可防止應用程式損毀使用者的環境：隔離應用程式執行所在的程式。 Doesn't involve .dll or .exe replacement or ActiveX components. Makes apps easy to install or uninstall by the end user. The administrator and end users have control over the mail apps that are made available and whether to grant the requested permission before installing a mail app. In the case of rich clients, governs the use of memory and CPU to prevent denial of service malicious attacks.
Security monitoring features	針對郵件應用程式，會監視下列資源：CPU 核心使用量。 Memory usage. Number of crashes. Length of time blocking an application. Regular expression response time. Number of times re-evaluating regular expressions. Administrators can override default settings that govern the resource usage.

Deployment criteria

Criteria	Mail apps support in apps for Office platform
Server platform requirements	The user's mailbox for which a mail app is installed must be on Exchange Server 2013 or a later version.
Client platform requirements	For a mail app to run on the Outlook rich client, Outlook 2013 and Internet Explorer 9, or a later version of these applications, must be installed on the local computer.
Deployment methods	You can publish mail apps to the Office 市集 or to an Exchange catalog that makes the app available to users on that Exchange Server. Administrators or users can then choose to install a mail app from the Office 市集 or Exchange catalog, by using either the Exchange Admin Center (EAC) or by running remote Windows PowerShell cmdlets. You can access the EAC from the Outlook Backstage view or Outlook Web App, or by directly signing into the EAC for your mailbox. For more information, see 部署並安裝 Outlook 增益集測試.
Deployment notes	Once you install a mail app on Outlook or Outlook Web App, the mail app is available for that mailbox on both Outlook clients.

Objective evaluation criteria for the object model and PIA

Solutions that run on the client computer can use the Outlook object model or PIA to programmatically access Outlook items, such as contacts, messages, calendar items, meeting requests, and tasks. Unlike MAPI, the Outlook object model and PIA can provide event notifications for Outlook user-interface changes, such as changing the current folder or displaying an Outlook inspector.

The following tables show evaluation criteria for the Outlook object model and PIA.

Functional criteria

Criteria	Outlook object model or PIA
Application domain	Add-ins or standalone applications that use the Outlook object model or PIA typically handle user-specific messages, customize the Outlook user interface, or create custom item types for specialized solutions such as customer relationship management (CRM) solutions that integrate with Outlook. The Outlook object model or PIA is sometimes used for message processing in an informal workflow process, especially where application development on the Microsoft Exchange Server is not permitted. Unlike browser-based clients, cached-mode operation allows Outlook solutions to work when the user is offline or disconnected from the corporate network.
Major objects	The top-level object in the Outlook object model and PIA is the Outlook Application object. Explorers, Conversation, Inspectors, Views, NavigationPane, SolutionsModule, FormRegion, and related objects represent elements of the Outlook user interface. The NameSpace, Stores, Folders, Accounts, AccountSelector, AddressEntries, ExchangeUser, and related objects support extending Outlook sessions, profiles, user accounts, message stores, and folders. At the data level, a number of item-level objects, such as MailItem, AppointmentItem, ContactItem, and TaskItem, represent the built-in Outlook item types. The PropertyAccessor, Table, Search, ItemProperties, UserDefinedProperties, Attachments, Categories, Recipients, RecurrencePattern, Reminders, Rules, and related objects support customizing and manipulating item-level objects.
Data-access model	The Outlook object model and PIA represent all data as a hierarchical set of objects and collections.
Threading models	All calls to the Outlook object model and PIA execute on Outlook's main foreground thread. The only threading model that the Outlook object model supports is single-threaded apartment (STA). Calling the Outlook object model or PIA from a background thread is not supported and can lead to errors and unexpected results in your solution.
Application architectures	Typically, COM add-ins and other Office applications use the Outlook object model to extend Outlook. Managed solutions can use the Outlook PIA and the COM interoperability layer of Visual Studio and the .NET Framework to access the Outlook object model. Visual Studio provides templates and additional class libraries and manifests to facilitate Office document and application customizations. For more information about using Visual Studio to develop managed add-ins for Outlook, see Architecture of Application-Level Add-Ins and Outlook Solutions. The Outlook object model also supports Visual Basic for Applications (VBA) macros and Windows Scripting Host (WSH), but does not support Windows Service applications.
Remote usage	The Outlook object model and PIA can be used only on a computer on which Outlook is installed. The Outlook object model can be used to access information stored in Exchange that is available in the Outlook application.
Transactions	The Outlook object model and PIA do not support transactions.
Availability	The Outlook object model is currently available in all versions of Outlook. The PIA is available in versions of Outlook since Outlook 2003. There have been extensions and improvements with each new version of Outlook.

Development criteria

Criteria	Outlook object model or PIA
Languages and tools	You can implement Outlook object model applications by using any COM or automation-compatible language, such as Visual Basic or C#, as well as non-COM languages, such as native C or C++. Microsoft Office development tools in Microsoft Visual Studio 2010 are the preferred tools for development of managed add-ins for Outlook 2010 and Outlook 2007. Microsoft Visual Studio 2005 Tools for the Microsoft Office System are the preferred tools for Outlook 2003. You can also use Office development tools in Visual Studio 2010 to create solutions for 32-bit and 64-bit versions of Outlook. When you build a solution in Office development tools in Visual Studio 2010 or Microsoft Visual Studio Tools for the Microsoft Office System, specifying the Any CPU option for the target platform results in managed solutions that work for both 32-bit and 64-bit versions of Outlook 2010.
Managed implementation	Outlook PIA 可讓 Outlook 物件模型用於 Managed 程式代碼環境中，受一組豐富的類別庫支援，並支援可解決許多 VBA 和 COM 載入宏限制的技術。PIA 是 COM 包裝函式，可做為 Managed 與 COM 環境之間的網橋。 如需詳細資訊，請參 閱為何使用 Outlook PIA。
Scriptable	The Outlook object model can be used in scripts.
Test and debug tools	No special debugging tools are needed to use the Outlook object model or PIA. On the other hand, you can use Visual Studio to provide an integrated development environment that facilitates application testing and debugging.
Expert availability	Developers who can successfully develop applications by using the Outlook object model or PIA are relatively easy to find. The Outlook object model and PIA are intended for add-ins created by using widely available development tools, such as Visual Studio. These tools provide design-time environments that simplify the development process.
Available information	Information about programming by using the Outlook object model is available in both Microsoft and third-party resources. For more information about the Outlook object model, see the Outlook 2010 Developer Reference. For more information about the Outlook PIA, see the Outlook 2010 Primary Interop Assembly Reference. For examples of managed Outlook solutions developed by using Office development tools in Visual Studio, see Outlook Solutions with Visual Studio.
Developer and deployment licensing	Refer to your Exchange and Microsoft Developer Network (MSDN) subscription licensing agreements to determine whether additional licenses are required for Outlook and Outlook object model use in your applications.

Security criteria

Criteria	Outlook object model or PIA
Design-time permissions	No special permissions are required to develop applications by using the Outlook object model or PIA.
Setup permissions	No special permissions are required to install applications that use the Outlook object model or PIA. However, local administrator rights are required to install Office and Outlook.
Run-time permissions	No special permissions are required to run applications that use the Outlook object model or PIA.
Built-in security features	The Outlook object model and PIA communicate with Exchange by using MAPI and with Active Directory by using Active Directory Service Interfaces (ADSI). The current security context of the user who is running the application is used to determine what resources that code can access. By default, add-ins are trusted for full access to all objects, properties, and methods in the Outlook object model or PIA. IT administrators can exercise control over which add-ins and objects can access the Outlook object model or PIA. The Outlook object model and PIA prevent code that is run outside the Outlook process from accessing secure objects and methods.
Security monitoring features	Outlook 會監視載入宏的下列計量，以判斷它是否應該停用載入宏：啟動關機資料夾切換項目開啟叫 用 頻率 管理員可以使用組策略來覆寫使用者設定，並控制在用戶計算機上執行的載入宏。 For more information, see Performance criteria for keeping add-ins enabled.

Deployment criteria

Criteria	Outlook object model or PIA
Server platform requirements	The Outlook object model and PIA are client-side technologies.
Client platform requirements	Applications that use the Outlook object model or PIA to access Exchange data require that Outlook be installed on the local computer.
Deployment methods	Applications that use the Outlook object model or PIA are distributed by using standard application installation software.
Deployment notes	Because Outlook should not be installed on the Exchange Server, applications that use the Outlook object model or PIA cannot be run on the Exchange Server.

Objective evaluation criteria for MAPI

You can use MAPI to access items and folders in public and private stores, as well as to access the properties stored with each item. All versions of Outlook use MAPI. You can create clients that use MAPI, and can create MAPI servers and MAPI forms handlers, as well. The information in this section applies only to MAPI client applications.

The following tables show evaluation criteria for MAPI.

Functional criteria

Criteria	MAPI
Application domain	Client applications that use MAPI access a user mailbox or public folder information stored in Exchange, and user directory information stored in Active Directory. Client applications that use MAPI are typically email clients, such as Outlook, and applications that require complex email processing.
Major objects	MAPI objects are all obtained through the IMAPISession： IUnknown interface. The session object provides the client access to objects for working with MAPI profiles, status, message service provider administration, message store tables, and address books. The message store table contains objects for the message store, folders, messages, attachments, and recipients. The address book tables contain objects for messaging users and distribution lists.
Data-access model	MAPI represents messages and users as a hierarchical set of objects.
Threading models	There are no specific threading prohibitions. However, applications that use free-threading should avoid sharing MAPI objects among threads due to the high costs of marshaling the object. MAPI and MAPI service providers use free-threading.
Application architectures	MAPI client applications are typically Windows Forms-based client applications. However, you can use MAPI to write N-tier applications.
Remote usage	MAPI uses remote procedure calls (RPCs) to communicate with the Exchange Server. Typically RPCs are intentionally blocked from passing through Internet firewalls.
Transactions	MAPI does not support transactions.
Availability	A MAPI stub currently ships with all versions of Windows. Office installs its own MAPI subsystem when it installs Outlook. No changes to MAPI are anticipated at this time.

Development criteria

Criteria	MAPI
Languages and tools	You can directly access MAPI by using C or C++. Other languages that can access the C/C++ calling convention may be able to access MAPI. The use of managed languages, such as Visual Basic or C#, is not supported. You must compile separate MAPI solutions for 32-bit and 64-bit versions of Outlook.
Managed implementation	MAPI is an unmanaged component. Use of MAPI is not supported under the COM interoperability layer of Visual Studio and the .NET Framework.
Scriptable	MAPI cannot be directly used in scripts.
Test and debug Tools	No special debugging tools are needed to debug applications that use MAPI. On the other hand, you can use MFCMAPI. MFCMAPI uses MAPI to provide access to MAPI stores through a graphical user interface, and facilitates investigation of issues when you extend Outlook by using MAPI.
Expert availability	Expert MAPI programmers can be difficult to find, and learning the technology can take a significant amount of time. In addition to the Microsoft communities, there are only a small number of high-quality third-party websites that provide helpful MAPI development information.
Available information	Both Microsoft and third-party books that describe MAPI programming are available.
Developer and deployment licensing	No special licensing is required for developing applications that use MAPI.

Security criteria

Criteria	MAPI
Design-time permissions	The developer must have permissions to access the data in the Exchange store. Exchange stores user and distribution list information in Active Directory, so developers who create MAPI client applications that access that information must have the ability to retrieve and set that information.
Setup permissions	Setting up MAPI-based applications typically requires the user to be a local administrator, or to have rights to install software.
Run-time permissions	Running a MAPI-based application usually requires only that the user has sufficient permissions to access the data on an Exchange store or personal folders (.pst) file.
Built-in security features	MAPI profiles can be password protected on most platforms.

Deployment criteria

Criteria	MAPI
Server platform requirements	The Exchange Server on which user data is stored for users of the MAPI client application must be properly configured to allow access by MAPI clients.
Client platform requirements	The client application installer should verify that the proper version of MAPI is available on the computer, and that it is properly configured by using the Mapisvc.inf file.
Deployment methods	Applications that use MAPI can be deployed to client computers by using standard software distribution technologies.
Deployment notes	The installer should verify that the correct version of MAPI is available.

Decision factors for the apps for Office platform

Because Office 增益集 use web technologies, they are best for connecting to services in the cloud or on-premises, and bringing the services into the context of the rich client and web client. By requesting appropriate permissions, mail apps also allow reading, writing, or sending items in a mailbox.

The following are common reasons why mail apps are a better choice for developers than add-ins:

• You can use existing knowledge of and the benefits of web technologies such as HTML, JavaScript, and CSS. For power users and new developers, XML, HTML, and JavaScript require less significant ramp-up time than COM-based APIs, including the object model and MAPI.

• You can use a simple web deployment model to update your mail app (including the web services that the app uses) on your web server without any complex installation on the Outlook client. In fact, any updates to the mail app, with the exception of the app manifest, do not require any updating on the Office client. You can update the code or user interface of the mail app conveniently just on the web server. This presents a significant advantage over the administrative overhead involved in updating add-ins.

• You can use a common web development platform for mail apps that can roam across the Outlook rich client and Outlook Web App on the desktop, tablet, and smartphone. On the other hand, add-ins use the object model for the Outlook rich client and, hence, can run on only that rich client on a desktop form factor.

• You can enjoy rapid turnaround of building and releasing apps via the Office 市集.

• Because of the three-tier permissions model, users and administrators perceive better security and privacy in mail apps than add-ins, which have full access to the content of each account in the user's profile. This, in turn, encourages user consumption of apps.

• Depending on your scenarios, there are features unique to mail apps that you can take advantage of and that are not supported by add-ins:

  • You can specify a mail app to activate only for certain contexts (for example, Outlook displays the app in the app bar only if the message class of the user-selected appointment is IPM.Appointment.Contoso, or if the body of an email contains a package tracking number or a customer identifier).

  • You can activate a mail app if the selected message contains some known entities, such as an address, contact, email address, meeting suggestion, or task suggestion.

  • You can take advantage of authentication by identity tokens, and of Exchange Web Services.

However, the following features are unique to add-ins and may make them a more appropriate choice than mail apps in some circumstances:

• You can use add-ins to extend or automate Outlook at an application-level, because the object model and PIA have extensive integration with Outlook features (such as all Outlook item types, user interface, sessions, and rules). At the item-level, add-ins can interact with an item in read or compose mode. With mail apps, you cannot automate Outlook at the application level, and you can extend Outlook's functionality in the context of only the read-mode of the supported items (messages and appointments) in the user's mailbox.

• You can specify custom business logic for a new item type.

• You can modify and add custom commands in the ribbon and Backstage view.

• You can display a custom form page or form region.

• You can detect events such as sending an item or modifying properties of an item.

• You can use add-ins on Outlook 2013 and Exchange Server 2013, as well as earlier versions of Outlook and Exchange. 另一方面，從 Outlook 2013 和 Exchange Server 2013 開始，郵件應用程式會使用 Outlook 和 Exchange，但無法使用舊版。

For more information about scenarios that the object model and PIA support, see the next section, Decision factors for the object model or PIA. For a comparison of the Office 增益集 platform with other extensibility technologies for Office, see The background on apps for Office and SharePoint.

Decision factors for the object model or PIA

Major baseline scenarios supported by the Outlook object model or PIA

In general, use the object model or the PIA if your solution customizes the Outlook user interface or relies on Outlook's business logic. 以下是 Outlook 解決方案使用物件模型或 PIA 的主要基準案例。

• 自訂 Outlook 使用者介面
• 新增、移除、讀取、寫入、篩選、搜尋或排序 Outlook 專案
• Customize item properties, fields, and forms
• 處理 Outlook 事件，例如切換資料夾或開啟專案
• 自動化 Outlook 並與其他 Office 應用程式整合

自 Outlook 2007 起由物件模型或 PIA 支援的案例

除了基準案例之外，如果您的 Outlook 解決方案支援下列清單中顯示的任何案例，而且您的解決方案是要在 Outlook 2007 或更新版本上執行，但不能在較舊的版本上執行，您也可以使用物件模型或 PIA。 本節會指定您可以在 Outlook 物件模型中使用的主要物件或成員，以擴充每個案例 (但 Visual Studio 自動化物件模型中的 IDTExtensibility2 介面除外，以及 Office 物件模型中的 IRibbonExtensibility 介面，您可以與 Outlook 物件模型) 整合。

• 自定義 Outlook UI：Office Fluent 功能區、瀏覽窗格、工作窗格
• 將表單自定義為表單區域，並透過載入宏加以部署
• 設定並取得未在物件模型中公開的內建專案層級屬性
• 列舉和檢視資料夾中的許多專案
• Flag items as tasks
• Share calendars, RSS feeds, and folders
• 新增、移除、儲存和取得附件的區塊層級、路徑、大小和類型
• Manage rules, time zones, and views
• 在目前配置檔的主要類別清單中新增或移除類別
• 取得目前配置檔中帳戶的詳細資訊
• 取得 Exchange 通訊組清單或使用者的詳細資訊做為地址專案
• 儲存解決方案的私人數據

自 Outlook 2010 起由物件模型或 PIA 支援的案例

如果您的 Outlook 解決方案是要在 Outlook 2010 上執行，而不是舊版，您可以選擇使用物件模型或 PIA 來支援下一節所示的案例。 本節會指定您可以在 Outlook 物件模型中使用的主要物件或成員，以擴充每個案例 (，但 Office 物件模型中的 IRibbonControl、 IRibbonExtensibility 和 IRibbonUI 介面除外，您可以將這些介面與 Outlook 物件模型整合) 。

• 自定義 Outlook 2010 UI，例如 Office Backstage 檢視和操作功能表
• 管理和存取交談中的異質性專案
• 管理檔案總管中的項目選取範圍或尋找選取專案
• Manage selection of attachments in an inspector
• Support multiple Exchange accounts in one profile
• Create a contact card for an address entry
• 在解決方案模組中組織解決方案特定資料夾

自 Outlook 2013 起由物件模型或 PIA 支援的案例

如果您的解決方案是要在 Outlook 2013 上執行，而不是在任何舊版上執行，您可以使用物件模型或 PIA 來支援下列資源中顯示的案例。

• 顯示目前資料夾中所有聯繫人的檢視
• 在閱讀窗格中選取內嵌回應
• Show check address or full name dialog for contact
• Detecting reading item properties is complete

Decision factors for MAPI

In general, you use MAPI to access data on a MAPI-based server such as the Microsoft Exchange server, and to do tasks such as the following:

• Create a custom service provider such as an address book provider, transport provider, or store provider.

• Create a sink process.

• Create or manipulate a profile.

• Run an application as a Windows NT service.

• Run tasks on a background thread. For example, enumerating numerous items in a folder and modifying the items' properties in a background thread can optimize performance.

For more information and code samples, see the Outlook MAPI 參照 and MFCMAPI.

In addition, if your solution runs on a version of Outlook earlier than Outlook 2007, and scenarios such as the following apply to your solution, you should use MAPI to extend those scenarios.

• Set and get built-in item-level properties that are not exposed in the object model.
• Manage accounts, attachments, Exchange distribution lists, Exchange users, or stores.
• Store private data for solutions.
• Manage a message store for an account.

Since Outlook 2007, the object model has supported a range of features that, prior to Outlook 2007, developers had to resort to MAPI or other APIs such as Microsoft Collaboration Data Objects (CDO) 1.2.1 and Microsoft Exchange Client Extensions. So if any of the scenarios in the previous list applies to your solution, but your solution runs on Outlook 2007 or Outlook 2010, you can and should use the Outlook object model or PIA to support these scenarios. For more information about Outlook 2007 enhancements that unify Outlook development technologies, see What's New for Developers in Outlook 2007 (Part 1 of 2).

Decision factors for the Auxiliary APIs

The Outlook auxiliary APIs can integrate with Outlook business logic or MAPI in some scenarios where the object model or MAPI does not provide a solution. Use the Outlook auxiliary APIs in the following scenarios:

• Account management: Manage account information, manipulate accounts, provide notification on account changes, and protect accounts from spam.
• Data degradation: Wrap an object in a preferred character format rather than exposing the object in its native format.
• Rebasing calendars and time zone support: Rebase Outlook calendars to support daylight saving time.
• Free/busy status: Provide free/busy information on calendars.
• Contact pictures: Determine the display of a contact's picture in Outlook.
• Item currency: Determine whether an Outlook item has unsaved changes.
• Categorizing an item: Categorize an Outlook item after sending the item.

For more information about the auxiliary APIs, see the Additional resources—Auxiliary APIs section.

Automating Outlook by in-process vs. out-of-process Solutions

Outlook supports automation by using add-ins that run in the same foreground process as the Outlook process, and by standalone solutions that run in their own separate process outside of the Outlook process. Generally, to automate Outlook, use an add-in to interact with Outlook through the object model, PIA, or MAPI, and in less common scenarios, through an auxiliary API (such as HrProcessConvActionForSentItem). Use an out-of-process solution only when it's necessary (for example, when you're writing a MAPI client application that uses the Tzmovelib.dll file to rebase Outlook calendars for customers, or enumerating numerous items in a folder and modifying the items' properties in a background thread to optimize performance).

載入宏是自動化 Outlook 的慣用解決方案，因為 Outlook 只會信任在載入宏的 OnConnection (Object、ext_ConnectMode、Object、Array) 事件期間傳遞至載入宏的 Application 物件。 您可以 從這個 Application 物件衍生所有物件、屬性和方法，以避免顯示物件模型防護的安全性警告。 如果載入宏建立 Application物件的新 實例，Outlook 就不會信任該物件，即使載入宏位於受信任的載入宏清單上。衍生自這類 Application 物件的任何 物件、屬性和方法都不會受到信任，而且封鎖的屬性和方法會叫用安全性警告。 如需 Outlook 物件模型防護的詳細資訊，請參閱 Outlook 物件模型的安全性行為。

Automating Outlook by managed vs. unmanaged solutions

Outlook supports automation by add-ins and standalone applications, written in managed or unmanaged languages. The more commonly used managed languages are C# and Visual Basic. C++ and Delphi tools are more common in unmanaged development. Available expertise is one consideration when choosing between managed and unmanaged development.

If your solution uses only the object model, you can consider developing a managed solution by using the PIA, or Office development tools in Visual Studio. The Office development tools in Visual Studio provide project templates and visual designers that simplify creating custom user interfaces and developing Office solutions.

On the other hand, because MAPI was developed years before the .NET Framework, and Microsoft does not provide managed wrappers for MAPI, Microsoft does not support using MAPI in managed code. If you are using MAPI, you must develop an unmanaged solution. For more information, see The support guidelines for client-side messaging development.

Niche APIs and technologies

The Outlook Social Connector (OSC) and Weather Bar support extending very specific scenarios in Outlook.

Outlook Social Connector (OSC) provider extensibility

The Outlook Social Connector (OSC) provider extensibility supports developing a provider for a social network to allow users to view, in Outlook and other Office client applications, friends and activities updates on that social network. Figure 6 shows the OSC displaying in the People Pane the activities of a person in social network sites.

圖 6： 在 [人員 窗格中顯示社交網路數據的 OSC

The OSC in Outlook allows users to view, in the People Pane, an aggregation of emails, attachments, and meeting requests from a person in Outlook. In an organizational environment, users who collaborate on a SharePoint site can see document updates and other site activities of this person on the SharePoint site. Outlook Social Connector provider extensibility supports developing a provider for the OSC to synchronize and surface social network updates in Outlook. Common OSC providers (such as Facebook and LinkedIn) are installed by default with Outlook. Depending on the social network sites that an Outlook user has signed into, the user can see, in the People Pane, updates such as photos, status, and activities on the corresponding social networks.

Weather Bar extensibility

Starting in Outlook 2013, the Weather Bar allows developers to plug in a third-party weather web service for the Weather Bar, to provide weather conditions data for a user-chosen location. The Weather Bar in Outlook displays weather conditions and forecast for a geographic location. A user can choose one or multiple locations, and conveniently see weather data in the Weather Bar in the calendar module. Figure 7 shows the Weather Bar displaying a three-day forecast for New York, NY.

圖 7： Outlook 中的天氣列

By default, Outlook uses weather data provided by MSN Weather. The Weather Bar supports third-party weather data web services which follow a defined protocol to communicate with Outlook. As long as a third-party weather data service supports this protocol, users can choose that weather data service to provide weather data in the Weather Bar.

See the Additional resources—primary references, resources, and code samples section for more information about using OSC provider extensibility and the Weather Bar extensibility.

總結

To determine the best API or technology for your solution, you must first define the goals of your solution:

• The versions of Outlook you intend your solution to support.

• The high-priority scenarios of your solution. Does your solution mainly interact with the content and properties of a message or appointment item? Or does your solution automate Outlook at an application level? If so, do these scenarios involve enumerating, filtering, or modifying folders that contain many Outlook items?

First, verify whether the mail app support in the Office 增益集 platform meets your needs. See the Functional Criteria section of Objective evaluation criteria for the apps for Office platform to determine whether the major objects and features support your scenarios. See the section Decision factors for the apps for Office platform to verify whether mail apps are a better choice than add-ins for your scenarios. In general, develop your solution as an app, if possible, to take advantage of the platform's support across Outlook clients over different form factors.

If your scenarios require you to extend beyond message and appointment items, or require you to automate Outlook at an application level, try to match your scenarios with those outlined in the section Decision factors for the object model or PIA. If the object model (or PIA) of your target Outlook versions supports your scenarios, and your solution does not manipulate folders with many items, you should implement your solution as an add-in, in either a managed or unmanaged language.

If the object model (or PIA) of a target Outlook version does not support some of your scenarios, verify whether the scenarios in the Decision factors for MAPI or Decision factors for the Auxiliary APIs section meet your needs. If MAPI meets your needs, you should implement your solution in unmanaged code. If an auxiliary API solves one of your scenarios, you can use managed or unmanaged code.

If your solution uses MAPI, you must implement it in unmanaged code, such as C++. Otherwise, the decision to use managed or unmanaged code to create the solution generally depends on your available resources and their expertise. As for deciding whether to implement the solution as an add-in or standalone application, choose an add-in to avoid the user constantly invoking the Outlook Object Model Guard, unless your scenario requires manipulation of folders that contain numerous items. In the latter scenario, implementing the solution to run as a background thread can optimize Outlook performance.

If your scenarios include showing social network information or updates in Outlook, you should use the OSC provider extensibility to create a COM-visible DLL. You can do this in either a managed or unmanaged language.

If you are interested in plugging in a third-party weather data service to the Weather Bar, you can follow the protocol defined by Weather Bar extensibility and provide the appropriate web services. You can create these web services in a managed language.

Once you have decided on the APIs or technologies to use in your solution, you can refer to additional documentation and code samples in the Additional resources—primary references, resources, and code samples section for more information.

Office 增益集平台概觀 provides a good introduction of Office 增益集, including the architecture and development life cycle.

See Outlook 增益集 for a detailed roadmap of resources about developing mail apps.

另請參閱：物件模型和 PIA

The following resources provide more information about using the object model and PIA.

• Account object

• NameSpace.Accounts property

Accounts—multiple accounts in profile

• Account object

• 針對 Outlook 的相同設定檔使用多個帳戶

• 取得多個帳戶的資訊

• Manipulating Multiple Exchange Accounts in Outlook 2010

Address book and Exchange users

• 顯示通訊錄中的名稱

• 從通訊錄存取 Exchange 使用者或通訊群組清單資訊

• 列出我的經理所屬的群組

• 列出屬於 Exchange 通訊組清單之每個管理員的名稱和辦公室位置

• AddressEntries object

• AddressLists object

• ExchangeDistributionList object

• ExchangeUser object

• SelectNamesDialog object

附件

• 將檔案附加至郵件專案

• Attachment file types restricted by Outlook 2010

• Attachment object

• AttachmentSelection object

• AttachmentAdd event per item object

• AttachmentRead event per item object

• AttachmentRemove event per item object

• BeforeAttachmentAdd event per item object

• BeforeAttachmentPreview event per item object

• BeforeAttachmentRead event per item object

• BeforeAttachmentSave event per item object

• BeforeAttachmentWrite event per item object

Attachments: selection in inspector

• Inspector.AttachmentSelection property

• Inspector.AttachmentSelectionChange event

Automating Outlook

• 使用 COM 增益集自訂 Outlook

• Building a C++ Add-in for Outlook 2010

• COM 與 .NET 之間的互操作性簡介

• 為什麼要使用 Outlook pia (英文)

• 開發 Managed Outlook 載入宏的最佳做法

• 取得並登入 Outlook 的實例

• 從 Visual Basic 應用程式進行 Outlook 的自動化

• 從其他 Office 應用程式進行 Outlook 的自動化

Categories

• 將 Outlook 項目分類

• Category object

• NameSpace.Categories property

Contacts: check address and full name

• ContactItem.ShowCheckAddressDialog method

• ContactItem.ShowCheckFullNameDialog method

交談

• 以交談主旨管理 Outlook 郵件

• 取得並列舉選取的交談

• Conversation object

• ConversationHeader object

• SimpleItems object

• ConversationID property per item object

Events

• 使用 Outlook 事件

• 實作偵測器的包裝函式，並在每個偵測器中追蹤 Item-Level 事件

Explorer: inline response

• Explorer.ActiveInlineResponse property

• Explorer.ActiveInlineResponseWordEditor property

• Explorer.InlineResponse event

Items: basic properties, fields, and forms

• Outlook 項目物件

• ItemProperties object

• UserProperties object

• 標準欄位概觀 (英文)

• Outlook 欄位和對應的屬性

• 自訂欄位與資料類型概觀 (英文)

• 自訂表單頁面及表單區域

Items: customizing properties

• 屬性概觀

• Efficiently Getting and Setting Custom Properties in a Contact Folder in Outlook 2010

• PropertyAccessor object

Items: enumerating, filtering, and sorting

• 儲存 Outlook 項目

• Table 物件中顯示的預設屬性

• Efficiently Filtering Contact Items in a Contact Folder in Outlook 2010

• 列舉、搜尋和篩選資料夾中的項目

• 將資料夾中的項目排序

• Table object

Items: flag as tasks

See the following task-related properties in some item objects such as the MailItem object:

• TaskCompleteDate property

• TaskDueDate property

• TaskStartDate property

• TaskSubject property

• ToDoTaskOrdinal property

Items: selection in explorer

• Selection.GetSelection method

• Selection.Location property

Miscellaneous: business cards, rules, and views

• 自訂及共用名片

• 管理 Outlook 物件模型中的規則

• 建立規則以將特定電子郵件移至資料夾

• Rules object

• RuleActions object

• RuleConditions object

• TimeZones object

• Outlook 檢視

• Views object

安全性

• Outlook 物件模型的安全行為 (英文)

• Shutdown Changes for Outlook 2010

• Attachment file types restricted by Outlook 2010

• Application Shutdown Changes in Outlook 2007 SP2

• Code Security Changes in Outlook 2007

共用

• 共用行事曆

• 共用線上行事曆、RSS 摘要、Microsoft SharePoint Foundation 資料夾及 Exchange 資料夾

• SharingItem object

Solutions: solution-specific folders

• Programming the Outlook 2010 Solutions Module

• SolutionsModule object

Solutions: storing data

• 儲存解決方案的數據

• StorageItem object

User interface: customizing form regions

• 自訂表單頁面及表單區域

• 表單區域

• 建立表單區域

• 逐步解說：將表單區域新增至表單中的現有頁面

• Building an Outlook 2007 Form Region with a Managed Add-In

• Implementing a Form Region to Display Email Headers in Outlook 2010

• FormRegion object

• FormRegionStartup object

User interface: customizing since Outlook 2007

• 自訂功能區概觀

• Customizing the Ribbon in Outlook 2007

• Developing Interfaces in Outlook 2007

• Custom Task Panes Overview

• Targeting User Interface Solutions to the 2007 and 2010 Releases of Microsoft Office

• 自訂功能窗格

• Outlook 檢視控制物件模型參考

• IDTExtensibility2 interface

• IRibbonExtensibility object

• NavigationPane object

User interface: customizing since Outlook 2010

• 擴充 Outlook 2010 中的使用者介面

• Outlook 的 Office Fluent 使用者介面擴充性

• Programming the Outlook 2010 Solutions Module

• Customizing the Context Menu of a Contact Card in Outlook 2010

• IRibbonControl object

• IRibbonExtensibility object

• IRibbonUI object

User interface: solutions-specific folders

• Programming the Outlook 2010 Solutions Module

• Adding Solution-Specific Folders to the Solutions Module in Outlook 2010

• SolutionsModule object

另請參閱：輔助 API

The following resources provide more information about the Outlook auxiliary APIs.

Account management

• 關於帳戶管理 API

• 帳戶管理 API 參考 (英文)

• 反垃圾郵件設定的相關

Categorizing items

• HrProcessConvActionForSentItem

Contact pictures

• 指定是否要在 Outlook 中顯示聯絡人的圖片 (Outlook 輔助參考)

Data degradation

• 關於資料降低層 API

• 資料降低層 API 參考 (英文)

空閒/忙碌狀態

• 相關的空閒/忙碌資訊的 API

• 使用相對時間來存取空閒/忙碌數據

• 空閒/忙碌 API 參考 (英文)

Item currency

• 判斷 Outlook 專案是否已修改，但尚未儲存 (Outlook 輔助參考)

Rebase calendars

• 關於重定行事曆以程式設計方式的基底的日光節約時間

• 若要將二進位屬性認可至資料流的保存 TZDEFINITION 的相關

• 從二進位屬性剖析數據流以讀取 TZDEFINITION 結構

• 從二進位屬性剖析數據流以讀取 TZREG 結構

• 從約會讀取時區屬性

另請參閱：主要參考、資源和程式碼範例

The following resources provide more information about the primary Outlook references, resources, and code samples.

Major references and resources

• Office 增益集
• Outlook 2013 developer reference
• Outlook 2010 Primary Interop Assembly Reference
• Outlook MAPI 參照
• Outlook 2013 Auxiliary Reference
• Outlook Social Connector 提供者參照
• Extending the Weather Bar in Outlook
• Outlook Weather Information XML Schema
• Outlook Weather Location XML Schema
• What's New in XML Schemas for Outlook 2010
• Outlook 2010: XML Schema Reference
• Developing Outlook 2010 Solutions for 32-Bit and 64-Bit Systems

Code samples

• Mail apps samples
• Object model code samples: How Do I ... in Outlook
• PIA code samples: How Do I... (Outlook Reference)
• MAPI 範例 (英文)
• Auxiliary API code samples: 範例工作 (英文)