Best Way To Distribute App with ActiveX?

[jlb101]

I am trying to find the best practice for distributing applications with ActiveX controls, to minimize the possibility of the dreaded 'DLL hell'.

I have seen some applications place ActiveX controls into their own directory, rather than placing then in the Windows System32 dir.

Is this possible in VB? My worry is that it will screw up the registry.

 

[TomKane]

I think that if at all possible you don't want to install dll's on the users individual pc's. We have some activex in our apps and we have them out on a network drive.

 

[SemperFiDownUnda]

"I have seen some applications place ActiveX controls into their own directory, rather than placing then in the Windows System32 dir."

hehehe this doesn't matter. Unless you name your DLL the same as another vendor.

If your application has a control name AdvCalendar and it is in a component named AdvControls. Your applications will access these controls via its CLSID in 99% of the cases. When the app starts the system goes to the registry and looks up the CLSID it then finds what OCX holds that control and loads it. You want to mess up a system....install (register) an OCX in a directory and make a program for it. Then close the program and move the OCX to they Windows System32 directory....the application will not run. Now there are ways that he OCX can get reregistered.

I don't see a problem with putting stuff in the win32 directory. Biggest thing is naming conventions. You should use project names that will not conflict with other systems. I'm a fan of prefixing the project with the name of the organisation. So if I had a company "Wayne'sWorld" I would have all my support projects named stuff like
ww_AdvControls. Thus the DLL would be ww_AdvControls and less likely to conflict with file names of other vendors files.

 

[jlb101]

I am not talking about my own control, it's 3rd party ones which cause a problem when you use a different version in your project to what's on there pc (DLL Hell!).

 

[williamu]

I understand that you are looking to install a 3rd Party ActiveX on a User's Machine that you are shipping with your own App. However this ActiveX may exist already on the Users machine, so you want to know what to do to avoid DLL hell, yes?

If this is correct then place the control in your own app's directory and register it. If the same version already exists then it will be used when needed. Since it will be found by Windows when it searches for the CLSID. If it's unregistered (properly) the one in your app's directory will then be used allowing your program to operate normally.

You may also want to consider using the CLSID in your app when you instansiate the Control, to resolve ANY confusion.


William
Software Engineer
ICQ No. 56047340

 

[jlb101]

William

What do you meen by using the CLSID? In what way?

 

[williamu]

I don't know what ActiveX you are using but if you use the CreateObject() Function you can use the CLSID instead of "Excel.Sheet" for example.

You'd normally do this if the Control didn't have a User Interface.


William
Software Engineer
ICQ No. 56047340

 

[SemperFiDownUnda]

If you are using 3rd party controls then they should be designed to be backward compatible.
Controls and ActiveX DLLs should not install if there is a newer version already installed on the machine.
Unlike normal DLLs, that are looked for in the current directory then search path, OCXs and ActiveX DLLs can only have 1 registered copy on the machine. Any call to classes or controls that are in the library will be pointed to that 1 File. That files location is contained in the registry and is where the file exsisted when it was registered. ActiveX DLL/OCX hell is different then normal DLL hell. The problem here is much worse because unlike normal DLLs I can't have 2 or more OCX/ActiveX DLL librarys with the same ProgID (library name.class name) registered on the one machine at any one time.


Let me explain in real world terms.

I have program A that uses a control called AdvCalendar in a OCX called AdvControls who's version is 1.1. The Version independant ProgID of this control is AdvControls.AdvCalendar it has a CLSID of {39460F50-1709-409D-B672-1AF74C271241} and was registered from the directory C:\Program Files\AdvMail\

When a program that uses that control loads up it asks the system to load the file that has {39460F50-1709-409D-B672-1AF74C271241}. The system goes to the registry and finds that control is in the file C:\Program Files\AdvMail\AdvControls.OCX and loads it up. If the OCX isn't where the registry thinks it should be you'll get an error.

Later I load Program B uses a control called AdvCalendar in a OCX called AdvControls who's version is 2.5. The Version independant ProgID of this control is AdvControls.AdvCalendar it has a CLSID of {39460F50-1709-409D-B672-1AF74C271241} and was registered from the directory C:\Program Files\AdvProjectMgr\

This control is backward compatible as per the guidelines for COM. The control registries entries are changed to point to the new OCX in C:\Program Files\AdvProjectMgr\AdvControls.OCX

If Program A gets run it will use the C:\Program Files\AdvProjectMgr\AdvControls.OCX.

If I reinstall Program A the setup program will compare the Version currently installed to the version it has and should prompt you there is a newer version and ask you if you want to keep it. If you say no and install the 1.1 version (actually you are just changing the registry entries) then there is a good chance that you'll break the program AdvProjectMgr.

This is all despite the fact that you have 2 AdvControls.OCX files on your system. Only 1 of them can be registered at one time. (strickly this is not true) If I had 2 different AdvControls.OCX from 2 different vendors and none of the controls inside have the same name and they both where not installed to the same directory C:\windows\system32 for example then they will coexists fine. The problem is if they have any classes that are named the same one may not work depending on how its used. The other problem is if they are installed to the same directory obviously only the last installed OCX is going to live because you can't have 2 files with the same name in a directory.

I know its a bit much to take in but if I'm not clear please speak up.

Oh CLSID is a 128bit unique key for your object. It statistically unique meaning no other control should ever get that ID by accident.