This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Unwanted (Unneeded?) RunOnce Entry
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 13, 2007
05:19 PM
Unwanted (Unneeded?) RunOnce Entry
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:
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!
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\
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,
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!
(8) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 14, 2007
09:00 AM
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.)?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 14, 2007
10:23 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 14, 2007
01:50 PM
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??
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??
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 27, 2007
06:47 AM
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!
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??
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 02, 2007
10:26 AM
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?
Has anyone else seen this? Is this some sort of known issue w/IS 2008? Any suggested workaround?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 02, 2007
11:36 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 02, 2007
03:07 PM
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?
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 04, 2007
03:11 AM
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.
😉
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.
😉
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)