Re: Calling MAPI from C++/CLI

As of Outlook 2002, I can't think of anything you cannot do in a COM addin
but can in an ECE.
And you can of course always resort in MAPI from a COM addin through one of
the MAPIOBJECT properties.

If you have a perfectly working ECE, I don't see a reason to rewrite it just
for the fun of it. But if you switch to managed C++, that's what you'd end
up doing anyway.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Dave Smith" <Dave@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:OrA5cmeTGHA.4616@xxxxxxxxxxxxxxxxxxxxxxx
OK, I understand that "calling MAPI from managed code" (whatever that
means in the real world) is 100% unsupported. I am not complaining here. I
understand that the world moves on.

But, you seem to be saying that ECE's have been deprecated and totally
replaced by Outlook COM addins. So I should be spending my time removing
all trace of my existing ECE and rewriting everything as one or more
Outlook COM addins? (Yes, I do not support anything older that
Windows/Office 2000 and am considering moving this up to XP in the next
version.) Can I burn my copies of "Inside MAPI" and "Writing Exchange
Extension Clients in Visual C++?" (Of course, I exaggerate. Used copies of
"Inside MAPI" are still selling for around $200 on Amazon.)

Dave Smith

"Dmitry Streblechenko" <dmitry@xxxxxxxxxxx> wrote in message
news:Oggiq5dTGHA.736@xxxxxxxxxxxxxxxxxxxxxxx
No, but OutlookSpy is written in (unmanaged) Delphi and it needs to be an
ECE since it is supposed to work in all versions of Outlook and Windows,
uncluding Outlook 97 and Windows 95. COM addins only work in Outlook 2000
and up.
Since you are going to use .Net, what are the chances that your users
will be using anything less than Outlook 2000 on Windows 2000?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Dave Smith" <Dave@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23KPPoWdTGHA.424@xxxxxxxxxxxxxxxxxxxxxxx
Dmitry,

Outlook Spy is an Exchange Client Extension, as I understand things. Are
you saying that it should be completely rewritten as a COM add-in for
.NET?

Dave Smith

"Dmitry Streblechenko" <dmitry@xxxxxxxxxxx> wrote in message
news:%23FzN4BdTGHA.5044@xxxxxxxxxxxxxxxxxxxxxxx
Why would you want to implement an Exchange Client Extension in .Net
(which is unsupported 100%) instead of writing a COM addin (which is
supported) that resorts to MAPI only when it really needs to?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Dave Smith" <Dave@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:enni9ybTGHA.4520@xxxxxxxxxxxxxxxxxxxxxxx
Russell,

First, thank you for taking the time to write up a thorough response
to my question. I think it has turned on the light bulb in my brain,
and I want to ask for this one further piece of clarification.

You said in your reply, "MAPI is not supported in any way if it is
linked with managed code..." I read that to mean, if MAPI32.dll is
"referenced" (i.e., in the input library list to the linker) in a .NET
module, then no support. So, in my mind, this means that I will need
to create a separate DLL (as you suggest) which is linked against
MAPI32.dll and marshal calls from my main, managed-code Outlook
extension module, which is *not* linked against MAPI32.dll, to this
unmanged module.

The whole process starts when Outlook loads my dll and calls the
ExchEntryPoint method, which is supposed to return to Outlook a COM
object that implements the IExchExt interface. I assume, since this
does not require calling any methods implemented inside of MAPI32.dll,
that I can do this from managed code. As I implement the methods of
this (and other MAPI interfaces) within my managed code module, I will
need to defer any operations that require methods implemented in
MAPI32.dll to my unmanaged module.

So, as I see things now, the key is which module actually references
(links against) MAPI32.dll. If I am correct, I think that was the
piece of information I was missing.

Again, thank you.

Dave Smith

"Russell Mangel" <russell@xxxxxxxxx> wrote in message
news:e8I8jFVTGHA.1576@xxxxxxxxxxxxxxxxxxxxxxx
"Dave Smith" <Dave@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:eq0AozPTGHA.4952@xxxxxxxxxxxxxxxxxxxxxxx
I thought that this was a rather focused, narrowly scoped question;
however, I have received no feedback,

First the bad news..., good news is at the end ;)

