Daniel,
Using MAPI to talk to an Exchange server isn't quite the same thing as using
Outlook. If only things were so easy!
You really don't need to remind me of that ;-)
First: By MAPI do you mean Extended MAPI, CDO 1.2.1, CDOEX, OOM (Outlook
Object Model) or something else? I initially took it you meant CDOEX as that
is what you put in the subject. The page I gave is a comprehensive list that
includes samples for CDO 1.2.1, CDOEX, and OOM from both C# & VB.NET! It is
the only such list that I am aware of.
Don't forget there are multiple varieties of CDO:
- CDO 1.2.1 - which is the client side library that you can use to
supplements and/or replaces the OOM model. This is also a server side
library that is used for Exchange Event Scripts & Outlook Web Access.
- CDO for Exchange 2000 Server (CDOEX) which supplements CDO 1.2.1
- CDO for Exchange Management (CDOEXM) which supplements CDOEX
- CDO for NTS - Which is exposed via System.Web.Mail namespace
Remember that CDOEX is generally only server side and you will need to use
regular interop with it.
Remember that CDO 1.2.1 (MAPI.Session in VB) is installed with either
Exchange Server itself or with the Outlook Client. The library installed
with the Outlook client is subject to the same security prompts as the OOM.
For the most part if you have a VB example of using the library you want you
can simply cut & paste it into VB.NET, as VB.NET fully supports late
binding, however if you use it in C#, then you will need to manually do any
late binding (via reflection) that VB.NET & VB would have done for you.
If you meant Extended MAPI (IMAPISession in C++), I only know of one
Extended MAPI example for .NET, and I have not decided to release that or
not! As its is extreme pain for little gain, and it is no where near a
complete example.
I didn't think you meant Extended MAPI as Extended MAPI is not usable from
VB, without extreme pain & many C++ helper functions (which is effectively
CDO 1.2.1). I believe it would be usable from C# or VB.NET, however you
would need many helper functions based on various functions in the
System.Runtime.InteropServices namespace, however I question the real
usefulness of creating such a library. Using unsafe code from C# may reduce
the number System.Runtime.InteropServices routines, however I'm not sure
that's an advisable route ;-)
Hope this helps
Jay