Developer Issues When Upgrading Solutions to Outlook 2010 (Outlook)

  • [アーティクル]

This topic lists issues to consider before you upgrade existing solutions to Microsoft Outlook 2010.

Collaboration Data Objects (CDO)

Collaboration Data Objects (CDO) 1.21 is not supported in Outlook 2010. Any existing version of CDO 1.21 will be removed when you upgrade from an earlier version of Office. The absence of CDO will break solutions that have a dependency on it. The suggested workaround is to rewrite your solution so that it uses the Outlook object model, which has been enhanced to provide most of the CDO functionality, or to call Messaging API (MAPI) directly.

Exchange Client Extensions (ECEs)

By default, Exchange client extensions do not load in Outlook 2010. There is no workaround unless the creator of the Exchange client extension converts the Exchange client extension to an Office COM add-in.

Customizing Inspector or Explorer Command Bars

Command bars are deprecated in the inspector and explorer in Outlook 2010. Although your add-in or VBScript code that customized command bars in an inspector or explorer might still work in Outlook 2010, those who use your solution might not easily find your custom commands because those commands appear on the Add-ins tab of the ribbon in the customized inspector or explorer. Instead of using command bars, use the IRibbonExtensibility interface in an Outlook add-in. Note that you cannot customize inspector ribbons by using VBScript code behind forms. For more information about using IRibbonExtensibility to customize the Outlook user interface programmatically, see the article Extending the User Interface in Outlook 2010 on the MSDN Web site.

Customizing Shortcut Menus Using Application Object Events

Customizations to shortcut menus using events such as ItemContextMenuDisplay on the Application object might not operate as expected. These events operate on a CommandBar object that is returned in the event. Because command bars are deprecated in Outlook 2010, use IRibbonExtensibility to customize shortcut menus programmatically. For more information about customizing shortcut menus, see the article Extending the User Interface in Outlook 2010 on the MSDN Web site.

Office 2010 Available in Both 32-bit and 64-bit Versions

64-bit processors are becoming the standard for systems ranging from servers to desktop computers. 64-bit systems can use more virtual and physical memory than 32-bit processors. Users on 64-bit systems can work with much larger data sets, and analyze and solve larger computational problems than they could previously. Microsoft Office 2010 is available in both 32-bit and 64-bit versions. The native 64-bit version of Office 2010 takes advantage of the larger capacity. The 32-bit version of Office 2010 provides the same functionality as 64-bit, and is compatible with 32-bit add-ins. By default, Office 2010 installs the 32-bit version. Office 2010 also supports 32-bit Office applications running on 64-bit Windows operating systems by using Windows-32-on-Windows-64 (WOW64). WOW64 is the x86 emulator that enables 32-bit Windows-based applications to run seamlessly on 64-bit Windows. The 32-bit version of Office 2010 gives users the ability to continue to use existing 32-bit ActiveX controls, COM add-ins, and Visual Basic for Applications (VBA) solutions on 32-bit systems, and with WOW64, on 64-bit systems as well.

ActiveX Controls and COM Add-ins

ActiveX controls and add-in (COM) DLLs that are written for 32-bit Office do not work in a 64-bit process. As a result, a 64-bit solution for Office 2010 that tries to load 32-bit ActiveX controls or DLLs in its process fails. In addition to controls that load into Office applications, there are also Web-based solutions that use ActiveX controls in Internet Explorer. The 64-bit version of Office 2010 installs Office 32-bit client-side controls to support Web solutions in a browser. The workaround to resolve these issues on a 64-bit system is to have your 64-bit solution load 64-bit-compatible controls and add-ins, or provide a 32-bit solution for Office 2010 (WOW64) to work with the 32-bit ActiveX controls and COM add-ins.

MAPI Applications

If you have developed and installed 32-bit MAPI applications, there are actions that you should take to change and rebuild 32-bit MAPI applications to run on a 64-bit platform, and 64-bit applications to run on a 32-bit platform.

Beginning with the Office 2010 release, Outlook is available as a 32-bit and a 64-bit application. The bitness of Outlook depends on the edition of the Windows operating system (32-bit or 64-bit) and the edition of Office 2010 (32-bit or 64-bit) that is installed on the computer, if Office is already installed on that computer.

Some of the factors that determine the feasibility of installing a 32-bit or a 64-bit version of Outlook include:

  • 32-bit Office 2010 (and 32-bit Outlook 2010) can be installed on a supported 32-bit or 64-bit edition of the Windows operating system. 64-bit Office 2010 (and 64-bit Outlook 2010) can be installed only on a supported 64-bit operating system.

  • The default installation of Office 2010 on a 64-bit edition of the Windows operating system is 32-bit Office 2010.

  • The bitness of an installed version of Outlook is always the same as the bitness of Office 2010, if Office is installed on the same computer. In other words, a 32-bit version of Outlook 2010 cannot be installed on the same computer that already has 64-bit versions of other Office 2010 applications installed, such as 64-bit Microsoft Word 2010 or 64-bit Microsoft Excel 2010. Similarly, a 64-bit version of Outlook 2010 cannot be installed on the same computer that already has 32-bit versions of other Office applications installed.

MAPI applications include standalone applications such as Microsoft Communicator and MFCMAPI, and service providers such as address book, store, and transport providers. For MAPI method and function calls to work in a MAPI application (with the exception of one Simple MAPI function, MAPISendMail), the bitness of the MAPI application must be the same as the bitness of the MAPI subsystem on the computer in which the application is targeted to run. The bitness of the MAPI subsystem, in turn, is determined by and is always the same as, the bitness of the installed version of Outlook. For information about how to prepare MAPI applications for 32-bit and 64-bit platforms, see Building MAPI Applications on 32-bit and 64-bit Platforms on the MSDN Web site.

If you are upgrading from a version of Outlook that is Microsoft Outlook 2003 or earlier, consider the following issues.

Public Folders

Public folders are optional on Microsoft Exchange Server 2007 and Microsoft Exchange Server 2010servers. If you upgrade to Exchange Server 2010 and Outlook 2010 and choose not to deploy public folders on Exchange Server 2010, any solution that uses public folders will fail. In addition, because the Organizational Forms Library is dependent on public folders, you must migrate the custom forms published in the Organizational Forms Library to a Personal Forms Library.

One-off Outlook 97-2003 Forms

In earlier versions of Outlook, it was possible to distribute a custom form over the Internet as a one-off form without having to publish it and distribute it in a public folder or Organizational Forms Library. To do so, you enabled the Send form definition with item option on the Properties tab in the Forms Designer, and then Outlook sent the form as part of an underlying Transport Neutral Encapsulation Format (TNEF) attachment. While some Internet-based servers strip the TNEF section of the messages, most servers today support it and Outlook users can receive and use the custom form. However, since Office Outlook 2007, Outlook no longer supports one-off forms sent as TNEF attachments. When Outlook converts incoming Internet messages from MIME to MAPI format, it ignores the custom form. If you are customizing forms, consider using form regions and distributing custom forms with add-ins.