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:
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.
Yes, this was long time due from MAPI Guru.
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.
That's actually a great workaround and one we highly recommend.
Mapi is here to stay for a while so why don't create a real API that will work on 64bits platform.
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.
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?
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.
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.
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.
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
The only way your going to find what's likely to be OK is through testing. I've got nothing I could share.
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?
Do you support a .NET COM-Addin calling an unmanaged Add-in via some mechanism, e.g. COM Interop which then makes MAPI calls?
Pete - that wouldn't be any different. The number of layers you put between the managed code and MAPI are irrelevent.
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?