In a previous article, I noted that you could load exmapi32.dll directly and bypass the MAPI Stub Library. Good idea in theory, except for the bug.
One of the things that happens when you change the name of a binary is you break anything that depended on the old name. We thought we had found all of them, but it turns out there was one place in exmapi32 that was still looking for mapi32.dll so it could load a resource. If you had loaded the stub library and let it turn around and load exmapi32, everything would be fine. We found mapi32, and we found the resource we needed. But if you didn’t load mapi32, if you loaded exmapi32 directly, then we don’t get our resource, and things fall apart from there.
You can see the problem yourself using MFCMAPI:
- Get MFCMAPI: http://codeplex.com/mfcmapi
- Session/Load MAPI, and enter the path to exmapi32.dll on your system, such as "c:\program files\exchangemapi\EXMAPI32.DLL"
- Session/Logon and Display Stores
You’ll see that instead of being prompted to select a profile, you get an error dialog that comes straight from MAPI, despite the "Microsoft Outlook" title:
I’ve requested a fix for this and I’ll post an update if we issue one, but for now, the workaround is straightforward. You can still load exmapi32 directly and not use the stub library, but to avoid this problem, also load mapi32 into your process. Just having it loaded, even if you’re not using it, avoids the problem.
Incidentally – I use this same trick to solve other problems in MFCMAPI. Nobody’s ever asked about it though…maybe I’ll save that for another post.