LoadLibrary when .local in app folder

[Ted]

I know that .local files will force LoadLibrary to always use the app's
folder first to see if the DLL is there, even if an absolute path was
specified. It is used for side-by-side component sharing.

My question is: is there any way to override this behaviour for specific
cases? I have a DLL in my app folder that I load at run time and I need to
be able to load one with the same name from another folder in some cases.
Unfortunately, my app has a .local file for other reasons (side-by-side COM)
so I cannot remove the .local file. I'm wondering if there's a way to force
a load from another folder on a case-by-case basis, short of renaming the
DLL in the app folder before loading.

Ted.

[Jon Reese [MS]]

Hi Ted,

No, there isn't a way around it. You have to rename a file. Note that you
have three choices: the one in your app directory, the one in the other
directory, or the .local file. Note also that you have the CreateHardLink
API at your disposal since you're running Windows 2000. That might be a
better way to "redirect" the file in the app directory to another file.

Jon Reese
Microsoft

[ This posting is provided "AS IS" with no warranties, and confers no
rights. ]

[Schorschi Decker]

That is not true. I have done this. I use a registry key value with the
path for the special DLL location, and a wrapper to the LoadLibrary
routine. When I need the 'standard' dll I just call LoadLibrary, when I
need the special one I use my wrapper routine.

Using a dynamic path value would do the same thing, just swap the module
name path between the two locations for the different DLLs.

"Jon Reese [MS]" <jre...@online.microsoft.com> wrote in message
news:ckJH1fzuBHA.1356@cpmsftngxa08...

[Jon Reese [MS]]

Hi Schorschi,

Are you sure that you've done this when there is a redirection file in the
directory? From the documentation for LoadLibrary:

>>>
Windows 2000/XP: If a path is specified and there is a redirection file for
the application, the function searches for the module in the application's
directory. If the module exists in the application's directory, the
LoadLibrary function ignores the specified path and loads the module from
the application's directory. If the module does not exist in the
application's directory, LoadLibrary loads the module from the specified
directory.
<<<

It doesn't matter if you write a wrapper function around LoadLibrary:
LoadLibrary will ignore the path and look for the file in the application's
directory. I suppose that you could hard-link the file to a unique
filename and then LoadLibrary that new file, but it's a little inefficient
and depending on the application it could introduce some subtle bugs since
it changes the DLL's name and the contents of the volume.

Jon Reese
Microsoft

[ This posting is provided "AS IS" with no warranties, and confers no
rights. ]