I have 1 dll file which I try to load during the installation with UseDLL() in one of my installscripts.
this dll has 2 dlls it depends on. they both located on the same directory of the main dll.
When in build the installation with an older installshield - it find it's dependencies and works fine.
When I try to build it with IS2016, it fails because it doesn't find it's dependencies. (If I put these 2 dlls in SysWOW64 - it finds them and works fine).
What is the problem?
Thanks,
Dudi
It looks like InstallShield 2018 makes this easier through a new Enable/Disable flag called DLL_DIRECTORY_SUPPORTDIR. But in InstallShield 2016 there's a good chance you can add the following InstallScript code to find dependencies in SUPPORTDIR. If your DLLs are in a different directory, substitute that instead.
// Add prototype for SetDllDirectory(); this typically goes near the top of your script
prototype number kernel32.SetDllDirectoryW(wstring);
// Call it; this goes in a function called before your UseDLL call
SetDllDirectoryW(SUPPORTDIR);
Note that doing this removes some protection against DLL planting, so it is safest to do this only if you ensure the DLLs in question are either proactively resistant to such things, or if you vet and secure the directory in question. (I'm uncertain whether InstallShield does this for you.)
Related
I've built a inproc com server dll which I can package as 1 file or many via the build utility py2exe. When I allow all the dependencies to remain external, I have no issues, but bundling as 1 file produces problems.
When the dll is utilized (either registering it or instantiating a com object from it), it immediately loads MSVCR90.DLL from the path c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6871_none_50944e7cbcb706e5\MSVCR90.DLL no matter what I do, I can't change that. There is no information that I can find (using Dependency Walker) to indicate what is causing that to load. It just happens magically...
Then, later on it loads that dll again via an explicit call to LoadLibraryA("MSVCR90.dll") (part of some py2exe black box?), but this time it does not look into the winsxs manifests / directory. Instead it looks to the system path and/or will respect a dll redirection. That's when the problem occurs. If I set the system path to start with c:\windows\winsxs\x86_microsoft.vc90.crt...\ it will load the exact same dll and be happy - but if ANY other file is utilized - inclusive of a copy of the EXACT same dll - but at a different path - then the whole thing blows up. It can't handle using two different files.
How can I fix this? Ideally, I've love to make the initial magic loading of the dll draw upon a private assembly, but no matter what I do with manifests or .dll.local etc it will not respect that until this second dll loading takes place.
Note that with the non-bundled dll (external dependencies) it always uses the winsxs MSVCR90.DLL.
I can "fix" my failure to use the dll by forcing the system path to load the winsxs copy, but that is pretty useless for a deployable com server!
The reason is that you DLL has a manifest that tells the module loader to search also in the SxS storage.
You have several choices
Build your DLL using static linkage. Not using any of the MFC-DLLs (see project settings)
Don't use a side by side manifest for the DLL and still use the MFC DLLs. But beware you have to ship those DLL with your DLL in the local path (see DLL search sequence docs)
Use a later build of VS. Later versions of VS don't use the SxS storage any more and there are no manifests for those DLLs any more.
For the 2. see this article in code project. There is an update for VS-2008 [here].
2
Build your DLL
I am receiving an ICE30 when I am trying to compile my WiX installer project. The complete error is below:
ICE30: The target file 'DPFPSH~1.DLL|DPFPShrNET.dll' is installed in
'[TARGETDIR]\Windows\DPDrv\' by two different components on an SFN system:
'DPFPShrNET.DA2BFC77_FAFE_41D1_8BB6_134232B2EADC' and
'DPFPShrXTypeLibNET.51D3E534_F1F9_4BC6_BFC5_B27F733081C7'. This breaks component reference
counting.
Now the peculiar thing is that these two components belong to two different merge modules, DPOTDotNet.msm and DPOTShrDotNet.msm. When viewed in Orca, the two components in question, DPFPShrNet (which is part of DPOTShrDotNet.msm) has a dll of the same name associated with it (DPFPShrNet.dll as seen in the file table), while DPFPShrXTypeLibNet also has a one dll of the same name associated with it (DPFPShrXTypeNet.dll). I do not see two DPFPShrNet.dll's being installed as the error says.
We are migrating away from InstallShield and into WiX, and the InstallShield ism file references these two merge modules and they both install correctly using that method. Is there some reason why WiX thinks two files of the same name are being installed? As soon as I remove DpOTShrDotNet.msm from my project, it compiles correctly, but I am missing the DPFPShrNet.dll in the GAC after I install.
ICE's are validation (unit tests) not compilation. Some of the ICEs are known to have bugs / design shortfalls. You should be able to ignore this one. Third party merge modules can be problematic though so you might want to look for an exe/msi redist installer for these components instead. Another possibility is to wrap these MSM's into their own MSI's and use WiX burn chainer to link it all together. This provides some separation / firewall / mitigation to the risks.
I am building a MSI installer with WiX for redistributing my MinGW64 application. This requires to ship MinGW dlls with the executable.
The libstdc6.dll file is not versionned. What is the cleanest approach for this?
I have tried:
Adding a companion file to the dll component, pointing to the main app exe, which is versionned. However, wix complains that I cannot set a companion to a dll
Putting the dll in the main app exe component, but this is discouraged in every wix faq, howto and forum...
Adding attribute DefaultVersion="!(bind.FileVersion.mainapp.exe)" to the dll file element for overriding the (missing) dll version. This seems to work at first glance, but wix is issuing warnings related to this:
C:\Users\Etienne\Documents\coding\ocean\ocean.wxs(116) : warning
LGHT1103 : The DefaultVersion '!(bind.FileVersion.mainapp.exe)' was used
for file 'libstdc6.dll' which has no version. No entry for this file
will be placed in the MsiFileHash table. For unversioned files,
specifying a version that is different from the actual file may result
in unexpected versioning behavior during a repair or while patching.
Version the resource to eliminate this warning.
What is the best way to solve this?
Thanks,
Etienne
IMHO, your best bet is option #2. All the rules assume that executable code would be properly versioned and thus are best deployed as KeyPaths of their respective Components. Since the .dll is not versioned, placing it as a data file with a versioned file is the next best thing.
Although, for the record, versioning the .dll is by far the most optimal solution. :)
I am using heat to harvest the COM dll and tlb files (let's call them MyLib.*, developed in VB.NET) to do the COM registration. Everything was working fine, when I install MyLib.dll and MyLib.tlb into my application's installation folder, i.e., INSTALLDIR. However, since we want to allow different versions of our SW to be installed on the same machine, and if they are using the same version of COM component, only one copy of the dll (I think each version of our SW should have its own tlb, please correct me if I am wrong) should be installed, we now want to install MyLib.dll into another folder, specifically PROGRAM_FILES\Common Files\SHARED_FOLDER_NAME, so now if one version of our SW is uninstalled, the MyLib.dll will not be removed and can still be used by other versions.
But here comes the problem: my COM registration is just simply not working any more after I install this dll into this another folder, and it keeps saying that can't find file specified when I am calling the COM function which indicates registration failure. In the WIX installer project, everything is the same except this folder for MyLib.dll.
Here is the registry structure after installation:
Firstly I have HKCR\CLSID{MYCLSIDs}, each of them represents one of my COM class. in the sub-key named "InprocServer32", I have Assembly, Class, CodeBase, RuntimeVersion, threadingModel. And the CodeBase is either common file folder (not working) or MyApp's installation folder(working), which is the different locations I put the dll. I thought there would be another sub-key TypeLib under {MYCLSIDs}, since Access only sees the TypeLib and I think there should be some link from the TypeLib to the actual dll, however, at both cases this sub-key is missing but in the second case it is still working. Is there a problem of it?
Secondly I have HKLM\Software\Classes\CLSID{MYCLSIDs}, these keys are of course the same structure as described above.
Thirdly, the HKCR{MYPROGIDs}, these are just ProgIDs of my classes
Fourthly, HKCR\Typelib{LibID}, which includes the information from tlb file, and this ID is from the Assembly GUID of COM component project.
Finally, the HKEY_CLASSES_ROOT\Interface{InterfaceID}, there is sub-keys named ProxyStubClsid32 with value {00020424-0000-0000-C000-000000000046}, and the one named TypeLib and the value is my LibID.
As I mentioned, the only difference is the CodeBase, which stores where MyLib.dll is located. In order to verify that, I did two tests: after I install MyLib.dll into the shared folder, the COM calling fails. But if I replace all the CodeBase values for SHARED_FOLDER\MyLib.dll to INSTALLDIR\MyLib.dll, and copy MyLib.dll into INSTALLDIR, it actually works. Vise versa, after I install MyLib.dll into INSTALLDIR(in which case COM is working), I change the CodeBase values from INSTALLDIR\MyLib.dll to SHARED_FOLDER\MyLib.dll, and make a copy to SHARED_FOLDER, this time it fails. So it seems that it is exactly the installation location's problem, which is the opposite to my understanding of COM. And I don't think there is a permission issue for the SHARED_FOLDER(I could be wrong) since it is in a folder that my installer creates.
Please help, thanks!
It turned out that MyLib.dll is using some other libraries, which are still installed in the MyApp installation folder. And so in that case that MyLib.dll is installed in the shared folder, it tries to find those libraries in the same libraries, which of course fails. When I install those libraries in the shared folder too, it is working.
BTW I found fulogvw.exe very helpful when tracking down the assembly loading problem. For example in my case in the failed log it says can't load file xxx.dll in SHARED_FOLDER, the xxx.dll is some library that MyLib.dll is using, and I had no idea that MyLib.dll needs it until I see the log.
A wrong version of a dll (MSVCR90d.dll instead of MSVCR90.dll) gets used for the delete operator, causing a crash. In the callstack, only the dll name is shown, not their path. How to see the path?
Edit: I'm building in Release mode, not in debug mode. So why does the debug dll get used? I have seen the same problem reported on many other websites, but could find no working solution.
Yesterday I found using Dependency Walker that the debug dll is getting picked up, so I renamed the dll, then the release version got picked up in the Dependency Walker, and also my program did not crash. I didn't change anything today, but the program has started crashing again. And when I see the dependency walker tree, it shows MSVCR90d.dll (the debug dll) with a question mark, saying it couldn't find it in the path. Why can't it pick up the release dll? Also I don't know from where the debug dll gets used by the runtime.
You can add them in your global PATH environment variable. Refer here
You can specify the dll manually by right clicking on the solution and selecting Add Reference, then browse to the particular dll.
You can add the path to the DLLs to the Executables files settings under Tools > Options > Projects and Solutions > VC++ Directories
For finding out the details of a dll, you might want to use DependencyWalker
However, in your case I think d is being appended to the name of dll, probably because you are creating a DEBUG build, and for that corresponding DEBUG versions of all dlls are loaded.
If you choose to create a RELEASE build, you would not have a d appended to MSVCR90.dll
You don't need to know Dll path, you need to understand why Debug version of delete operator is called. Maybe, _DEBUG constant is defined in Release configuration.