MAPI and .Net

Working with a customer the other day, I went looking for my blog post discussing the fact that MAPI is not supported with .Net. Turns out, while I’ve mentioned it several times, I’ve never devoted a topic to it. So here goes.

Here are the articles which outlines our official support policies for MAPI and .Net, from both the Exchange and Outlook perspectives:

Support policy for Microsoft Exchange APIs with the .NET Framework applications

Support policy for Outlook APIs that are used in the .NET Framework environment

A bit of history of this policy: When .Net was first announced, we (in Developer Support) were very excited. We took every API we supported and started figuring out how to invoke them from managed code. I myself wrote 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. We had early adopters using MAPI and CDO 1.21 from .Net who were seeing strange error codes, memory leaks, and crashes. We started investigating these, and eventually asked development for their opinion.

We went to the Exchange team first, to ask about their implementation of MAPI and CDO, and whether we 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 we 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, finalizer, 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.

We took the 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.

None of this is new information. Matt even wrote a similar article a couple years ago in which he discusses some of the alternatives. But given the surprised response I get from developers whenever I explain our support policy, I figure it was worth repeating.

Comments

• Anonymous
  April 03, 2009
  Yes, this was long time due from MAPI Guru.

• Anonymous
  April 03, 2009
  The not-ideal way we found around this was to write an unmanaged (VB6 or C++) Activex exe and get that to do all the CDO/MAPI work. It can (I hope) safely be called from .Net as it runs in a different process - although you should not have MAPI types exposed in the interface. The Outlook/Exchange API situation is a real mess for .Net developers although the web services in Exchange will start to help over time.

• Anonymous
  April 03, 2009
  That's actually a great workaround and one we highly recommend.

• Anonymous
  April 03, 2009
  Mapi is here to stay for a while so why don't create a real API that will work on 64bits platform.

• Anonymous
  April 03, 2009
  Given your perspective and insights, do you see MAPI and its current implementation living for a long time?  While it is a supremely flexible specification (which I am a huge fan of) its current implementation is becoming antiquated as exemplified by this article. Which begs the next question, how does the developer community get insight into the future aside from the press.

• Anonymous
  May 27, 2009
  As I know MAPI is only option for message store provider. If I have a message store provider loaded in Outlook, then I could not create any COM Addin using VSTO. If that happens, both MAPI and managed code are loaded in same Outlook process. Does Outlook use MAPI interface internally all tall? Then How can managed COM addin be used in Outlook?

• Anonymous
  May 27, 2009
  Outlook supports COM Addins built using VSTO. Those COM Addins are free to use the Outlook Object Model. We would not support those add-ins calling directly into MAPI though.

• Anonymous
  May 27, 2009
  Thanks for your clarification. But in Matt's article referenced in your original post, it states: "we don't support any scenario of CDO 1.21 or MAPI being loaded in the same process as the CLR." It looks like the problem is not MAPI and managed code in the same process, but the direct call from managed code to MAPI. However if I have a managed COM  Addin which access OOM, evantually OOM will make MAPI calls to access message store provider internally, which all happen in a same process. This scenario works perfect in Outlook as it is. It looks like to me that managed code can call MAPI without any negative impact INDIRECTLY. Is that true? If that is the case, the supported/not supported conditions should be further defined. There are implementations of managed/MAPI bridge out there. Maybe some of the implementations are safe, if the conditions are clearly defined.

• Anonymous
  May 27, 2009
  The existance of Outlook and the fact that Outlook itself uses MAPI does not change our support policy. We do not support .Net applications which use MAPI and we do not support .Net based add-ins calling MAPI. We do support .Net applications and addins calling into the Outlook Object Model. You can debate the logic all you want, but the question here is the support policy, not what may or may not work if you're willing to put enough time, effort, or development skill into it.

• Anonymous
  August 28, 2009
  Stephen, jh does make an interesting point and one I've often thought about myself. Obviously .Net and MAPI can co-exist if you know what you're doing and know which bits of MAPI are ok and which are not. Whilst we must accept that Microsoft do not support MAPI calls in .Net is there any way of getting more information on what particular call are likely to be OK or you definitely know are problematic? For example just knowing that updating and reading properties is stable would be of huge benefit (In OL2007 we have PropertyAccessor but it's very difficult writing a solution supporting OL2003 as well). It would be very helpful to have any information on what you think/know is OK and what you think is not even it comes with big warning signs, no guarantee and no support. I realise this is tricky ground 'politically'. LJ

• Anonymous
  August 28, 2009
  The only way your going to find what's likely to be OK is through testing. I've got nothing I could share.

• Anonymous
  September 01, 2009
  Clearly there should be a supported version of MAPI32.DLL for Win 32 applications, a supported version of MAPI64.DLL for Win 64 applications, and a supported version of MAPI .NET (wherever the CLR is sold) for .NET applications. Now, what other unanswered questions to you have?

• Anonymous
  November 16, 2009
  Do you support a .NET COM-Addin calling an unmanaged Add-in via some mechanism, e.g. COM Interop which then makes MAPI calls?

• Anonymous
  November 16, 2009
  Pete - that wouldn't be any different. The number of layers you put between the managed code and MAPI are irrelevent.

• Anonymous
  November 19, 2009
  Hello Stephen, I have a question regarding the MAPI I have downloaded an application that uses some of the functions of MAPI32.dll using DllImport. for example : [DllImport( "MAPI32.DLL")] private static extern int MAPISendMail( IntPtr sess, IntPtr hwnd,MapiMessage message,int flg, int rsv ); but when i try to send emails i get the following messagebox indicating that "A program is trying to send an email-message on your behalf...." is it possible to avoid this message to appear? also, another question is - does outlook redemption is ok for using Mapi for .net (it is a regular com - if i understand correctly) and you said that it doesnt matter and it will always be problematic to use .net and mapi in the same time (even if their is the com layer in between?) is this correct?

• Anonymous
  February 13, 2010
  Stephan Nice post. But MS contradicts on the use of MAPI. Using reflector API, my team found that Exchange 2007 Web Serviceas internally uses MAPI and a variation of RPC so although generally speaking .NET integration is not supposed but we have successfully used it on x86 and x64 (although in 32 bit process) Despite various means such as WebDAV, WS, now REST and other mechanisms available to connect to Exchange, lets be practical - MAPI is still the best protocol for sophisticated systems integration regards -Shahbaz

• Anonymous
  February 13, 2010
  You misinterpret what you see with Reflector. None of the MAPI client binaries (which are the issue here) are used by Exchange 2007 Web Services. If you want to bypass the MAPI client binaries and use the underlying RPC Rops directly, you're free to do so - consult the Exchange Protocol docs.