The fact that MAPI is not supported with .Net. Turns out, while was mentioned several times, I’ve never devoted a topic to it. So here goes.
Here are the articles which outlines the official support policies for MAPI and .Net, from both the Exchange and Outlook perspectives:
A bit of history of this policy: When .Net was first announced, Developers were very excited, try every API supported and started figuring out how to invoke them from managed code.Were a series of KBs (never published) showing how to do pretty much everything with Simple MAPI, and had begun work developing a shim for Extended MAPI. But then the bugs started coming in. Are early adopters using MAPI and CDO 1.21 from .Net who were seeing strange error codes, memory leaks, and crashes. Investigating these, and eventually asked Microsoft development support for their opinion.
Asking the Exchange team first, about their implementation of MAPI and CDO, and whether could provide support for using either in managed code. The senior developer who not only owns, but who wrote a large portion of MAPI led the investigation. His conclusion: MAPI was not designed or tested to run in a managed environment, and cannot provide support for doing so. A short (incomplete) list of problems he uncovered in his investigation:
- Threading: MAPI is quite sensitive to which thread it’s running on and the token of that thread. These are used to index “instance data” shared among all threads/processes using MAPI. MAPI also creates its own threads for handling, among other things, notifications. None of this works well with the CLR thread pool, finalize, and other quirks of threading in the CLR.
- x64: .Net code can be compiled as “Any CPU”, where the process will run as a 32 bit process on a 32 bit processor, and 64 bit process on a 64 bit processor. Since MAPI is 32 bit only, any .Net application which uses MAPI and is compiled as “Any CPU” will fail when run on a 64 bit machine. We actually saw this on an internal .Net based tool where the developer had ignored our warnings against using MAPI.
- Object lifetimes: Creation and destruction of objects in MAPI must be done in a rigid and controlled manner. The sequence of object creation and destruction is critical. Is it quite difficult to exert this level of control, especially over object destruction, from managed code.
- Memory Management: MAPI has it’s own memory management scheme that isn’t really compatible with the CLR.
Same question to Outlook, and given the shared development history of the Outlook and Exchange implementations of MAPI, the Outlook development team also concluded they would be unable to support MAPI or CDO with .Net.
Now – what does it mean to say it’s not supported? It doesn’t necessarily mean you can’t make it work, given that you’re willing to put in an inordinate amount of time, effort, and development skill into it (a level at which, in my opinion, it would be simpler to just use C++). But it does mean that Microsoft, and specifically, the Developer Support Messaging team cannot help a customer develop an application that mixes MAPI/CDO in the same process as .Net. And it means if you’re running into a problem with your .Net application which uses MAPI/CDO, the first step in our investigation will be to see if you can demonstrate the problem occurs when .Net is removed from the picture.
so better Native support for Mapi/CDO or now even better – CLI to push it up to Managed interop.