Hi,
i'm useing the install shield for vc++ 6.0, and i can't install a shared dll like the mfc40.dll.... know anyone how i can do this???
Thanks in advance,
Diego
Printable View
Hi,
i'm useing the install shield for vc++ 6.0, and i can't install a shared dll like the mfc40.dll.... know anyone how i can do this???
Thanks in advance,
Diego
If I did not know if the target machine has had the same version of mfc DLL, I usually put it in the application directory, and the application will use the the file.
I am not sure what you mean by shared mfc dll, is it shared by your app(s) or is it shared by your app(s) and some other applications?
Hope this can call some other suggestions.
csheng
Usually, you must not redistribute the release versions of MFC DLLs (as mfc40.dll),
because they are already in the system directory since the OS install.
Although, in case it's necessary (e.g. mfc70.dll or msvcr70.dll),
better is to put them in the application directory, as csheng already said.
I agree on the idea that the best way is to copy the necessary DLLs in the current folder of the application. That's guarateed that the DLL from the app. directory will be used when using the LoadLibrary() function.
However I do not agree with the idea , I quote: "Usually, you must not redistribute the release versions of MFC DLLs (as mfc40.dll),
because they are already in the system directory since the OS install." I built many installation kits and on older OS'es, especially when the OS is freshly installed, U DO NOT HAVE MFC40.DLL installed.
I have a suggestion however to make your work easier. I use InstallShield 6.3 which is coming with a bunch of predefined objects: OLE DB, MFC 6.2, ODBC 3.51 that u can insert them in the project. Those objects will do the painful work that u normally do: check the version of MFC40.DLL for example, deciding if it replaces it or not , registering it , etc.
Actually u create first a component and in that component u insert the object that u want. The objects are installing a certain technology as u may see in the explenations before. All your responsability is then to check the errors that can occur during the installation, but this can be done easily. In addition to that the InstallShield 6.3 is event based, so that u can split logically the actions.
RATE ME OR HATE ME
This is not always true. Search for SafeDLLSearchMode in MSDN. Granted, it is only for newer OSs, but it should be noted...Quote:
Originally posted by nick666
I agree on the idea that the best way is to copy the necessary DLLs in the current folder of the application. That's guarateed that the DLL from the app. directory will be used when using the LoadLibrary() function.
Truly newer OS: Windows XP.Quote:
Originally posted by vicodin451
This is not always true. Search for SafeDLLSearchMode in MSDN. Granted, it is only for newer OSs, but it should be noted...
Possible will be also present in Windows Longhorn . :D
XP is already 2 years old, I might say.Quote:
Originally posted by marsh_pottaye
Truly newer OS: Windows XP.
Possible will be also present in Windows Longhorn . :D
Nonetheless, the whole blurb from MSDN (from the LoadLibrary doc), since it might appear that someone is using an older version...
The SetDllDirectory function is also mentioned.Quote:
Windows Server 2003, Windows XP SP1: The default value of HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode is 1 (current directory is searched after the system and Windows directories).
Windows XP: If HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode is 1, the current directory is searched after the system and Windows directories, but before the directories in the PATH environment variable. The default value is 0 (current directory is searched before the system and Windows directories).
I quote from MSDN:
"The directory from which the application loaded.
The current directory.
Windows 95/98: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
Windows NT/ 2000: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32.
Windows NT/ 2000: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. "
This is the sequence of paths searched by the LoadLibrary() API to load a DLL. Even if SafeDllSearchMode is set to 1, the first path to be searched is , I quote again: "The directory from which the application loaded." The current directory might be diffrent from the application directory. So, in my understanding, if u put the DLL in the same directory with the app, it should work regardless the value of SafeDllSearchMode.
You are correct, of course.Quote:
Originally posted by nick666
Even if SafeDllSearchMode is set to 1, the first path to be searched is , I quote again: "The directory from which the application loaded."
In my defense, I'm suffering from caffeine deprivation...:D
Actually, I had a situation in mind where I was "bitten" by SafeDLLSearchMode, that I was thinking was similar to this, but it is not.
I will make a test today by simple curiosity and maybe later I will be grateful for u :) I will tell u the results.Quote:
You are correct, of course.
thanks, but if i put the mfc40.dll in the application directory, it doesn't work, is it??
It should. Try it and see. Not sure what dependencies MFC40.DLL has... Get DependencyWalker from www.DependencyWalker.com to find out...Quote:
Originally posted by diegojancic
thanks, but if i put the mfc40.dll in the application directory, it doesn't work, is it??
We should also make sure other dll (if any) using the same mfc dll are in the same spot.
csheng