April, 2009

Get it here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=B444BF18-79EA-46C6-8A81-9DB49B4AB6E5

Jason Nelson has an interesting article up on the EHLO blog discussing MAPI named properties in Exchange. Specifically, he covers the history and reasons behind x-headers, how they’ve been handled in the past, and how we’ll be handling them in an upcoming rollup for Exchange 2007, and later, in Exchange 14.

Addressing a couple of the comments to his article:

Q: Is there any reason why the properties couldn't be at a per-message (or equivalent) level? Perhaps not as efficient, but if you're going to redesign it, why not allow 32K props per message?

A: Because this would break everything. Every client that ever connects to Exchange would be broken.

Q: Or why not store all the unknown x-headers in a text field that is always attached to PropID 0xFFFF?

A: They always have been – they’re in PR_TRANSPORT_MESSAGE_HEADERS, which any app is free to parse. No data is being lost here.

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.