Partilhar via

Putting a Path in MAPISVC.INF

  • Artigo

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:mypathmyprovider.dll”, MAPI will try to load “c:mypathmyprovider32.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.pathmyprovider.dll” or “c:mypathmy.groovy.provider.dll”. Update:  this was fixed in Outlook 2013 (https://support.microsoft.com/kb/2817503) and Outlook 2010 (https://support.microsoft.com/kb/2760764).
  • 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!

Comments

  • Anonymous
    April 19, 2016
    The comment has been removed
  • Anonymous
    April 19, 2016
    When you are testing your project in Visual Studio, you might like to include this Post Build Event in your project properties :rundll32 $(TargetPath) MergeWithMAPISVCNow when you build your project, the entries in MAPISVC.INF will refresh automatically. I realise that the MAPISVC.INF file will not normally change. This step can be very helpful if you are using SVN with multiple development machines. Now you don't have to wonder if MAPISVC.INF is correct for the current project version. Building the project will tidy that up for you.(Note: Outlook will look for your Provider DLL in your project Debug output folder when you use %targetpath%)Please be careful if you are also testing a setup program with your Provider.Once the provider has been installed in Outlook, Outlook will load the DLL file that was copied in from MAPISVC.INF.If you use MergeWithMAPISVC and update the path to the DLL file, this is not automatically updated into the Outlook profile.You should remove the Provider within Outlook (which requires an application restart) then when you re-add the provider, the updated path in MAPISVC.inf will be used. This is particularly important if you want the Visual Studio debugger to be triggered on breakpoints in the Provider code.(These comments are based on personal experience so please forgive any incorrect phrases as I am an end-user of MAPI.)
  • Anonymous
    April 19, 2016
    The comment has been removed