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
- :
- BUG: Is(DOTNETFRAMEWORKINSTALLED,…) deletes INSTALLDIR property
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 02, 2009
09:36 AM
BUG: Is(DOTNETFRAMEWORKINSTALLED,…) deletes INSTALLDIR property
Hi,
I found an interesting bug today.
Calling both Is( DOTNETFRAMEWORKINSTALLED, REGDB_KEYPATH_DOTNET_20 ) and Is( DOTNETSERVICEPACKINSTALLED, "2|"+REGDB_KEYPATH_DOTNET_20 ) from an installscript custom action deletes the INSTALLDIR property, under certain conditions:
The MSI log file shows that the INSTALLDIR property is deleted
Consequences:
Remarks
What I don't understand is why the "Is" function interferes with the MSI properties, as it is only an InstallScript functions.
I have attached a dummy IS 2010 project that proves it.
Like many users, I am starting to wonder how IS 2010 could be released with so many bugs, as it is not the first one I report!!!
I found an interesting bug today.
Calling both Is( DOTNETFRAMEWORKINSTALLED, REGDB_KEYPATH_DOTNET_20 ) and Is( DOTNETSERVICEPACKINSTALLED, "2|"+REGDB_KEYPATH_DOTNET_20 ) from an installscript custom action deletes the INSTALLDIR property, under certain conditions:
- Basic MSI project (might also apply to InstallScript MSI project)
- The corresponding custom action in either the UI sequence or the ExecuteSequence is executed before CostFinalize
- Both Is( DOTNETFRAMEWORKINSTALLED …) and Is( DOTNETSERVICEPACKINSTALLED…) must be called, resulting in the following code
Is( DOTNETFRAMEWORKINSTALLED, REGDB_KEYPATH_DOTNET_20 );
Is( DOTNETSERVICEPACKINSTALLED, "2|"+REGDB_KEYPATH_DOTNET_20 );
The bug does not occur if you call only one of these functions
The MSI log file shows that the INSTALLDIR property is deleted
MSI (s) (F4!24) [15:22:41:415]: PROPERTY CHANGE: Deleting INSTALLDIR property. Its current value is 'C:\ABC\'.
Consequences:
- In such a scenario, one consequence can be that the INSTALLDIR property you specify when installing silently with the following code is ignored.
Setup.exe /s "/qn INSTALLDIR=C:\ABC"
Remarks
- If INSTALLDIR is empty, CostFinalize sets it to the default target folder
- If you call the custom action after CostInitialize, this bug does not occur
What I don't understand is why the "Is" function interferes with the MSI properties, as it is only an InstallScript functions.
I have attached a dummy IS 2010 project that proves it.
Like many users, I am starting to wonder how IS 2010 could be released with so many bugs, as it is not the first one I report!!!
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 05, 2009
02:46 PM
Any idea?
Can Acresso confirm whether it is a bug? And possibly tell us if there is any plan to release a patch?
Regards
Can Acresso confirm whether it is a bug? And possibly tell us if there is any plan to release a patch?
Regards
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 05, 2009
05:02 PM
I've submitted work order IOA-000052186 to address this issue in a future release. Note that this behavior has actually existed since InstallShield 11 due to a change in the VarSave and VarRestore functions specific to InstallScript custom actions (in Basic MSI and InstalllScript MSI projects) and InstallScript MSI events. The Is function (in this particular case) uses these functions to save and restore some global script variables that it modifies, and as a result of the change made to the VarSave/Restore functions in IS 11, INSTALLDIR is always saved and restored. Due to some implementation details of how INSTALLDIR is retrieved and set, it is possible for the VarSave and VarRestore functions to change the value of INSTALLDIR in a custom action sequenced before CostFinalize (mainly due to the fact INSTALLDIR as a target path is not initialized until after CostFinalize).
You can work around this behavior either by sequencing this custom action after CostFinalize or by saving the value of INSTALLDIR to a string variable before calling Is and then restore it by calling MsiSetProperty:
You can work around this behavior either by sequencing this custom action after CostFinalize or by saving the value of INSTALLDIR to a string variable before calling Is and then restore it by calling MsiSetProperty:
sOriginalInstallDir = INSTALLDIR;
// Call Is()...
// Restore INSTALLDIR.
MsiSetProperty(hMsi, "INSTALLDIR", sOriginalInstallDir);
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 06, 2009
01:20 AM
Hi Josh,
Thanks for your answer.
As you mentioned, implementing a workaround is easy.
Just 2 more questions, as I am trying to understand if this bug might have other consequences on my setup:
Regards
Thanks for your answer.
As you mentioned, implementing a workaround is easy.
Just 2 more questions, as I am trying to understand if this bug might have other consequences on my setup:
- Is there any other known MSI property that the Is(...) function modifies or deletes?
- This bug occurs when calling Is( DOTNETFRAMEWORKINSTALLED, REGDB_KEYPATH_DOTNET_20 ) and Is( DOTNETSERVICEPACKINSTALLED, "2|"+REGDB_KEYPATH_DOTNET_20 ) in a row. Does the bug also occur when calling Is(...) with other parameters?
Regards
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 06, 2009
11:42 AM
The VarSave and VarRestore functions are only called by Is for DOTNETFRAMEWORKINSTALLED and DOTNETSERVICEPACKINSTALLED. These functions will only attempt to save and restore the value of INSTALLDIR.
None of the other Is options should cause any INSTALLDIR changes since they do not use VarSave and VarRestore.
Another function that calls VarSave and VarRestore that can be called from InstallScript custom actions would include LaunchApplication/LaunchAppAndWait.
None of the other Is options should cause any INSTALLDIR changes since they do not use VarSave and VarRestore.
Another function that calls VarSave and VarRestore that can be called from InstallScript custom actions would include LaunchApplication/LaunchAppAndWait.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)