Where should my application dlls be placed in clients machine?

Hello,

Currently my vb6 app is putting all dlls into the system32 folder of windows when i run my setup. But i was wondering if i should keep the dlls inside the program files itself. is there a best practice followed on this?

Thanks

DLLs and OCXs that ship as part of VB6 come with DEP files that list the location where they are meant to be installed.

Third party libraries should also come with these DEP files but lately they rarely do. In such cases there should at least be advice in the library's documentation, but when there isn't you have a few choices.

One might be to dump them unceremoniously into System32 but that really isn't a legitimate choice. Stand-alone libraries that are not part of a 3rd party application won't have an obvious install location without a DEP file, a developer install package that places them where they are meant to be installed, or some written advice.

The most obvious place for these according to the guidelines Microsoft offeres is to put them into a subfolder named for the company and possibly a subfolder under that for the specific DLL and any associated files. This folder goes under Program Files\Common Files, so on most systems this ends up being:

C:\Program Files\Common Files\<DLL maker>\<the DLL itself>

or

C:\Program Files\Common Files\<DLL maker>\<DLL package files>\<the DLL itself>

However until Windows Vista there is no automated way for an installer to obtain the localized path for the Common Files folder (on modern versions of Windows it is at FOLDERID_ProgramFilesCommon). So for safety many people build install packages to use:

C:\Program Files\<DLL maker>\<the DLL itself>

or

C:\Program Files\<DLL maker>\<DLL package files>\<the DLL itself>

The "Program Files" directory is more easily obtained via the old CSIDLs (CSIDL_PROGRAM_FILES in this case).


The only time you'd put application-specific DLLs that you have written in VB6 under the application folder is when they will never be shared by another application (or at least not another that isn't in the same application folder as part of an application suite). And even then there are very good reasons to put it into a subfolder of the app folder (such as "bin" or "libs" or something).

Sticking an ActiveX DLL next to an EXE using it risks the VB6 runtime registering it for you when first run. This can have negative side-effects if some other program on the system uses the same DLL for anything. The biggest headache is that the library gets re-registered at the new location and once you delete your application all the other uses are now broken.


So libraries pretty much all have their proper places, though working it out can be a chore if you refuse to use the PDW or Windows Installer with the VB6 Merge Modules that Microsoft supplies... or for 3rd party libraries.

Thread moved to the 'Application Deployment' forum, which is where questions about installing/distributing your software belong

thank you dilettante. that definitly gives the clear picture. the dll s which i use are very much application specific for my application and it is not being used by other apps as of now. so i hope it should be best to go to my application bin folder in Program Files. and i think it would also have less permission issues compared to putting in system32.

thanks a lot