Understand that I do not work for Microsoft, and so all of my
information
is simply my opinion, and so here goes.Yes your question was narrowly
focused,
and I think you already know why you have received no reply's. MAPI
is not
supported in any way if it is linked with managed code, there are no
exceptions
here. You are obviously aware of the power of the new C++/CLI and you
want to
use it with MAPI, and so do I. As far as I know, MAPI is the only
native MS API
that is not supported when doing Interop & Marshaling with C++/CLI
and other
.NET languages. Is this so bad, I don't think so. C++/CLI is the most
powerful
.NET language, period.

I firmly believe that it is impossible (in a full featured Outlook
client extension) to completely avoid MAPI.

I agree with you. You will find the limits of OOM quickly.


So, I want to segregate those MAPI calls into an "unamaged" section
of my application. Now I have a partner on this project who claims
that the new C++/CLI language (in VS2005) gets around this
limitation by "letting" you call unmanaged code directly from
managed code. It is my understanding that you could always call
unmanaged code from managed C++, but there was still the limitation
against calling methods of the MAPI interfaces. As I understand
C++/CLI it is mostly syntactic sugar to simplify creating and
calling managed objects, such as the ^ operator in the place of __gc
pointers.

If I am right, then the question ariises, "How segregated does my
MAPI code have to be from my managed code?" Can I put them in the
same source code file but just create __nogc objects, interfaces,
etc, to be used by the MAPI calls? Or do I need to build a separate
compilation unit (library) for this MAPI code? If so, can that
separate library be statically linked to my managed code or must it
be a DLL module?

You are supposed to be asking question's about MAPI in this
newsgroup. Look
at the previous questions again, you are asking the Exchange
messaging group about
how to organize a C++/CLI project for Interop/Marshaling. Which
requires
special knowledge how to Marshal Managed->Native data and
Native-Managed data.
This is one of the most difficult areas of programming, welcome to
major-leagues.

So the question is. What should you do?

<Warning BeginEncryption>
The following information is encrypted and will be unreadable by any
Microsoft
Employee's and Contractors.
</Warning BeginEncryption>

First, just accept the fact that Microsoft typed the words
"unsupported" near
the words MAPI and .NET as they are just characters. 514 Years ago,
people were
typing the words "the earth is flat" go there and you die! Lucky for
us,
Mr. Columbus could not read and pressed on to discover the America's.
However,
before you set sail... be warned that the weather can get really
rough!

Here are some of my thoughts, listed in order of importance.

Do not write anything you don't need, write the simplest thing that
will solve
the problem. I know this is old advice, but I still see far too many
people
writing un-needed libraries, when they should focusing on "the
simplest thing that will work".
Stay out of MAPI as much as you can, try to find the data elsewhere,
lean on
Active Directory and other .net base class libraries. Example, don't
use MAPI
to get the GAL list, hit the directory using LDAP instead. Prefer
LDAP to ADSI
See System.DirectoryServices.Protocols.LdapConnection. This is an
awesome namespace.
If you need to check/set security on mailboxes, hit the directory
with LDAP. You
can use the new System.Security namespace to change/check the
Security on any
active directory object. The new Security namespace allows mere
mortals to
set security. Do anything to stay out of MAPI.

Now that you have your 10 MAPI methods that you must have:
How do I organize my C++/CLI project to support mixed code and mapi?
Good question, there are at least five ways to do this. The easiest
is to create
one managed dll and mix everything together. Your .net clients can
now reference
this dll. I think this is also the poorest solution. Because you will
end up with
code that resembles nothing in the real world, and worse if run into
one of the
problems that Microsoft warned you about. No one will be able to help
you.

I suggest the following.
Create an Un-managed .lib or .dll project, and write all of your MAPI
code
in standard C/C++, this could be just methods, or C++ classes if you
like.
Then create another Managed .dll project and reference the previous
lib or .dll.
This second .dll will basically be where all of your marshaling will
take place.
The managed class that you expose to your .net clients will be all
that is visible
to them. The .net clients simply reference the second managed .dll.
Typically this
managed C++ class is just a thin wrapper around your native MAPI
method calls. Example:
Suppose that you have a Un-Managed MAPI method called Profiles*
GetProfiles(LPTSTR profileName)
and you want to expose this to your .net clients. You would add a
managed method to
the managed class called array<String^>^ GetProfiles(System::String
^profileName); that passes it's input to the
un-managed method. So now you need to know how to marshal a
System.String to Char*.
Pretty easy. But since this method returns an array of strings you
will need to
marshal that array back to a Managed String array. Not too hard
either.

