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: How to tell Standalone Build's version?
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
‎Oct 17, 2008
06:02 PM
How to tell Standalone Build's version?
Hello,
We have switched to IS2009 Premier just a few weeks ago. I downloaded the Standalone Build version for the build server from IS Update utility. But the installer doesn't say if it has SP2 in it or not. Is there any way to tell what version of Standalone Build is it?
The Setup.exe and the binaries it installs have the following version info:
File Version: 15.0.0.591
Internal Build Number: 82160
Date: 09/17/2008
We are experiencing a problem that was supposedly fixed in SP2. But IS Update (aka Software Manager) says I'm up to date.
We have switched to IS2009 Premier just a few weeks ago. I downloaded the Standalone Build version for the build server from IS Update utility. But the installer doesn't say if it has SP2 in it or not. Is there any way to tell what version of Standalone Build is it?
The Setup.exe and the binaries it installs have the following version info:
File Version: 15.0.0.591
Internal Build Number: 82160
Date: 09/17/2008
We are experiencing a problem that was supposedly fixed in SP2. But IS Update (aka Software Manager) says I'm up to date.
(13) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 20, 2008
04:04 PM
I don't know about the setup.exe, but if I compare the binaries that were installed by the SP2 Standalone builder to the ones that were installed previously on my system (SP1?), I see a difference in ISWIBuild.dll and ISSetup.dll. The previous release had version 15.0.0.533, the ones installed by SP2 have 15.0.0.591.
Sandra
Sandra
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 20, 2008
04:45 PM
15.0.0.591 is the correct version number for all updated binaries in SP2, including the setup.exe file.
(If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 20, 2008
05:14 PM
Hmm, I'm puzzled... :confused:
Then why bugs IOC-000062240, IOC-000063184, IOC-000065022 that are listed in SP2 release notes as fixed still occur in builds made with latest Standalone Build?
Then why bugs IOC-000062240, IOC-000063184, IOC-000065022 that are listed in SP2 release notes as fixed still occur in builds made with latest Standalone Build?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 21, 2008
11:28 AM
Can you please verify that the following files are indeed updated to version 15.0.0.591 in your StandAlone Build install?
..\Redist\Language Independent\i386\ISSetup.dll
..\Redist\Language Independent\i386\ISP\ISSetup.dll
..\System\ISSetup.dll
..\Redist\Language Independent\i386\ISSetup.dll
..\Redist\Language Independent\i386\ISP\ISSetup.dll
..\System\ISSetup.dll
(If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 21, 2008
01:34 PM
Sheryl,
Confirmed, the files you've listed are all version 15.0.0.591, and all have the same date 09/10/08 23:33, but they have different filesizes (though I guess it's allright).
Confirmed, the files you've listed are all version 15.0.0.591, and all have the same date 09/10/08 23:33, but they have different filesizes (though I guess it's allright).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 21, 2008
02:47 PM
We are taking a look at this issue. In the meantime, do you also see these errors with a build done through the InstallShield IDE, or do they only occur with the StandAlone Build?
(If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 21, 2008
09:13 PM
Sheryl,
Our QA found this issue to be a problem only on XP 32 bit.
Vista and XP x64 do not show warning dialogs ("File Setup.exe was not found") after reboot, even thou the registry values in RunOnce key are present.
I was a bit busy today, but I'll try the GUI build tomorrow.
Thanks for your help.
Our QA found this issue to be a problem only on XP 32 bit.
Vista and XP x64 do not show warning dialogs ("File Setup.exe was not found") after reboot, even thou the registry values in RunOnce key are present.
I was a bit busy today, but I'll try the GUI build tomorrow.
Thanks for your help.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 24, 2008
11:56 AM
We ran some tests using the SP2 Standalone Build and the SP2 IDE and confirmed that this issue has been fixed. We could not reproduce the error on our end.
Could you please confirm if you also see this issue with a build from the IDE?
Also it would be helpful if you could send me a small test project (.ism), built media, and install log that demonstrates the problem. You can attach them to your post or send them to me at sheryls@acresso.com.
Could you please confirm if you also see this issue with a build from the IDE?
Also it would be helpful if you could send me a small test project (.ism), built media, and install log that demonstrates the problem. You can attach them to your post or send them to me at sheryls@acresso.com.
(If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 24, 2008
06:57 PM
Sheryl,
I did the IDE build of the product and I still have that issue. :mad:
Here's the image of the registry's RunOnce key after uninstall, but before the system is rebooted:
And this is the error message that comes up when system starts up after reboot:
The "InstallShield Installation Information" folder after reboot is clean - there's no {15733AD1-xxxx} folder inside it.
I'll try to come up with a sample setup for you. The actual product is for the high profile customer, so I can not share any of its sources.
Thanks for your help.
I did the IDE build of the product and I still have that issue. :mad:
Here's the image of the registry's RunOnce key after uninstall, but before the system is rebooted:
And this is the error message that comes up when system starts up after reboot:
The "InstallShield Installation Information" folder after reboot is clean - there's no {15733AD1-xxxx} folder inside it.
I'll try to come up with a sample setup for you. The actual product is for the high profile customer, so I can not share any of its sources.
Thanks for your help.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 28, 2008
03:14 PM
Sheryl,
I created a simple IS2009 project that installs just one TXT file. This project does not exibit the issue that I see in production.
The actual product is quite big and complex, it installs system drivers, runs multiple executables to configure the system and it installs several other IS-based products (prereqs). That's why it requires system reboot to make sure that all actions are complete before user starts the application (we are forcing BATCH_INSTALL=TRUE in OnFirstUIAfter, OnMaintUIAfter, etc.).
Also the product that has the issue was originally IS11-based, then moved to IS2009. Could that be the problem? There were no errors during conversion to IS2009 project format.
I created a simple IS2009 project that installs just one TXT file. This project does not exibit the issue that I see in production.
The actual product is quite big and complex, it installs system drivers, runs multiple executables to configure the system and it installs several other IS-based products (prereqs). That's why it requires system reboot to make sure that all actions are complete before user starts the application (we are forcing BATCH_INSTALL=TRUE in OnFirstUIAfter, OnMaintUIAfter, etc.).
Also the product that has the issue was originally IS11-based, then moved to IS2009. Could that be the problem? There were no errors during conversion to IS2009 project format.
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 28, 2008
03:55 PM
How is this related to the stand-alone build?
Does the sample app reproduce the problem if built with the stand alone build?
Also, are we talking about an InstallScript or InstallScript MSI project?
Also, the functionality basically checks whether Setup.exe exsits in the InstallShield Installation Info folder when the setup is completed, so one thing to check is whether setup.exe exists at this time (i.e.) it may be removed after reboot by Windows before the setup attempts to run after reboot.
Devin Ellingson
Software Developer
Acresso Software
Does the sample app reproduce the problem if built with the stand alone build?
Also, are we talking about an InstallScript or InstallScript MSI project?
Also, the functionality basically checks whether Setup.exe exsits in the InstallShield Installation Info folder when the setup is completed, so one thing to check is whether setup.exe exists at this time (i.e.) it may be removed after reboot by Windows before the setup attempts to run after reboot.
Devin Ellingson
Software Developer
Acresso Software
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 28, 2008
05:24 PM
Devin,
We have a non-MSI project, just InstallScript.
And it appears that the problem that we see is not bound to Standalone Build, as IDE build produces the same issue.
If you check the images in post #10, you'll see that Setup.exe indeed exists in the folder after uninstall is complete. But on reboot the entire folder seems to be removed by Windows before RunOnce key is getting processed.
The product seems to be cleanly uninstalled after reboot, and I don't have any OnReboot events defined, so I don't think that something needs to be executed. Though occasionally there could be some locked files in the product (like the DLLs that add menus to Windows Shell), which are removed on reboot.
From the IS standpoint, what actions done by our installer could trigger creation of those RunOnce keys? Just the mere presence of Setup.exe or some delayed clean up routines for OLE objects, services, or InstallShield itself?
Could -runfromtemp option (or absence thereof) in the UNINSTALL_STRING have anything to do with this issue?
We have a non-MSI project, just InstallScript.
And it appears that the problem that we see is not bound to Standalone Build, as IDE build produces the same issue.
If you check the images in post #10, you'll see that Setup.exe indeed exists in the folder after uninstall is complete. But on reboot the entire folder seems to be removed by Windows before RunOnce key is getting processed.
The product seems to be cleanly uninstalled after reboot, and I don't have any OnReboot events defined, so I don't think that something needs to be executed. Though occasionally there could be some locked files in the product (like the DLLs that add menus to Windows Shell), which are removed on reboot.
From the IS standpoint, what actions done by our installer could trigger creation of those RunOnce keys? Just the mere presence of Setup.exe or some delayed clean up routines for OLE objects, services, or InstallShield itself?
Could -runfromtemp option (or absence thereof) in the UNINSTALL_STRING have anything to do with this issue?
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 29, 2008
08:10 PM
rusgrafx,
It looks like there is still an issue with this in the case that the Setup.exe is locked and scheduled to be removed after reboot. (In previous versions we also checked for the existence of setup.ilg before creating the "RunOnce" key, however this is not reliable since setup.ilg does not have to be there in order for the setup to run after reboot).
The workaround would be to delete the "RunOnce" value at the end of the setup. Unfortunately we since write the RunOnce key at the end of the seutp (after all script code has completed) this is currently not easy to do.
It should be possible for the setup to delete the setup.exe during the initial uninstall, are you specifying /runfromtemp when uninstalling. If you don't do this then setup.exe will be locked and will have to be replaced after reboot. (In previous versions this was not needed as we used an unreliable workaround that involved ctor.dll and "Rundll32").
Devin Ellingson
Software Developer
Acresso Software
It looks like there is still an issue with this in the case that the Setup.exe is locked and scheduled to be removed after reboot. (In previous versions we also checked for the existence of setup.ilg before creating the "RunOnce" key, however this is not reliable since setup.ilg does not have to be there in order for the setup to run after reboot).
The workaround would be to delete the "RunOnce" value at the end of the setup. Unfortunately we since write the RunOnce key at the end of the seutp (after all script code has completed) this is currently not easy to do.
It should be possible for the setup to delete the setup.exe during the initial uninstall, are you specifying /runfromtemp when uninstalling. If you don't do this then setup.exe will be locked and will have to be replaced after reboot. (In previous versions this was not needed as we used an unreliable workaround that involved ctor.dll and "Rundll32").
Devin Ellingson
Software Developer
Acresso Software