As you know, when you install a new provider on a system, you have to update MAPISVC.INF to point it to the new provider. There are a few standard properties set during this configuration which tell MAPI where to find your DLL. One is PR_SERVICE_DLL_NAME, set in the Message Service section, and the other is PR_PROVIDER_DLL_NAME, set in the Service Provider section. For both properties, you are expected to set the name of your provider’s DLL (minus the “32” suffix"). MAPI will then load your provider by looking for it on the path.

What if the path isn’t good enough? What if, like any other modern application, you want to drop your provider over in Program Files and not dirty the path? According to the MAPI documentation, you shouldn’t be able to do that. However, it turns out that, with a few restrictions, Outlook’s MAPI can deal with full paths to MAPI providers. Outlook development has agreed to support this for Outlook 2010 and higher.

Here are the particulars:

  • When registering your provider in MAPISVC.INF, you should put the full path to the provider in PR_SERVICE_DLL_NAME and PR_PROVIDER_DLL_NAME.
  • Further, in a store provider, you will from time to time generate entry IDs using WrapStoreEntryID, which takes as a parameter the name of your provider. If you’re using full paths in MAPISVC.INF, you must use the same path in WrapStoreEntryID.
  • In both cases, this full path must be without the “32” suffix, as MAPI will continue to append it before looking for your file. So if you register the path “c:\mypath\myprovider.dll”, MAPI will try to load “c:\mypath\myprovider32.dll”.
  • Because Outlook’s MAPI was not originally designed with full paths in mind, it does this insertion of the “32” by looking for the first period in the string. This means that paths which contain other periods cannot work. So you cannot use paths such as “c:\my.groovy.path\myprovider.dll” or “c:\mypath\my.groovy.provider.dll”.
  • The path you use may be converted to and from Unicode using the code page provided by GetACP. You will see failures if you choose a path which contains characters cannot survive such a roundtrip through MultiByteToWideChar/WideCharToMultiByte.

To demonstrate this, I’ve updated the Wrapped PST sample over on Codeplex. The magic happens in MErgeWithMAPISVC and GenerateProviderPath.

Enjoy!