Incompatibilities between packaged projects

[elziko]

I am trying to package two projects.

I install the packaged Project1 on a computer and it works fine. I then install Project2 on the same machine and Project1 stops working with an error of Class does not support Automation or does not support expected interface

They both use several common controls and other references and I assume its something to do with Project2 overwriting ocx/dll files of an incompatible version. I went through every reference/control in Project1 and made sure that I was referencing the same files as in Project2 but that has not solved my problem.

Am I heading in the right direction? Any suggestions as to what I should check next?

Many thanks

elziko

 

[elziko]

In case someone can help me I've been looking into the .lst files produced for each installation. The most worring and inexplicable part of the lst files is as follows:

Project1's .lst
File30=@ET_COMMONTOOLS.DLL,$(AppPath),$(DLLSelfRegister),,6/13/01 10:14:16 AM,135168,1.1.0.4

Project2's .lst
File14=@ET_COMMONTOOLS.DLL,$(WinSysPath),$(DLLSelfRegister),$(Shared),2/28/01 5:15:50 PM,65536,1.0.0.0

Now, I assume that the highlighted parts of the lines above refer to the verion of the .dll, of which I have made several. I have gone into BOTH projects and have made absolutely sure that they are referencing the SAME file. How is it that Project2 insists on deciding against (my superior) advice and using an older version?

Hang on.....

.......before posting I just tried a bodge, where I added the correct verision into the support directory and then edited my .lst, copying the correct entry over the offending one. It seems to have worked OK. But can someone tell me whats going on so I can avoid the same problem in the future?

 

[jduckwo]

In project1 you placed the Commontools.dll (v1.1.0.4) in the same directory you installed your application in (app.path), and it was then registered to point to the app.path location when your program needed to use that dll.

In project2 you placed the Commontools.dll (v1.0.0.0) in the windows system path directory (C:\Windows\System). This dll was then registered in the registry as the correct one to use and the original dll (the one from project1) was then disregarded.

So when Project1 was looking for the Commontools.dll that it referenced, it was pointing to the old dll when it needed the new one to run properly.

In Project2 make sure you are creating a reference to the proper version of the control. Check the path of the dll from both projects and make sure they point to the same directory. If that isn't the difference, look in the program you created the setup package with, and make sure that it is looking in the proper place for the dll.

Jake

 

[chiph]

elziko -

When you built the ET_COMMONTOOLS.DLL, did you have version compatability set? If not, then what you're experiencing is a classic case of DLL Hell.

DLL Hell is where one application expects a shared DLL to have a public interface like 'A', then you install another application that uses the same DLL, and it expects that DLL to have a public interface like 'B'. The last app installed works fine, but the older one is broken since the shared DLL no longer has an interface of style 'A'.

You can do an ugly fix by renaming both versions (ET_COMMONTOOLS_11.DLL and ET_COMMONTOOLS_10.DLL), then providing a couple of batch files to
[tab]1. Unregister the old version
[tab]2. Copy the correct file over top of ET_COMMONTOLLS.DLL
[tab]3. Register it

Big limitation is that the user cannot run both programs at the same time.

Chip H.