如何最好的未来证明我需要连接到Outlook的应用程序？

Question

我有一个用Delphi编写的联系人管理应用程序，它具有我10年前开发的“与Outlook同步”功能。现在，我将回去添加一些功能并修复一些错误。此同步功能使用Outlook对象模型开始，但它有一个名为“使用MAPI增强功能”的可选模式，它使用纯MAPI来加速查找更改的方式，并允许使用RTF同步注释而不是只是纯文本。

我想知道是否支持两个并行执行路径是一个好主意。

如果我使用所有MAPI，我相信我会避免一些安全提示，并且我会避免反病毒具有阻止我的应用程序连接到Outlook的“脚本阻止”功能的情况。但我相信，在不利方面，我的32位应用程序将无法使用MAPI连接64位Outlook 2010。我对MAPI的未来感到好奇。

如果我坚持使用Outlook对象模型，我的32位应用程序是否能够连接到Outlook对象模型（因为它不在进程COM中）？如果是这样，这是保持我的Outlook对象模型执行路径到位的一个令人信服的理由。但如果没有，如果我的应用程序需要为x64编译，那么为什么不选择纯MAPI呢？

Answer 1

这是正确的，您需要根据Outlook位度编译32位或64位代码。

至于MAPI的未来，它仍然存在并得到MS的积极支持。 Outlook 2010仍然是纯MAPI。

Answer 2

我通过测试确认：   1. 32位应用程序可以通过COM自动化连接到Outlook 2010 x64。   2. 32位应用程序无法通过纯MAPI连接到Outlook 2010 x64。

因此，似乎我最好保留Outlook COM自动化代码以支持Outlook 2010 x64，而我的MAPI代码只能在x86 Outlook上使用。

但是我注意到在Outlook 2007中添加了“PropertyAccessor”对象，这将允许您在不使用MAPI的情况下读取MAPI属性。这可能会给我带来阅读/编写RTF Notes的好处......如果我不能使用MAPI，这是主要的缺失功能。