Whither ECE?
This is a question for those of you out there who still have Exchange Client Extensions.
Aside from budget concerns and legacy support, what blocks you from re-implementing your extension as an Outlook Add-In? Specifically, I'm looking for events and capabilites that would have to be added to the Outlook Object Model to allow you to migrate your code.
For example, ECEs have an OnRead event that happens before Outlook reads from a message. This allows the extension to modify the message first. The OOM's Read event happens after Outlook reads from the message, so it's too late. You would need some sort of BeforeRead event to match the ECE.
Can you come up with more? I've got a list I put together here, but I want to see what you folks have actually run up against, so I'm most interested in real world examples drawn from your own code. Thanks!
[Update: 11/21/27]
Welcome viewers from Patrick and Randy's blog! I've seen a few comments that indicate support for legacy clients is a major concern. We definitely understand that and it's on our list. But what we're looking for here is things that you're doing with ECEs right now that you cannot do with Add-Ins. To put it another way - if ECEs suddenly vanished and you had to implement your code in an Add-In, what missing features or capabilities would be showstoppers?
Comments
Anonymous
October 12, 2007
The comment has been removedAnonymous
October 12, 2007
Event notifications is extremely unreliable. If there are more than 64 events (I believe that is the threshold, I don't have my book near right now) on a single object, they get reduce to "Something Changed" event and you have to try to guess what exactly has been changed.Anonymous
October 12, 2007
Stephen Griffin is asking this question over on his blog . If you're using Exchange Client ExtensionsAnonymous
October 12, 2007
Hi Steve. I really need the functionality of OnRead OnOpen OnOpenComplete OnSubmit DoCommandAnonymous
October 12, 2007
My code depends on ECE's functionality of OnSubmit returning S_FALSE ( to let Outlook submit item ), S_OK ( Submit is processed by the client- do not touch ), E_FAIL - the Inspector comes back up... This is critical for the clients because the processed-by-me message should not go to Exchange. If I were to use COM AddIn, it gives me only 2 options ( S_OK - passes to Exchange ) or E_FAIL - inspector comes back up. I also Depend on OnSubmit & OnSubmitComplete. When I get OnSubmitComplete ( and I returned S_OK from ECE's OnSubmit to prevent Outlook from doing anything with the message ), I am free to delete the message ( or do whatever else I want ). With MailItem.Send event ( OOM ), this is not the case - the message is locked for the duration of Send event. In OOM, once I touch an item - Submit status is cancelled ( with the exception of getting "Submitted" property ). ECE allows me to examine an IMessage ( e.g., in OnSelectionChange ) without cancelling Submit. This is handy in cached mode. For parity, I'd want a way to get IMessage from OOM without cancelling Submit status.Anonymous
October 13, 2007
Outlook Object Model does not give access to the raw message source when the message is an S/MIME message. Also creating your own S/MIME message is not possible with the Outlook object model.Anonymous
October 15, 2007
I think that it is safe to say that there are really good reasons to expose the same event notifications in OOM as existed in ECE. I'm searching code that is important to our product that I've "inherited" and so I don't know it's ins and outs real well but I know we use OnRead, OnReadComplete, OnSubmit, OnSubmitComplete, OnWrite, OnWriteComplete, and several others. The OnRead notification is crucial - being able to fix up a message before the user sees it is why we have the ECE application.Anonymous
October 15, 2007
The comment has been removedAnonymous
October 16, 2007
There does not seem to be the equivalent to the Exchange Client Custom Action in an Outlook Add-In. Supporting Custom Actions for Outlook Rules is the only place in our application where it is not implemented as an Outlook Add-In.Anonymous
October 25, 2007
ECE is tightly coupled to MAPI store provider.Anonymous
October 28, 2007
Mike - what do you mean by that? What does ECE have to do with a store provider?Anonymous
November 21, 2007
We want to know why you're still using ECEs as opposed to an add-in. Please hop over to Stephen GriffinAnonymous
November 21, 2007
ECES has remained the same in recent versions whilst the object model is continuously changing and thus it is difficult to program for all versions of Outlook from 2000 upwards using the latest object model technologies. Compatibility with previous versions of Outlook is a pain for all new object model technologies, especially those that have to do with .NET (signed assemblies, Office PIAS, etc), that is a difficult story to handle reliably for all versions of Outlook. Even the recent Office Addin runtime v3.0 is only for version 2007 of Office and you need to maintain multiple versions of Visual Studio to support even only Office 2003 and 2007 together. ECES is the same everywhere. You learn one thing, implement it and it works. No redistributables and different Visual Studio tools versions and whatnot and no differents between Outlook versions.Anonymous
August 08, 2008
I'm also forced into an ECE due to attachment handling support needed. IExchExtAttachedFileEvents::OnOpenSzFile does NOT fire when an .ecf file is used, but it IS fired when the registry entry is used - but only for mail items, not for tasks. This method is one of the "before" events are fired to the ECE (and we have the S_OK to deal with the attachment itself) and does not have an equivalent in OL <= 2003, correct? OL just fires AttachmentRead event (I think BeforeAttachmentWriteToTempFile is the way to go in an addin, but only from OL 2007 and up...), which is a postmortem event. If the OOM will fully replace ECEs... then you're 100% right. And still there are places where, without MAPI(x), you're stucked. So? Do we see the day when OOM will be the way? :)Anonymous
October 15, 2008
Exchange Client Extensions are used in Outlook to extend the functionality of Outlook.  A developerAnonymous
October 22, 2008
I recently worked on an issue where the customer was getting this error message when attempting to export