Per Randy’s blog post, Exchange Client Extension (ECEs) deprecation does (for Outlook 2010) matters the developers. For more information please refer the excerpts of the blog post:
“For most Outlook users, this announcement will not concern you. However, if you are a developer that uses Exchange Client Extension interfaces to build a solution in Outlook, then this deprecation is significant because you will have to redesign your solution for Microsoft Outlook 2010.
Exchange Client Extensions (ECEs) represent an extensibility feature introduced with the Microsoft Exchange client in 1995. The Exchange client was a 16-bit mail application running against the earliest versions of Exchange Server. ECEs must be written in native code, typically using C++ and relying heavily on the Messaging API (MAPI). When Outlook replaced the Exchange client, ECEs were used to extend Outlook 97-98 until COM Add-ins replaced ECEs in Outlook 2000 as the primary extensibility technology for Outlook.
ECEs will continue to operate as expected in Outlook 2007 and earlier. However, ECEs will not load in 32-bit and 64-bit versions of Outlook 2010. Outlook 2010 has converted its own ECEs such as Delegate Access, Deleted Items Recovery, Exchange Extensions commands, and Exchange Extensions property pages to native Outlook code.
To redesign your solution, you should consider the following options:
- Rewrite your ECE as a COM Add-in using native or managed code. Unlike ECEs, an add-in represents a strategic extensibility technology that is fully supported in Outlook 2010. Using an Outlook add-in, you can build Outlook form regions and extend the Office Fluent User Interface. For additional information, please visit the Outlook Developer Portal on MSDN.
- Rewrite your ECE as a Windows service application using native code and MAPI. If you are writing a Windows service application, you must use MAPI to access Outlook items rather than the Outlook object model. ”