Interesting post, Managed MAPI? Not today, at an Outlook Add-in blog on Business Contact Manager (BCM). Sane individuals stop reading now!

If you haven't tried this before, you may be amazed by how much source code can be reconstructed from .NET IL. With managed code, Microsoft is effectively sharing their source code with developers.

Alex notes that to write good Outlook Add-ins you pretty much have to use MAPI. Unfortunately, MAPI was written in the days of COM, and writing a MAPI provider for Outlook in managed code is not a trivial exercise. Not that writing an straight COM MAPI provider was easy. Arguably it is easier in managed code, because once you are past the inter-op layer and into pure managed code, you can change in higher gears than are possible in unmanaged C++ development.

Can anybody tell me why Microsoft creates BCM with .NET?

That's easy. A managed component will have shipped while its unmanaged component will still be stuck in debugging the inevitable memory leaks, buffer overruns, and so on.

They have a plan to include MAPI to .NET or they wish to show that no impossible for .NET?

I don't know Microsoft's plans for MAPI, but Office components are written to address market requirements, to sell stuff, and not to show or demonstrate things. And I expect that explains why BCM only implements some MAPI interfaces instead of all of them. Microsoft is only going to implement the interfaces that BCM features require and ship the product.

Now you can understand why IMAPISession have only 2 methods from 19 — it is really hard to code such wrappers .

Hardness apart, why would BCM implement MAPI interfaces when there isn't a feature that needs those interfaces? In a world of limited resources, they would then have to test those interfaces instead of features customers use. And they would also unnecessarily increase BCM's attack surface. Not implementing unused interfaces makes BCM more secure.  ¶ 9:34 AM