DLL Conflicts

Hey, any thoughts on this one?

- PackageA (approx 1000 users) installs crqe.dll to C:\Windows\System32 and C:\Program Files\Common Files\Crystal Decisions\2.0\Bin - the DLL is registered as part of the install. Not sure why the dll exists in 2 locations (I don't think this is an issue) the MSI is a snapshot of a vendor install - no entries in the selfreg table, we avoid using it if at all possible.

- PackageB (approx 100 users) installs a slightly newer version of crqe.dll to C:\Program Files\PackageB\Crystal - this is a transformed vendor MSI which has entries in the selfreg table [:@]

If both packages are installed there are problems with PackageB. If both packages are installed and I regsvr32 the C:\Program Files\PackageB\Crystal\crpe.dll file PackageB works and there are problems with PackageA.

Tried downgrading the Crystal runtime DLLs in PackageB to match those in PackageA but PackageB won't work with these versions and the developer isn't being much help.

I guess component isolation is the way to go but I've not used it yet so before I start looking into it I wanted to see if anyone has any suggestions on fixing this?

Hope this makes sense [8|]

0 Comments   [ + ] Show comments

Answers (5)

Posted by: viv_bhatt1 15 years ago
Senior Purple Belt
Hello ,

I believe if the package does not works well with the higher version of dll then it is a potential candidate for isolation , you should use dll redirection to isolate dll in Package B .

Microsoft has added a DLL redirection feature from Windows 2000. This feature forces the operating system loader to load modules from your application's directory first. Only if the loader cannot find the file there will it search other directories.

Hence Package A will continue using the older version of dll from the shared location but package b will use a local copy of the higher version dll .

Hope this helps .

Cheers ,
Posted by: rikx2 15 years ago
Purple Belt
try adding an app_name.exe.local to your packageb and do a test to see if redirection would work.. that way it would look up the dlls first on the program directory instead of looking straight at the common files folder..
Posted by: MSIMaker 15 years ago
2nd Degree Black Belt
rikx2 its not app_name.local its exename.exe.local

IE MSWord.exe.local

And you have to add a .local file for all of the executable files in the folder.
Posted by: DavidLock 15 years ago
Senior Yellow Belt
Looks like there is conflicting COM information under HKCR.

Isolation would be the way to go but I don't think windows installer .local isolation would work. I believe that just isolates the DLL not the associated registry entries. If you want to isolate the associated COM data under HKCR you would need to use XP manifest isolation...which only works on XP.
Posted by: rikx2 15 years ago
Purple Belt
rikx2 its not app_name.local its exename.exe.local

[8D] wrong wording but same intention.. thanks msimaker
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