BUG: Is(DOTNETFRAMEWORKINSTALLED,…) deletes INSTALLDIR property

[Reureu]

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:

• 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!!!

[Reureu]

Any idea?
Can Acresso confirm whether it is a bug? And possibly tell us if there is any plan to release a patch?

Regards

[joshstechnij]

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:

sOriginalInstallDir = INSTALLDIR;
// Call Is()...
// Restore INSTALLDIR.
MsiSetProperty(hMsi, "INSTALLDIR", sOriginalInstallDir);

[Reureu]

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:

• 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

[joshstechnij]

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.