>That's not really necessary. A dll can be in any directory as long as the app(s) that's using it knows how to find it. There are precise rules on how an executable (app/dll/ocx) looks for a dll. These rules are explained in the Help/MSDN for LoadLibrary API function. Besides all rules, an app can open any dll from anywhere by specifing the whole path (although not recommendable).
>

That's true as long as something hasn't already loaded a .DLL that WIndows thinks will provide the necessary entrypoint; the problem comes specifically with shared components that are not self-registering. I've run into far too many problems where one application loads one version of a common .DLL, and another app, loaded after the first, expects a later version of the same .DLL to load - since the one has already loaded and is in memory, you're a bit cooked if you haven't taken care to make the correct version load first.

The problem doesn't arise if you know the behavior of the application and the libraries it references; if that's the case, the question behind this response would not have been asked.

>Vlad
>
>>.DLLs need to be present in the system path, which normally means installing them to the directry resolved as the system directory by Windows.