After successfully creating and installing my InstallShield Developer 7.0 MSI project, I find that after launching my project, The expected program splash screens appear, but suddenly a window titled
'Windows Installer' with the text 'Preparing to install...'
appears for a few seconds, then is replaced by a window titled
'[My Project Name]' with the text 'please wait while Windows configures [My Project Name]'
These dialogs alternate, and the product is not launched. Any ideas of what could cause this behavior? Note that the appropriate components have had their 'COM Extract at Build' property set to 'Yes' since I first suspected that MSI was trying to register my .dlls at install time.
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Installer in endless loop
Started by
johngalt
, Jan 08 2003 23:18
2 replies to this topic
hambone
-
- Members
- 206 posts
Posted 09 January 2003 - 13:50
it would seem that something is triggering the installer engine to believe that one of the product state requirements is not present and the installer is trying to install/configure it...
it cases like this it is helpful to create a full verbose log for the installation ( using the /l*v+ {logfile.log} switch is one method ). a useful tool for analyzing this information is the WILogUtl.EXE program from the MS SDK ( i am aware of two versions v2.0.3639.0 and v2.0.2600.0 ).
does this happen on all systems tested ?
it is possible that MSI Registry Database is corrupted. if this is the case there is a MSI CleanUp Utility ( again from MS ) that will allow you to delete Your Product information from the MSI Registry Database on the problem system.
it is also possible that there are component conflicts amoung the different MSIs installed on the system. so, when another application installs a component that changes your product's required component, your product is forced to try to re-configure and re-install at launch-time. to check for this use a conflict analyzer ( such as those provided by InstallShield Studio line, Wise Studio line, or Prism ).
it is also possible that you have included a component in your package that gets altered by your product. so that when your product runs it changes those included components forcing your product to re-configure at launch time. if this is the case you should be able to determine this by performing MSI Validation on your package ( this can be accomplished by using the MSIVal2.EXE and the appropriate .CUB files from the MSI SDK and performing a string pool validation ).
you can also run the MSI in 'test mode' or with a debugger to track the installation procedure ( this can be done by using one of the debugger tools from MS, InstallShield, Wise, Prism ).
another option is to play the 'price is right - high low game' by which you remove various items from your msi until you get a working installation. then you can do the 'high-low' re-iterative process to narrow down the offending area.
i know i probably haven't answered your question but i hope this will give you a direction in which to look for that answer...
it cases like this it is helpful to create a full verbose log for the installation ( using the /l*v+ {logfile.log} switch is one method ). a useful tool for analyzing this information is the WILogUtl.EXE program from the MS SDK ( i am aware of two versions v2.0.3639.0 and v2.0.2600.0 ).
does this happen on all systems tested ?
it is possible that MSI Registry Database is corrupted. if this is the case there is a MSI CleanUp Utility ( again from MS ) that will allow you to delete Your Product information from the MSI Registry Database on the problem system.
it is also possible that there are component conflicts amoung the different MSIs installed on the system. so, when another application installs a component that changes your product's required component, your product is forced to try to re-configure and re-install at launch-time. to check for this use a conflict analyzer ( such as those provided by InstallShield Studio line, Wise Studio line, or Prism ).
it is also possible that you have included a component in your package that gets altered by your product. so that when your product runs it changes those included components forcing your product to re-configure at launch time. if this is the case you should be able to determine this by performing MSI Validation on your package ( this can be accomplished by using the MSIVal2.EXE and the appropriate .CUB files from the MSI SDK and performing a string pool validation ).
you can also run the MSI in 'test mode' or with a debugger to track the installation procedure ( this can be done by using one of the debugger tools from MS, InstallShield, Wise, Prism ).
another option is to play the 'price is right - high low game' by which you remove various items from your msi until you get a working installation. then you can do the 'high-low' re-iterative process to narrow down the offending area.
i know i probably haven't answered your question but i hope this will give you a direction in which to look for that answer...
johngalt
-
- Members
- 5 posts
Posted 14 January 2003 - 23:50
Thanks, it turns out that my install was trying to find the files associated with a feature that was being installed when a certain flag was triggered. These files were not present in my installation, and once I rebuilt with the missing files back on my build box, the problem was solved.
Not a clear explaination, but the short of it is make sure you are comparing apples to apples.
Not a clear explaination, but the short of it is make sure you are comparing apples to apples.