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|]
Rob.
- 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|]
Rob.
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
viv_bhatt1
18 years ago
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 ,
V
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 ,
V
Posted by:
rikx2
18 years ago
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
18 years ago
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.
IE MSWord.exe.local
And you have to add a .local file for all of the executable files in the folder.
Posted by:
DavidLock
18 years ago
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.
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
18 years ago
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.
