In the article provided - Windows reports the deletion of the TEMP directory as an Issue and provides workaround solutions for it. I do not read the article that the deletion of the TEMP directory is an intended feature and something that should be supported by 3rd party applications. An Installshield compressed setup.exe requires the TEMP directory to extract files during installation (this was different in earlier versions of Installshield such as IS2015). The solution here would be to follow Microsoft's suggestions for the workaround. Alternatively if this is a common issue for the environment that your application installs into - using an uncompressed build release would remove the need to extract the files to the TEMP directory. ... View more

Perfect solution - and one that I would have suggested. If further down the line things become more complex and more features are introduced which are optional and don't require the shared files - you can look into creating conditions for the Feature C to only install if specific other features are selected. ... View more

Are the common files installing to the same directory? If so this would break Component Rules - https://learn.microsoft.com/en-us/windows/win32/msi/what-happens-if-the-component-rules-are-broken "If two components have a resource under the same name and location and both components are installed into the same folder, then the removal of either component removes the common resource, which damages the remaining component." ... View more

Installshield is designed to create Installers for Windows OS - it isn't tested to create installers that support emulators on other OS types. In addition Installshield 12 was End-of-lifed 12 years ago in 2010, so again support for this will be limited. I did find the following article on an ubuntu forum which may help configure Wine to do what you want. https://ubuntuforums.org/showthread.php?t=2322134 ... View more

The -6138 error can be seen when the setup.rul has been removed from the project - but there is still something within your project which is referencing the script file. This could be a custom action which expects the setup.rul to be present to run.  Check through your project to make sure that nothing has been orphaned and is still attempting to reference the Installscript file. ... View more

As the previous versions were not following upgrade best practices - its not possible to determine their behaviour. It is possible to identify that the Major Upgrades that you were previously creating were not incrementing the Product Version correctly. I understand that previous versions were working using the method of using the 4th ProductVersion field - however as windows installer does not read the 4th field - this is not seen as a change. Therefore the criteria of a Major Upgrade have not been met - and its possible that the "RemoveExistingProducts" standard action is not being started correctly as no upgrade has been identified. We can only assume that it is lucky that you have not encountered issues sooner. If you test increasing the productversion using only the first 3 fields to 7.2.1 - does this correct the behaviour or is the issue still present? ... View more

Windows Installer doesn't read the 4th value in a ProductVersion property, it will only read the first 3. This would mean that during the upgrade Windows Installer will not recognise the increase in the ProductVersion number and therefore upgrade rules are not being followed. There is more information the ProductVersion property here: https://learn.microsoft.com/en-us/windows/win32/msi/productversion Try creating your Major Upgrade by upgrading from 7.2.0.1 to 7.2.1.0 In addition make sure that you are correctly creating a Major Upgrade by following the steps provided here: https://community.flexera.com/t5/InstallShield-Knowledge-Base/Create-a-Major-Upgrade/ta-p/3879 Hope this helps. ... View more

Sorry for any confusion - the name of MSI is taken from the ProductName property. Changing this is not supported for a Windows Installer Minor upgrade. ... View more

There are quite a few limitations that Minor Upgrades can introduce due to how the Windows Installer Engine behaves. Unfortunately changing the name of the .msi package is not a supported feature for Minor Upgrades, and therefore a Major Upgrade would be required. The following article if really useful and shows what is and is not supported for each of the upgrade types: https://docs.revenera.com/installshield28helplib/helplibrary/MajorMinorSmall.htm?Highlight=productname ... View more

This CVE reports that only apps that call zlib's 'inflateGetHeader' method are affected. Neither InstallShield nor other third party components used in InstallShield are calling this method and therefore Installshield is not affected by this vulnerability. I hope this helps. ... View more

You would need to create a new Dialog for your suite installer which requests this information from your customer - this information can then be stored in a property by the suite installer, and passed to your MSI's via a command line. You should see the Property to populate in the control settings in the Wizard Interface of your suite project.   If the command line for each MSI is authored correctly this would pre-populate the information in the Installation process for your customers. Alternatively you can use the command line to instruct the MSI's to install silently using the property information that you provide. Information on how to pass property's from the suite to the MSI package can be found here: https://community.flexera.com/t5/InstallShield-Knowledge-Base/Passing-a-Suite-Property-to-Command-Line-of-Package/ta-p/4378 ... View more

Take a look at the following knowledge base article which explains possible reasons and resolutions for this build error: https://community.flexera.com/t5/InstallShield-Knowledge-Base/Build-Error-1001/ta-p/3628 ... View more

Rather than attempting to dynamically alter the combo box, could you create duplicate dialogs which are displayed depending on what the user selects? ... View more