MAPI SP Installation with Outlook 2007

[pete rowland]

I have a problem installing a MAPI SP with Outlook 12. In previous versions
of Outlook I have installed into %program files%\common\system\msmapi\<lcid>
with no problem. This does not work with OL12, presumably because the CWD is
no longer set to this folder.

I can force it to work by adding the install folder to the to the path, or
by installing to the Office binary folder. MS support have advised me that
this is the correct thing to do, but I can’t help but feel that this is not
correct, and have not seen any documentation such as a KB article.

Has anyone else encountered this problem ? Or, doed anyone know of any
official documentation?

Thanks
Pete Rowland

BTW specifying the full path in mapisvc.inf.... i.e.
PR_SERVICE_DLL_NAME=..\<lcid>\BJMKFR.DLL does not work)
(was posted originally on AddIn group.. )

[Dmitry Streblechenko]

Why do you need to install to that folder?
You can use folder names in PR_SERVICE_DLL_NAME, just make sure it is a
short path with no spaces - MAPI had a problem with spaces in folder names
since Outlook 97...

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"pete rowland" <peter...@discussions.microsoft.com> wrote in message
news:3A1A2146-770F-452E...@microsoft.com...

[pete rowland]

Hi Dmitry,
I don't want to install to the Office folder, and have not done so in the
past. It sounds like bad practice, but its what was recommended to me by MS.

I have installed to %program files%\common\system\msmapi\<lcid> with
previous versions of Outlook, with no problem, this however does not work
with OL12.

As I mentioned in the post I had tried specifying the path in
PR_SERVICE_DLL_NAME, but it did not work for me. I had wondered if the path
got mangled, so I used filemon to spy on outlook, and sure enough OL12 found
my service dll (no space/name issues), but could not find my supporting
dll… all Outlook appears to do is to search the current path for the support
DLL, i.e. current folder (OL12 binary), ‘system path’, and then ‘user path’.
I wondered whether there was a bug here in that the ‘algorithm’ should try
the pr_service_dll_name path too, as this indicates the mapi sp installation
folder.

Thanks
Pete Rowland

[Stephen Griffin [MSFT]]

Outlook's not the one loading your support DLL. You're either loading the
support DLL explicitly or you're relying on a load time dependency (which is
not good). When you load DLLs explicitly, you can provide path information.
I'd suggest storing your installation path in the registry somewhere and
using this information in your LoadLibrary call.

"pete rowland" <peter...@discussions.microsoft.com> wrote in message

news:87D76B55-4429-45C3...@microsoft.com...

> Hi Dmitry,
> I don't want to install to the Office folder, and have not done so in the
> past. It sounds like bad practice, but its what was recommended to me by
> MS.
>
> I have installed to %program files%\common\system\msmapi\<lcid> with
> previous versions of Outlook, with no problem, this however does not work
> with OL12.
>
> As I mentioned in the post I had tried specifying the path in
> PR_SERVICE_DLL_NAME, but it did not work for me. I had wondered if the
> path
> got mangled, so I used filemon to spy on outlook, and sure enough OL12
> found
> my service dll (no space/name issues), but could not find my supporting

> dll. all Outlook appears to do is to search the current path for the

[pete rowland]

Ah!.. just having a 'doh!' moment... of course I do. I guess my support dll
would have been loaded (by me :-)) in earlier versions of Outllook if
%program files%\common\system\msmapi\<lcid> was MAPI's current working folder.

Much Appreciated.
Pete Rowland

[mooingps...@gmail.com]

Is there any way around the load-time dependency issue? This seems to have gotten worse in Outlook2013, the "Mail" control panel can now appears to only load my plugin if the load-time dependent DLLs are placed in the system32 folder, which I don't want to do for obvious reasons. As far as I can tell, my options are (A) place all support dlls in system32, or (B) rewrite my add-in to use LoadLibrary. Is that correct?

[mooingps...@gmail.com]

On Tuesday, April 10, 2007 3:54:02 AM UTC-7, pete rowland wrote:
> I can force it to work by adding the install folder to the to the path, or
> by installing to the Office binary folder. MS support have advised me that
> this is the correct thing to do, but I can’t help but feel that this is not
> correct, and have not seen any documentation such as a KB article.

With Outlook 2013 the problem is worse, it won't even use the path unless you mark the dependant DLLs as delay-loaded when you link them to the main dll.