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?
1. None of the MailItem.Attachment* and MailItem.BeforeAttachment* events point ot a file path when an attachment is being added.
2. Selecton collection still feels slower in OOM, even if it was significantly improved and no longer runs out of ROC channels trying to open all selected messages when ones touches any Selection property.
3. Namespace.PickFolder is no match for IExchExtCallback::ChooseFolder()
4. MailItem only exposes BeforeCheckNames, while ECE has IExchExtMessageEvents::OnCheckNames / OnCheckNamesComplete
5. ECE allows to abort submit and leave the message open, abort submit and close the editor, or let the message go through. OOM only allows 2 out of 3.
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.
Stephen Griffin is asking this question over on his blog . If you're using Exchange Client Extensions
Hi Steve.
I really need the functionality of
OnRead
OnOpen
OnOpenComplete
OnSubmit
DoCommand
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.
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.
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.
A public announcement saying Microsoft is abandoning ECE for the Add-in.
I guess that we would re-implement the product if we had to but I cannot see any good valid reason for spending a substantial amount of time for absolutely no improvement (feature-speaking).
My company does not wish to/have the budget for changing tech's just for the hell of it and the only way to allocate the money and resources would be a public announcement.
Technically speaking, we would probably be able to migrate but we would have to go through a lot of hassle since we need to keep compatibility with Outlook 2000 and upwards and the integration-part is tough as our 'paying' customers require 100% (what they think) integration in ALL environements and they do not understand nor accept any faults...so it would be a challenge...
So, was that answer enough? :-)
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.
ECE is tightly coupled to MAPI store provider.
Mike - what do you mean by that? What does ECE have to do with a store provider?
We want to know why you're still using ECEs as opposed to an add-in. Please hop over to Stephen Griffin
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.
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? :)
Exchange Client Extensions are used in Outlook to extend the functionality of Outlook.  A developer