Accessing a string from an installscript function in a commit custom action

[Reureu]

Hi,

I am working on a Basic MSI project with IS 2010.
This project was originally built with IS 2008.

My project uses a custom action set to commit execution.

This custom action calls an Installscript function that performs a few checks, and displays an error dialog under certain conditions.

This dialog is displayed using the SprintfBox function, with some strings from the ISString table as parameters, ie

SprintfBox( INFORMATION, @ID_String_Title01, @ID_String_Message01 );

This function correctly displayed the error message when we built the setup with IS 2008.
Now we are building the setup with IS 2010, the error message is no longer displayed properly, but the name of the strings are shown instead.
If I schedule the custom action for immediate execution, the message is correctly displayed.

My questions:

• Can an Installscript function no longer access strings of the ISString table in a custom action scheduled for either commit or deferred execution?
  
• Is it expected, or is it a bug of IS 2010?
  
• Is it documented anywhere?
  
• Is there any workaround?
  

Regards

[Reureu]

Hi,

I can confirm that this was due to a bug in ISSetup.dll

The issue no longer occurs if I use ISSetup.dll version 16.0.0.329 available in Q205590.

http://kb.acresso.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q205590&sliceId=

Apparently, this new version of ISSetup.dll does not only fix the issue described in Q205590, but also fixes other non-documented problems.

Question to the Acresso developers:

• Is there any other non-documented problem fixed in this new version of ISSetup.dll you want to tell us about?
  

Maybe the Acresso team should update the issue description of Q205590 to describe all the problems that this new version solves?
Or even better, deploy all the fixes through the InstallShield 2010 Software Manager? That would be a good move, wouldn't it?

Regards

[joshstechnij]

The original issue could affect any string table handling in deferred, rollback, or commit InstallScript custom actions. Unfortunately, we do not have a comprehensive list of all the possible issues that could have been caused by the change that was in the RTM release of IS 2010.

The issue described by KB Q205590, while not mentioned, was caused by a change to how the language ID of the running setup is determined in InstallScript custom actions. The ID can always be determined in immediate custom actions because the ProductLanguage property can be read by the InstallScript engine. In non-immediate custom actions this property is not available and therefore the engine makes a best-effort attempt at determining what language should be used. This language ID is used to determine which string table should be used by the script engine. The change in IS 2010 caused a language ID of 0 to be used when the engine could not determine what the product language was (and there is never a StringTable0000.txt string table built).

Regarding hotfixes, these are typically delivered through KBs instead of the Software Manager as they do not necessarily affect everyone using the product. Hotfixes are almost always rolled up into a service pack that is delivered through Software Manager.

[Sairen]

I ran across this issue looking for a solution to what seemed a totally different problem. Windows Installer service was crashing towards the end of my installation, and I managed to track it down to an InstallScript custom action sequenced in the Commit sequence.
(I need to acknowledge help from George on Acresso's support group here for helping me get that far - thanks, George!)

The crazy thing was
1) I've been using this particular function without incident for a really long time (upwards of 2 years?) on a wide variety of IS versions, operating systems, and install packages
2) There's not much to it. This is it:

//---------------------------------------------------------------------
// function: RemovePreviousPackage_COMMIT
// purpose: Deletes backup folder.
//---------------------------------------------------------------------
function RemovePreviousPackage_COMMIT(hMSI)
	STRING szBackupPath, sCommonAppDataFolder;
	NUMBER nBuff;
begin         
	MsiGetProperty(hMSI, "CustomActionData", sCommonAppDataFolder, nBuff);
	szBackupPath = sCommonAppDataFolder ^ "Downloaded Installations\\InstallTemp";
	
	//if (AskYesNo("Backup Path: " + szBackupPath + " Is this correct?", YES) = 1) then
		DeleteDir(szBackupPath, ALLCONTENTS);
	//endif;
	
end;

It looked like the function wasn't even getting executed since that message box I have in there wasn't even appearing. So I tried grabbing this new ISSetup.dll, just in case there was something new and different in the way InstallScript functions are handled.

Lo, it fixed it. The only connection I see is in Josh's mention of the String0000.txt. When I was first debugging this, I thought it was something in the action RollbackCleanup, since the error happened close to that time and I saw this in the log:
Extracting support file String0000.txt to C:\Users\{bla bla}
Failed to extract file String0000.txt. Error = 0

So I'm not 100% about how this connects, but I can see why it might be. Guess I just need to keep closer tabs on that RSS feed of KB articles... hope this helps someone else.