Unwanted (Unneeded?) RunOnce Entry

[Sairen]

Totally mystified by this one...

So we have a bunch of install kits, all of which are going from version X.Y (build with InstallShield 12) to version X.Y+1 (built with InstallShield 2008). I'm using major upgrades to do it. All projects are Basic MSI.

Now on just one of our products, this upgrade deposits a registry key in the RunOnce area.
InstallShieldSetup = "C:\Program Files\InstallShield Installation Information\" -rebootC:\PROGRA~1\INSTAL~1\reboot.ini

Now, I didn't ask for a reboot in the project. The installer didn't prompt for a reboot. There should be nothing that needs resuming. Additionally, isn't being resolved.

Obviously, no such folder exists, so the next time I do reboot, I get this message:

"Windows cannot find C:\Program Files\InstallShield Installation Information\
Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search."

I can click through it, but it needs to be fixed.

Anyone have any thoughts or anything I should check for as to
1) Why is this RunOnce key being created at all?
2) Why isn't DISK1SETUPEXEDIR being resolved?

Thanks!

[MichaelU]

I know you say that those are all Basic MSI projects, but the location described is one I would only expect to be used by InstallScript and InstallScript MSI. Is it possible that this one project is in fact an InstallScript MSI, or that its InstallScript code had something bizarre copied into it? Is anything setting any properties or script variables related to reboots (such as BATCH_INSTALL, etc.)?

[Sairen]

Nope -- it's been a Basic MSI project since it was first created...back in InstallShield 11, I believe. Ever since we've just kept right on upgrading...so unless this last conversion managed to change its type (though no other conversions did that)...it's definitely not InstallScript or IS MSI. And I double checked the type in General Information. Yep -- definitely Basic MSI.

We do make extensive use of InstallScript CA's. But I've quickly skimmed the script files and see nothing that's particularly new, nothing we haven't done in other projects, and definitely nothing that would qualify as "bizarre."

We don't do anything in script dealing with reboots. The only change I've made to the default reboot behavior is change the condition of ScheduleReboot action to:ISSCHEDULEREBOOT OR NSPR_PROPERTY_PREVALUE <> 1
The second property checks for a system variable prior to installation; it is isn't there, it adds it the sys variable and triggers this reboot.

Looking at the verbose log file, ScheduleReboot is not called; the condition is false (as it should be). However, RebootYesNo is set to yes by the end. I see several files that are marked "for deletion during post-install cleanup (not post-reboot)" A reboot is scheduled in the midst of lines marked "RollbackCleanup: ...."

Info 1903. Scheduling reboot operation: Deleting file E:\Config.Msi\#####.rbf. Must reboot to complete operation.

There are three of these. However, no reboot was requested at the end of the installation!

Let me know if this has triggered any other ideas, or what add'l information I can provide. Thanks for your help.

[Sairen]

Additional information:

The key under RunOnce is not created on a new installation. This behavior only seems to occur after a major upgrade. The version from which it is upgrading is irrelevant.

Has anyone seen anything like this from an MSI project??

[mehajure]

Hi Sairen,

did you solve the problem with RunOnce ?

I see this behaviour on an InstallScript Setup, since upgrading it to IS2008. Always after uninstalling I have this behaviour. 😞
The ugly aspect is that the setup performs all tasks and does not need any RunOnce task - even before upgrading it was unneeded and didn't happen.

I'd like to get rid of it.

Any help is appreciated!

Sairen wrote:
Additional information:

The key under RunOnce is not created on a new installation. This behavior only seems to occur after a major upgrade. The version from which it is upgrading is irrelevant.

Has anyone seen anything like this from an MSI project??

[Sairen]

No, I haven't been able to fix it. This behavior is completely incomprehensible to me, particularly since I'm using a Basic MSI project!

Has anyone else seen this? Is this some sort of known issue w/IS 2008? Any suggested workaround?

[mehajure]

Hi Sairen,

after a lot of working I found a workaround. But I am using a Installscript setup, so it might not be aplicable to you.
In the last line in the OnEnd function of my script I set
BATCH_INSTALL=FALSE ;

The run once key is due to the fact that the setup tries to resume after reboot - unsolicited !?! 😞

The uninstallation of my setup needs a reboot and it still works well but without the unneeded run once key.
So the found locked files are uninstalled correctly because the "PendingFileRenameOperations" of the session manager are not affected by resetting BATCH_INSTALL.

Hope it helps though.

[Sairen]

Mehajure,

Thanks for the tip. In the Property Manager view, I set a property called BATCH_INSTALL to FALSE and that seemed to do the trick. Still, if anyone reads this and knows the underlying cause, I'm all ears...

=======================

Seems I spoke too soon...that fixed the bug when it was occurring during Major upgrade, but not during uninstall of the newer version... So. Back on the table?

[mehajure]

Hi Sairen,

Did you take in account that this variable (property) can be set at runtime? So if you solved the problem during major upgrade in the mentioned way, it could be that some Installshield-function-olalala sets this variable to "TRUE".

Maybe you need a simple custom action close to the end of the execute sequence that will be triggered ALWAYS.

Why?

In the last line in the OnEnd function of my script I set
BATCH_INSTALL=FALSE ;

The OnEnd function will always be called Install/uninstall/maintainance...
Since it is the last line, it will ALWAYS reset BATCH_INSTALL !

If you only insert BATCH_INSTALL=FALSE at design time it might be altered.
😉