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   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


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 ,
Answered 07/07/2005 by: viv_bhatt1
Senior Purple Belt

Please log in to comment
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..
Answered 07/07/2005 by: rikx2
Purple Belt

Please log in to comment
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.
Answered 07/08/2005 by: MSIMaker
Second Degree Black Belt

Please log in to comment
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.
Answered 07/08/2005 by: DavidLock
Senior Yellow Belt

Please log in to comment
rikx2 its not app_name.local its exename.exe.local

[8D] wrong wording but same intention.. thanks msimaker
Answered 07/08/2005 by: rikx2
Purple Belt

Please log in to comment