The previous suggestion has a several key points, that I think are
important.
First, You have cleanly separated your MAPI Un-Managed Code from your
Managed code.
Since you have an Un-Managed library you can test/debug your
mis-behaving Un-Managed
MAPI code using an un-managed client, just like the old days.
Additionally, You now have
a legitimate license for support because this part of your
application is supported
by Microsoft. You can say, yes, I am using Visual Studio 2005
(un-Managed C++ against
Extended MAPI, of course!) all the MS talent there will be glad to
help you.(ssssh!)

Okay, Okay, Now you have trouble with your second .dll and you don't
know how to
marshal some nasty data structure from MAPI Un-Managed to .NET
Managed and vice versa.
Pretty easy, I think. First, don't ask your question in the Messaging
group. Think...
Which Microsoft Newsgroup does handle C++/CLI Interop. Once you find
that newsgroup
read through the newsgroup and find another Microsoft API that has
similar data signatures
that is supported. And then ask your question there, no need to
mention MAPI, as you are
dealing a with data structure. Bingo, you got help, and you can now
pass data between
your marshaling class.

Okay, Okay, Now when I run my application and it crashes, at 2:30pm
on Sunday, but only
for customers who have IBM pc XT's in their garages, and their house
is painted yellow.
Chances are, you are a terrible software engineer and a poor
programmer. Start over.

Seriously, if your application or whatever is reasonable in
complexity, I don't think
you will have these bugs that Microsoft claims to exist. I think most
if not all of these
problems could be traced back to poor design and programmers trying
to write things that
they are not capable of writing properly. If your application needs
to multi-thread using MAPI you
will need to be especially careful with that. As from what I
understand this is potentially
one area which may have some issues with mixed code. I can not offer
any advice in this area.

One last thing.
You may or may not have heard of a .NET utility called MAPI33.
http://www.mapi33.adexsolutions.com/
It is written in Managed C++ 1.1 .net. The person or company that
wrote this has obviously overcome
most if not all MAPI issues. I have used the library and it seems to
work nicely. I tested it using C#
I don't think VB.NET is supported because of it's inability to
address UInt32. If your company
has the means, you can buy the source code for $1000.00, I'll bet you
could find all of your
marshaling questions in there. But possibly the best reason of all
for buying even just the
component without source code (much cheaper), is that you can use
this library to model
your application first. It might even be good enough for you that you
could use it in production. If
you do this, you should definitely buy the source code for it.

Good Luck

Russell Mangel
Las Vegas, NV

<Warning EndEncryption>
End of message
</Warning EndEncryption>






























.

Relevant Pages

  • Re: Calling MAPI from C++/CLI
    ... DLL which is linked against MAPI32.dll and marshal calls ... from my main, managed-code Outlook extension module, which is *not* linked ... As I implement the methods of this (and other MAPI ... Understand that I do not work for Microsoft, and so all of my information ...
    (microsoft.public.win32.programmer.messaging)
  • Re: Calling MAPI from C++/CLI
    ... supported) that resorts to MAPI only when it really needs to? ... DLL which is linked against MAPI32.dll and marshal calls ... from my main, managed-code Outlook extension module, which is *not* ... Your .net clients can now ...
    (microsoft.public.win32.programmer.messaging)
  • Re: Calling MAPI from C++/CLI
    ... ECE since it is supposed to work in all versions of Outlook and Windows, ... supported) that resorts to MAPI only when it really needs to? ... MAPI32.dll and marshal calls from my main, managed-code Outlook ... The whole process starts when Outlook loads my dll and calls the ...
    (microsoft.public.win32.programmer.messaging)
  • Re: How to replace an attachment from a file.wav to a winmail.dat
    ... And it will not have Outlook installed on. ... when the code tries to convert back from MAPI to MIME using the ... we created one stream object with the contents of the file using the ... and we created the new tnef stream using the OpenTnefStreamEx ...
    (microsoft.public.win32.programmer.messaging)
  • Re: What is next step to extracting PST contact items
    ... IMO mode doesn't really support Extended MAPI. ... We cut IMO mode in Outlook 2002. ... and MAPI Developer Tool ... An unexpected error has occurred. ...
    (microsoft.public.win32.programmer.messaging)
Loading