PDA

View Full Version : Dependent dlls/ocx's fail to register...



ThomasR
07-24-2002, 12:59 PM
Dependent dlls/ocx's fail to register, and in some cases fail to 'stay registered'.

The install was built with IS Developer 7.03 and runs successfully on most customer machines. However, on a few of them, the com components fail to register or have registration issues. The target machines are Winnt sp6, win2000 sp2, win98, and winXP. The only machines having these issues are Winnt and Win2000.

For this install, all of the dependent dlls and ocxs are installed into the system directory. Their component properties are set to 'Shared' and 'Extract COM Info at Build'. (I've since learned that they may not get uninstalled with the 'Shared' option turned on.) Additionally, the dependent files are set as a key file of each component, with 'Self Register' turned on.

Registration issues (separate issues occured on different machines, while each issue has occured on one or more machines):

1.) Install runs successfully, yet when the user attempts to run the installed program, they get a 429 error (dependency error). Manually registering the supporting dlls that were installed fixes the issue... Until the machine is rebooted, then the files must be manually registered again. On machines with this issue, we've ran the uninstall and tried to manually install all of the files. However, once the InstallShield program has been ran, the machine fails to 'keep' the registration information for the dependent files. For now, we have the user running a bat file to register the files each time the machine is rebooted.

2.) Install fails to register supporting dlls. Once the install has completed and given the user an error when it attempts to register the files, manual registration of these files fails also. Uninstalling the program, then manually copying the files to the machine and manually registering them works. Several attempts on this machine have failed to run successfully.

Any help or information you could provide would be greatly appreciated.

Mike.Weeks
07-25-2002, 07:23 AM
I had self registration working great in 7.02. Registration of dependant dll's and ocx's fails in 7.04.

The ISSelfReg table has an order column which should control the order in which files are self registered. Either this function is broken or the self reg function itself is broken.

But, this is only one issue of many that will prevent our on-time product release with a Windows Installer. Oh, well.........

_doog_
07-25-2002, 08:03 AM
use best practice and do not self-register the components during install
extract the information at build or when creating the component

when you do this, msi will store the activex registration into the apropriate tables and write them during installation, no dependencies come into play

if you can not do that (there is no reason anybody needs to do self-registration...) but if you say i can not do that, there is an article in the platform sdk how to make activex components register in the right order, but thats a lot of work

Mike.Weeks
07-25-2002, 08:17 AM
When InstallShield fails to extract com information or you get build errors when Extract at Build is selected for the component, you must use self registration.

As I said, this was working. I can register from the command line all day without error, so what did they break???

_doog_
07-25-2002, 08:21 AM
is this standard or basic project?

well activex will always fail, if it is not done in the proper order
and there is no way to tell msi, in which order the components should be registered

you can only use a bunch of CA to eliminate the problem

well, if it does fail to extract the informations, then extract them manually and put them into the apropriate tables

what version are you using?

Mike.Weeks
07-25-2002, 08:32 AM
Basic MSI.

I'm not going to write hundreds of CA's today. I'll go back to IS 3.

_doog_
07-25-2002, 08:37 AM
did you extract the activex components at a clean computer?
are they registered within component service?

i would try to populate the tables correctly rather than doing self-reg

when i had 7.01 it was a real hard fight to bring in activex registration into the tables, but from my point of view, with 7.03 it works out fine

ThomasR
07-25-2002, 10:13 AM
From what you're saying, do not use 'Self-Register', use Extract Com info for a component instead? I'll give that a shot.

The current install uses both - Could that be part of my problem?

Thanks

_doog_
07-26-2002, 06:54 AM
yes, could be part of the problem, you should no longer use self-reg
if you still want to do so,
you should check the install execute sequence so that the SelfRegModules Action is after RegisterTypeLibraries, RegisterClassInfo, RegisterProgIDInfo and WriteRegistryValues

ThomasR
07-26-2002, 07:25 AM
Ok, can you tell me how the Extract Com info registers a file differently than self register? One of the issues I'm having with this install where I had both Extract Com info and Self Register selected is that doing an uninstall does not remove all of the registry entries for the components. Neither does manually unregistering these components with regsvr32.

One other note about these dependencies - they were marked as 'Shared' because they are also used with another program we install. However, only one program was isntalled, and trying to uninstall and clean up the machine seems to be about impossible. Is marking a component shared the same as marking it permenant?

_doog_
07-26-2002, 07:44 AM
I) a permanent component will not be removed from the target computer
a shared component has a reference counter. if the references to the component go to zero through uninstalling, the component is removed

II)
if you use self-register, the self-register function within the dll is called
if you extract com during build (or when creating the component) ISDev scans the component for the self-register values written to the registry. these values are extracted and written to the class table, progid table and typelib table. any values that can not be placed in any of these tables are written to the registry table

any values withing the msi-tables are removed from msi during uninstall, but msi has no control over the unselfregister-function within the dll

bob362
07-29-2002, 10:05 AM
I am having this same problem. I am unable to get "some" DLLs and OCXs regsitered. I have tried BOTH the self-register flag and COM extract at rebuild method. Neither method seems to work.

I have not attempted to order the registration of this stuff.

If we register the files using REGSVR32 after the install. It seems to work fine.

I was wondering if writing a InstallShield script language function that fires "OnInstalled" and executes the same line of code that we manuualy execute?

How would one do this?

THANKS!


Bob

_doog_
07-30-2002, 07:38 AM
create the component with the component wizard using best practice
it will extract all com informations of the component when creating the component

check the class, progid, typelib and registry information, if they are correct and change them, if needed

if you do so, set self register=no and extract at build=no