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:
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.
I am using MFCMAPI on a clean system (without a mapi32.dll) and getting the error mentioned above.
I wanted to use exmapi32.dll without a stub. Please let me know if it is possible.
Any clean system should have a mapi32.dll as that's a system file. Using exmapi32 without the stub won't be possible until we ship a fix for this bug. I'll update the article when that happens.
A few months ago I documented a bug in the Exchange MAPI download that prevents you from loading ExMAPI32.dll