11 replies to this topic

[mickey]

Im now testing the InstallShield Professional Windows Installer Evaluation Version and i really like it.
In my Setup i need to register a certain COM Component (mssnapr.dll) before the others to work properly.
Wich is the best way to do this?
Im still playing with it and trying do get it done with a custom action that calls another .msi. Wich is the best place in the Sequence to call this external .msi ?

[Stefan Krueger]

The suggested method is not to use self-registration, but let Windows Instalelr created the required registry entries (CLSID etc). With this method there should be no dependency on registration order. InstallShield has an option to extract the self registration information at build time, or when you add the file (using the component wizard)

[mickey]

ive written a snap in for the ms management console with visual basic. this relies on the "visual basic snap-in designer library" from microsoft.
in the manual ms tells you to register the library on a target system before you register your snap in.
so far, this can be done with "extract at build" option of install shield without problems.
i dont understand why but my snap in dll itself only can be registred useing "self-register".
therefore i need to understand how to tweek the sqeunce to fit my needs :)

[Stefan Krueger]

You canot specify the self registration order. If you need to use self registration and need to enforce a certain order, you must use custom actions to register and unregister these files. There is a topic "Specifying the Order of Self Registration" in MSI Help that explains the process.
As an alternative you could try to find out why IPWI can't extract the self registration information, or enter the registry data manually into the respective component settings (or import a .reg file)

[Ad]

We have the same problem. It seems that the extraction only works with dll's written in c++ and not with dll's written in Visual Basic. Can anyone confirm this or give a solution/workaround?

[mickey]

dear ad!
as stefan mentioned the self-reg order can be organized as described in the MSI help. (good hint, thnx!)
concerning my problem with the incompatiblity of a dll with the "advanced settings" registration mode of ISPWI:
i cannot agree your suggestion that this is a general problem with dlls written in VB - ive successfully registred a couple of classes written in VB this way.
it seems to be a specific problem with MMC snap-in dlls written in vb useing the Visual Basic Snap-in Designer v1.0 from MS Platform SDK.
however, its the only dll where i had this problem.

happy setup!

[Stefan Krueger]

IPWI 2.01 relied on the OleSelfRegister entry in the version properties of a file to extract registration information while you add the component to your project (this limitation did not affect the "extract at build" option as far as I know).

In IPWI 2.03 this problem should be solved (according to the release notes)

[Ad]

Thanks for the responses. I have temporarely set all our own com-dll's to self registering. I'm planning to put them back to "extract" at build as soon as I know how Installshield extracts the information and how I can solve problems that might occur during the extraction.
So if anyone can tell me exactly how they do the extraction of the registry data, I can start looking at possible problems with our dll's. I get the impression that it depends to a certain degree on the OS you are running on the machine that builds the setup. In my case it's WindowsNT 4.0 SP1 with Visual Studio SP4 and IE4.0SP2. And also on the data already  present in the registry.
I'll post my conclusions when I resolved the issues.

thanks,

Ad

[Stefan Krueger]

I believe that IPWI basically registers the file on your devlopment machine and tries to monitor the registry modifications. This fails if a required file is missing. Versions of IPWI prior to 2.03 did not attemt the registration if the OleSelfRegister string was missing in the version info.

[Ad]

Thanks Stefan,

I tested a few things today and came to the same conclusion that IS indeed registers the dll on your machine. But does not give you the option to unregister the dll again. In my case this gave me problems because we are still changing a lot of the com interfaces, thus changing our registering info. I have created batch files that unregister all my dll's and exe's prior to building my setup. If I don't do this IS takes the wrong information out of the registry and puts this wrongly in my installation.
So to conclude this thread: if you have a problem with registry data extraction at build time, make sure your registry is clean before doing the build.

[SteveP]

There is also the option of designing your own custom routine to extract the registry information from your COM objects and register them explicitly.  If you would like additional information on this option, please drop me an email.