It's just a day of cool fixes. For months now, people have been bugging me about the fact that MAPIFindNext doesn't work in Vista. I knew we had a fix in the works, but I wasn't able to give any more details than that.
Well, the wait is over - this issue has been fixed: http://support.microsoft.com/kb/939718.
Those who look closely at the fix will notice that the file getting the fix is rpcrt4.dll, not in MAPI. What had happened was portions of the code for marshalling parameters across process boundaries was rewritten in Vista. In doing this rewriting, a very obscure corner case was handled improperly, causing the marshalling to fail. The Windows Mail implementation of MAPIFindNext just happened to reliably hit that corner case.
The fix of course was to make sure that case was handled, and now Simple MAPI works in Vista. Enjoy!
MAPI Editor Source:
One year is gone....
We are waiting....
Don't lose heart - I had some other priorities that took my time.
Why do we always have to waste time calling MS to get these patches!!!!!
The fix should be in SP1. You could wait until then. :)
I still can not get MAPI running with Vista (Home Basic) even if I installed SP1. It always returns MAPI_E_FAILURE. Could you suggest what I can do to solve this problem please?!
What's your version of rpcrt4.dll?
Thanks for your answer; rpcrt4.dll version is 6.0.6001.180000.
AFAIK, that version should have the fix. You must be seeing a different problem. Does your code work on XP?
Hi, yes on Xp (SP2 or SP3) it works always. Today I tried it on 3 PCs with Vista SP1: two of them are Vista Home and one is Vista Business. On Vista Home I always get MAPI_E_FAILURE, on Vista Business it works perfectly!Do you have any suggestion for me?I will be very grateful to you.
I am having simlar problem, but not exactly the same... and hoping if you have any pointers.
When I call MAPISendMail while outlook is open it fails on windows XP, but succeeds when it is not open (or when express is default mail)
What makes things difficult is that my app is a fully trusted XBAP, when I call the exact code from a windows forms app it works perfectly fine. I am thinking it could be related to security context... but not entirely sure.
I have searched everywhere and tried every workaround I can think of... so any pointers would be appreciated.
It seems that it has indeed something to do with restricted vs. unrestricted token. It works on Win7 if both OL and the Client App are running with an restricted token. If I start the client app elevanted, it does not work and produces MAPI_E_FAILURE, unless OL is closed.
Nice simple API anyway ... it produces issues since 2007 that are not fixed within three years. Is this the reason why the MSDN states "Using of these functions is discouraged"? Just have a look at google, how many people are struggeling with MAPISendMail and only getting back MAPI_E_FAILURE.
The Outlook 2003 SP 3 MAPI Client loads DLLs from the current directory. This is considered a security flaw (see www.microsoft.com/.../2269637.mspx) and it is one possible reason for this problem. We found that using the SetDllDirectory() function as recommended causes MAPI_E_FALIURE with the Outlook 2003 SP 3 MAPI client. Particularly, the client fails to locate OUTEX.DLL.
Furthermore, it's worth mentioning, that Outlook 2010 does not have this problem anymore.
I can confirm this issue.
When using Outlook 2003 SP3, MapiSendMail returns MAPI_E_FAILURE if it is called with the MAPI_DIALOG flag and the calling application has removed the current directory from the library search path via SetDllDirectory(""). However, without MAPI_DIALOG, the email gets sent successfully after a security dialog is displayed to the user.
Outlook 2010 doesn't have this problem anymore.