Summary This article discusses how to specify a condition for checking the Windows Registry in the case of a variable Windows Registry path. Project Type Basic MSI Problem Description During installation of software, the DatabaseFolder Dialog is displayed and the user may choose a folder and that folder path is stored in the [DATABASEDIR] property. From this, a registry value is created: Path = "HKEY_LOCAL_MACHINE\SOFTWARE\TEST Abc\[REGISTRY_SETUP_PATH]" where [REGISTRY_SETUP_PATH] is a property that will be set to different values depending on release flags The value name = "CommonFilesPath" The value data = "[DATABASEDIR][CommonFilesDirectoryName]" [DATABASEDIR]= Value entered in dialog "DatabaseFolder" [CommonFilesDirectoryName]= Property that will be set to different values depending on release flags. What is the condition if this Windows Registry value "CommonFilesPath" on path "HKEY_LOCAL_MACHINE\SOFTWARE\TEST Abc\[REGISTRY_SETUP_PATH]" already exists before then install starts? In this case this Windows Registry value should not be modified and the DatabaseFolder Dialog should not be displayed. Solution This can be achieved by using the following InstallScript code: 1. RegDBGetKeyValueEx - Use this function to get the Windows Registry value. function CheckIfCFRegistryValueExists(hMSI) STRING sRegistrySetupPath; NUMBER nRegistrySetupPathSize, nType; STRING sRegKey, sRegName, sRegValue, sErrorCode, szMsg; NUMBER nRegType, nRegSize, nErrorCode; STRING sCFRegistryValueExists; NUMBER nCFRegistryValueExistsSize; begin //Find exact path to registry. MsiGetProperty (hMSI, "REGISTRY_SETUP_PATH", sRegistrySetupPath, nRegistrySetupPathSize); RegDBSetDefaultRoot(HKEY_LOCAL_MACHINE); REGDB_OPTIONS = REGDB_OPTION_WOW64_64KEY; sRegKey = "SOFTWARE\\TEST Abc\\" + sRegistrySetupPath; sRegName = "CommonFilesPath"; sRegValue = "NONE"; nRegType = REGDB_STRING; nRegSize = -1; //Get value from registry if (RegDBGetKeyValueEx (sRegKey, sRegName, nRegType, sRegValue, nRegSize) < 0) then //Registry value doesn't exists. Set CFRegistryValueExists to "FALSE" MsiSetProperty(hMSI, "CFRegistryValueExists", "FALSE"); else //Registry value exists. Set CFRegistryValueExists to "TRUE" MsiSetProperty(hMSI, "CFRegistryValueExists", "TRUE"); endif; MsiGetProperty (hMSI, "CFRegistryValueExists", sCFRegistryValueExists, nCFRegistryValueExistsSize); end; Note: The InstallScript code is triggered by an InstallScript custom action configured for Immediate Execution. 2. Add a condition for the DatabaseFolder Dialog. The condition should be specified for the NewDialog Event the Next button that navigates to the DatabaseFolder Dialog. In this case, the condition would be: NOT CFRegistryValueExists ... View more

Summary This article discusses a scenario when the installer lays down components, such as DLLs, Windows Registry entries, or shortcut files, these components are getting installed as dynamic components. Project Type Basic MSI Symptoms When trying to not install any component as a dynamic component, there are duplicate components prefixed with a double underscore with a 65 appended and the components are being installed as dynamic components anyway. MSI (s) (28:C4) [18:00:52:463]: Component: Shortcut; Installed: Absent; Request: Local; Action: Local; Client State: Unknown MSI (s) (28:C4) [18:00:52:463]: Component: __ServerDLL65; Installed: Null; Request: Local; Action: Local; Client State: Null MSI (s) (28:C4) [18:00:52:463]: Component: __JDProcessorDLL65; Installed: Null; Request: Local; Action: Local; Client State: Null MSI (s) (28:C4) [18:00:52:463]: Component: __ProcessorDLL65; Installed: Null; Request: Local; Action: Local; Client State: Null MSI (s) (28:C4) [18:00:52:463]: Component: __Registry65; Installed: Null; Request: Local; Action: Local; Client State: Null MSI (s) (28:C4) [18:00:52:463]: Component: __NotificationReg65; Installed: Null; Request: Local; Action: Local; Client State: Null MSI (s) (28:C4) [18:00:52:463]: Component: __Shortcut65; Installed: Null; Request: Local; Action: Local; Client State: Null MSI (s) (28:C4) [18:00:52:463]: Component: JDProcessorDLL; Installed: Absent; Request: Local; Action: Local; Client State: Unknown MSI (s) (28:C4) [18:00:52:463]: Component: JDProcessorINI; Installed: Absent; Request: Local; Action: Local; Client State: Unknown MSI (s) (28:C4) [18:00:52:463]: Component: ProcessorDLL; Installed: Absent; Request: Local; Action: Local; Client State: Unknown Discussion There are cases where a component can install resources into locations other than the location referenced in the Directory_ column. In order to account for that and to more accurately adjust costing when a Directory's target location changes, such as when the user alters the install location, the installer uses a mechanism called cost-linking. For each alternate target folder for the component, the installer creates a new subcomponent. Cost-linking is used to account for the following MSI tables: Shortcut, RemoveFile, MoveFile, DuplicateFile, Registry,IniFile. Cost-linking is also used for all global/shared assembly components. Action start <time>: InstallValidate. MSI (s) <process info>: Feature: Simple; Installed: Absent; Request: Local; Action: Local MSI (s) <process info>: Component: Simple7890123456789012345678901234567890123456789012345; Installed: Absent; Request: Local; Action: Local MSI (s) <process info>: Component: __ Simple789012345678901234567890123456789065; Installed: Null; Request: Local; Action: Local For example, let's look again at the InstallValidate action dump from above for an example setup where the component installs both a file and a registry key. Note the subcomponent. That component was created to account for cost associated with the registry key. It's a cost-linked component for the component + WindowsFolder directory. The component's current cost (for the parent) is associated with the SimpleDir directory which is the authored directory for the component in the Component table. At this point, the component doesn't have any previously created child components so it starts with a suffix of 65. Also, only the first 40 characters were used of the component name (which had 55 characters). ... View more

Description: The suite installation is not resumed after a reboot prompt if the user clicks No on the reboot / restart prompt. Clicking Yes resumes the installation and the Basic MSI installer also resumes the installation after reboot, after the user clicks Yes or No on the reboot prompt. Steps to Reproduce:  Basic MSI Project: Create a Basic MSI project (ex. BMSITest.ism). Configure the ForceReboot Action by placing it after the RegisterProduct Action. Build the project. Run the installer. At the reboot prompt, click Yes or No. After the reboot the installation resumes in both the cases, after clicking Yes or No. Suite Project: Create a suite project. Add the Basic MSI project as a package in the suite installer. Build the project. Run the suite installer. After the restart, the suite installation resumes if the user clicks Yes at the reboot prompt. If the user clicks No at the reboot prompt, the installation is not resumed after the reboot. Behavior: The suite installer handles clicking No as equivalent to clicking Cancel. Explanation of the behavior: Note: The ForceReboot action must be given a condition of NOT AFTERREBOOT; otherwise, the reboot will get stuck in a loop. Test Scenario# 1: A compressed MSI package built from the Basic MSI project: Launch the MSI setup with the following command line: ForceRebootMSI.msi /l*v "C:\Log\ForceRebootBasicYes.log" The user needs to click Yes at the reboot prompt. The Windows Registry entry will created under: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\RunOnceEntries with a value of: {3BC02749-19DA-4FA7-A3DC-5B172C36D7FC}" AFTERREBOOT=1 RUNONCEENTRY="!94720CB3AD917AF43ACDB571C2637D" /qF /lmewuifsoarpcv+ "c:\tmp\ForceRebootBasicYes.log" The Windows Registry RunOnce entry value clearly indicates that the MSI package will be launched in Full UI (/qf) Mode. More details on MSI command line parameters can be found here.  Test Scenario# 2: The same as Test Scenario# 1, except for the user clicking No during the reboot prompt. The same Windows Registry entry gets added to the RunOnce Windows Registry entry. The only difference is that the user needs to manually restart in this scenario. After restart, the user can see the same MSI setup being launched. Test Scenario# 3: Add a compressed MSI package to the suite installer. Enable logging support under the Packages -> Package -> Common Tab with the following options selected: Enable Logging Support: Yes LogFile: SuiteForceRebootMSIYes Log Options: *v Enable logging option for the suite project as well by navigating to Releases -> Release -> Setup.exe -> Set Always Create Debug Log: Yes and  specify a Log File Name. Build the project. Launch the suite installer's setup.exe with the following command line: Setup.exe /log"C:\Log" Note: Only the log folder has to be specified, since the filename was already configured. Select Yes at the reboot prompt. The Windows Registry entry will be added under: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\RunOnceEntries with a value of:                                                              "{3BC02749-19DA-4FA7-A3DC-5B172C36D7FC}" AFTERREBOOT=1 RUNONCEENTRY="!94720CB3AD917AF43ACDB571C2637D" /qN /lewuioarpcv+ "c:\tmp\SuiteForceRebootMSIYes.log"  The MSI setup starts and MsiInstallProduct returns code 1641 which means: ERROR_SUCCESS_REBOOT_INITIATED 1641 The installer has initiated a restart. This message is indicative of a success. 0x669 0x80070669   The suite installer will create a Windows Registry entry under: HKEY_CURRENT_USER\Software\InstallShield\SuiteInstallers\<Suite-GUID>\REBOOT with value 1 After restart, the suite installer will get launched and finish the execution. The MSI package will be installed silently. Test Scenario# 4: Add a compressed MSI package to the suite installer. Click No at the reboot prompt. After the user clicks No at the reboot prompt, the suite installer will be interrupted with error code 1602 from MsiInstallProduct which means: ERROR_INSTALL_USEREXIT 1602 The user cancels installation. 0x642 0x80070642   No suite installer REBOOT Windows Registry entry will be created. The suite handles this test case differently than the MSI setup. The suite installation does not take place, but the MSI installation takes place. This is because Windows Installer (MSI) handles reboots differently. After a manual reboot, the MSI package gets installed silently. But the suite installation does not take place because the suite installer assumes that the user canceled the installation. ... View more

As a courtesy Installshield provides many common Prerequistes already built and to used straight away within your project. Sometimes however a prerequisite that you require may not be available - or you may need to create your own custom prerequisite. In these cases you can use Installshield's Prerequiste Editor to create your own using the steps below: 1. Select Tools → Start Prerequisites Editor       2.Go to File→ Save as → Name the file (ex:Notepad++), save that .prq file into C:\Program files\InstallShield\2019\SetupPrerequisites. 3. Condition: 4.  Select Files to include→ click on add and browse the file which you want to add it as a prerequisites file,                                                                                    5.On the Application to run tab, Select the application you wish to launch               5.Save and close the window.         6.Go to Redistributables View- > Refresh and search notepad, now you can see the Notepad++ prerequisites available                                                                                                             ... View more

Summary: This article discusses the difference between a public MSI property and a global InstallScript variable. Public Property (Basic MSI Project): Public properties have names that contain only uppercase letters. For example, INSTALLDIR is a public property. Public properties can be specified at the command line used to launch the installation or chosen by using an authored user interface. If you are creating your own properties, use all uppercase letters if you want end-users to have access to these properties. In order to allow the end-user or administrator to change the destination via the user interface or from the command line, the Directory Identifier for the component’s destination must be a public property. Note: Only public properties have their values preserved from an installation’s user interface and User Interface Sequence to the point where the installation is changing the target system, known as the Execute Sequence. If you set the value of a property in a dialog box displayed to the end-user, use a public property (for example, MY_PUBLIC_PROPERTY) if you want its value written to a file or to the Windows Registry. The value of a public property is passed on from the User Interface Sequence (in which the dialogs are shown) to the Execute Sequence (in which the system is modified). Additionally, only public properties can be specified at the command line as parameters passed to msiexec.exe which is the main executable for running an MSI (Windows Installer) package. Therefore, make sure that you use a public property to store the value for a UI control (EditBox, ComboBox, etc.) if you want its value to be available in the Execute Sequence, for instance, if the value of this property is written to the Windows Registry. Global Variable (InstallScript Project): A global variable in the program is a variable defined outside the subroutine or function. It has a global scope means it holds its value throughout the lifetime of the program. Hence, it can be accessed throughout the program by any function defined within the program, unless it is shadowed. If you want to use the global variable in another .rul file, you have to include the .rul file which declares the global variable. Global Variable (InstallScript MSI Project): OnFirstUIAfter is called by the InstallScript engine after the MSI finishes, so you can't access MSI properties with public properties. It's possible with setting a global variable in OnFirstUIBefore and using that in OnFirstUIAfter. ... View more

Summary: This article discusses whether it is possible to download a file using the HTTPS protocol by using the CopyFile InstallScript function. Discussion: There is no option from an InstallScript point of view. The CopyFile InstallScript function, discussed in the documentation here, only supports the HTTP protocol, not HTTPS. If you receive a certificate error like the following: we can override this type of certificate error from a C++ or .NET DLL using a managed or unmanaged code custom action. Or we can use the UseDLL InstallScript function, in the documentation here, for unmanaged code and DotNetCoCreateObject for .NET, in the documentation here, to load / call a DLL from InstallScript, which has a custom download mechanism implementation. ... View more

Symptoms: The following error message is displayed at runtime: Cause: The issue is happening due to the short filename in the FileName column that is added by design when a long filename is referenced in the project. Workaround: This issue can be resolved by installing the Microsoft ODBC Driver 17 for SQL Server as a prerequisite and changing the msodbcsql17.dll FileName from [MSODBC~1.DLL|msodbcsql17.dll] to [msodbcsql17.dll] in the File table of  the Direct Editor. Or by i nstalling the MSI from here and removing the short filename from the File table in the Direct Editor. ... View more

Description: Build warning -9033: The conversion process does not support data in the MSI table 'RemoveRegistry.' Cause: This error is encountered when the Windows Installer package that is being converted includes the RemoveRegistry table. During the conversion process, the RemoveRegistry table is not read. Resolution: The RemoveRegistry table contains the Windows Registry information the application needs to delete from the system registry. If this removal requirement is just a cleanup step that does not impact the function of the application, you do not need to address this issue. However, if the existence of the registry keys listed in the RemoveRegistry table prevents the application from functioning, you need to set the isolation option of the registry keys to Ignore so that they are not visible to the isolation environment (network, servers, App-V).  The isolation option that is assigned to a file, folder or registry key specifies how the isolation environment will provide access to system resources requested by the application.  The Ignore option directs the isolation environment to always look for the registry key on the system, ignoring the one inside the isolation environment. For example, s uppose you have an isolation option for  C:\Windows  and one for  C:\Windows\System32 . When the application requests  C:\Windows\System32\Notepad.exe , then the  C:\Windows\System32  isolation rule will be applied because  C:\Windows\System32  is a more specific reference to  C:\Windows\System32\Notepad.exe  than is  C:\Windows . ... View more

Synopsis: The MSI package displays a User Account Control (UAC) prompt for Administrator privileges multiple times to install the application. This is after creating a Basic MSI package with no setup launcher setup.exe by selecting No for the Setup Launcher setting in the Releases View under the Release > Setup.exe Tab. The user needs to be able to run the MSI as invoker with no Administrator privileges being required to run the target application. Cause: The value of the ALLUSERS property, at install-time, determines the installation context. The value ALLUSERS=2 enables the system to reset the value of ALLUSERS and the installation context depending on the user's privileges and the Windows version. Resolution: An ALLUSERS property value of an empty string ("") specifies the per-user installation context. If the value of the ALLUSERS property does not equal 2, the value of the MSIINSTALLPERUSER property is ignored and has no effect on the installation. The value of MSIINSTALLPERUSER property is ignored when installing the package using Windows Installer 4.5 or 5.0.x. When elevated privileges are not required to install a Windows Installer package, the author of the package can suppress the dialog box that User Account Control (UAC) displays to prompt users for administrator authorization. To suppress the display of the UAC dialog box when installing the application, the author of the package should do the following: Install the application using Window Installer 4.0 or later on Windows Vista. Do not depend on using elevated system privileges to install the application on the computer. Install the application in the per-user context and make this the default installation context of the package. If the ALLUSERS property is not set, the installer installs the package in the per-user context. If you do not include the ALLUSERS property in the Property Table, the installer does not set this property and so a per-user installation becomes the default installation context. You can override this default by setting the ALLUSERS property on the command line. Set Bit 3 in the Word Count Summary property to indicate that elevated privileges are not required to install the application. ... View more

Synopsis: Though there is no built-in tooltip support for InstallScript or InstallScript MSI projects, the project can be customized by writing tooltip functionality as described in the official Microsoft documentation at this link: https://docs.microsoft.com/en-us/windows/win32/controls/create-a-tooltip-for-a-control Also, here is a link to a CodeProject sample which has already Edit control's tooltip function been implemented, see the Balloon Tips Section: https://www.codeproject.com/Articles/162933/Programming-User-Interface-in-InstallScript If the expectation is to add pretext to the edit control, like "Enter Text Here," this can be achieved by editing the custom or predefined dialog's function with the CtrlSetFont function. Sample CtrlSetFont function InstallScript code is here. ... View more

Description: Need to define a custom MSI property and define a value for it. Depending on the property value the installer should conditionally display a custom dialog. For example: Define a property BuildType and define a value for it Beta. If the property value is Beta then the installer should display a custom dialog. If the value is something else, such as Release, then the installer should not display a dialog. Solution: Basic MSI Project: Create an MSI property named BuildType with value Beta and use that MSI property in a condition to determine whether to display a dialog. For example: Action: Hide; Condition: Not BuildType1 Action: Show; Condition: BuildType1 InstallScript code in the same Basic MSI project: MsiGetProperty (hMSI, "BuildType", svName, nvSize); if(svName=="Beta") then _WinSubShowWindow(hwnds,1); _WinSubEnableControl(hwndDlg,TXTBOX,1); else if (svName =="Release")then _WinSubShowWindow(hwnds,0); _WinSubEnableControl(hwndDlg,TXTBOX,0); endif; ... View more

Summary This article discusses what to do if the CtrlGetMultCurSel InstallScript function is not selecting all items. Project Type InstallScript InstallScript MSI Symptoms As CUSTOMERCARE1 is already part of CUSTOMERCARE1SBOX the CtrlSetMultCurSel always highlights first one, not select all. Diagnosis case SELECT_ALL_BAD_BUTTON: nResult = ListGetFirstString(lBad, szSelectAllBad); // Loop while not at end of list. while (nResult != END_OF_LIST) CtrlSetMultCurSel(szDlg, LIST_BAD, szSelectAllBad, TRUE); // Get the next string in the list. nResult = ListGetNextString(lBad, szSelectAllBad); endwhile; ListDestroy(lBad_Selected); lBad_Selected = ListCreate(STRINGLIST); CtrlGetMultCurSel(szDlg, LIST_BAD, lBad_Selected); nCountBadSelected = ListCount(lBad_Selected); if (nCountBad != nCountBadSelected) then MessageBox("Select All did not properly select all systems in the list. Please manually select the missing.", WARNING); endif; LB_FINDSTRING finds the first string in a list box that begins with the specified string and it finds first substring szBadList = "CUSTOMERCARE1SBOX,CUSTOMERCARE1,CUSTOMERCARE2SBOX,CUSTOMERCARE2"; ​ As CUSTOMERCARE1 is already part of CUSTOMERCARE1SBOX the CtrlSetMultCurSel always highlights the first one instead of selecting all. Solution // Included header files ---------------------------------------------------- #include "ifx.h" #define EXIT_BUTTON 1305 #define SELECT_ALL_GOOD_BUTTON 1303 #define SELECT_ALL_BAD_BUTTON 1304 prototype dlg_GetCPSystemNames(); function NUMBER dlg_GetCPSystemNames() STRING szDlg, szMsg; STRING szFirstSystem, szSelectAllGood, szSelectAllBad; BOOL bDone, bAbort; NUMBER nReturn, nResult, nCmdValue, nCountCPSystemNames, nCountCPSelectedSystemNames, nId; NUMBER nCountGood, nCountBad, nCountGoodSelected, nCountBadSelected; HWND hInstance, hwndParent, hwndDlg; LIST lGood, lBad, lGood_Selected, lBad_Selected; STRING szGoodList, szBadList; begin szDlg = "_dlg_SelectAll"; nResult = EzDefineDialog(szDlg, "", "", DLG_ID_SELECTALL); case SELECT_ALL_BAD_BUTTON:                 nResult = ListGetFirstString(lBad, szSelectAllBad);                 hwndDlg = CmdGetHwndDlg(szDlg);                 hwndCntrl = CtrlGetDlgItem("", hwndDlg, LIST_BAD);                 SendMessage(hwndCntrl, LB_SETSEL, TRUE, -1);                                 ListDestroy(lBad_Selected);                 lBad_Selected = ListCreate(STRINGLIST);                 CtrlGetMultCurSel(szDlg, LIST_BAD, lBad_Selected);                 nCountBadSelected = ListCount(lBad_Selected);                 if (nCountBad != nCountBadSelected) then                     MessageBox("Select All did not properly select all systems in the list. Please manually select the missing system(s) by holding the CTRL key on your keyboard and clicking with your mouse.", WARNING);                 endif;   end; CtrlSetMultCurSel function uses LB_FINDSTRING message finds the first string in a list box that begins with the specified string and it finds first substring szBadList = "CUSTOMERCARE1SBOX,CUSTOMERCARE1,CUSTOMERCARE2SBOX,CUSTOMERCARE2"; CUSTOMERCARE1 is already part of CUSTOMERCARE1SBOX the CtrlSetMultCurSel always highlights first one hwndDlg = CmdGetHwndDlg(szDlg); hwndCntrl = CtrlGetDlgItem("", hwndDlg, LIST_BAD); SendMessage(hwndCntrl, LB_SETSEL, TRUE, -1); Adding the code, referenced above, should fix the problem. Also, hwndCntrl needs to be defined at the top: HWND hInstance, hwndParent, hwndDlg, hwndCntrl; ... View more

Set Max Product Version (VersionMax) in the Upgrade table at build time can be achieved in Two ways, 1. Use COM object: ISWiProject.ISWiUpgradeTableEntries.VersionMax InstallShield exposes a COM interface that allows you to perform many of the same tasks from a program, such as a Visual Basic executable, or a script, such as a VBScript file in Windows Scripting Host. By calling methods, setting properties, accessing collections, and so on, through the automation interface, you can open a project and modify its features and component data in many of the same ways that you would in the InstallShield interface. Automation Objects: Each InstallShield automation object represents an installation element such as a feature, a component, or a file. This section describes each of the InstallShield automation objects. The highest-level object in the automation interface is the ISWiProject object. The first thing you must do to access the interface is create this object. Then, you can use its objects, methods, and properties to modify your project. ISWiUpgradeTableEntry represents an upgrade item in the Upgrades view of InstallShield. You can retrieve an upgrade item by specifying an item in the ISWiUpgradeTableEntries collection. 2. Modify .ism project files directly as XML Ex for ISWiUpgradeTableEntries: Dim oProj As ISWiProject Dim oUpgradeItem As ISWiUpgradeTableEntry Set oProj = New ISWiProject oProj.OpenProject "C:\MySetup.ism" For Each oUpgradeItem In oProj.ISWiUpgradeTableEntries oUpgradeItem.Language = "1033" Next oProj.SaveProject oProj.CloseProject To target a specific item, replace the For Each loop in the above code with this code: For Each oUpgradeItem In oProj.ISWiUpgradeTableEntries If oUpgradeItem.UpgradeCode = "{12345678-1234-1234-1234-123456789012}" Then oUpgradeItem.Language = "1033" End If Next ... View more

Deferred Execution: Unlike deferred execution actions, rollback execution actions launch only during rollback. Custom actions can only be sequenced between the InstallInitialize and InstallFinalize actions in execute sequence tables. Custom actions don’t have access to the Installation database. Custom actions can run both in the context of the user and elevated using the system context Deferred execution in system context: Like deferred execution actions, deferred-execution-in-system-context actions do not launch until the script that generated by the Windows Installer is run. However, actions of this type execute with no user impersonation. If the Custom action which installs or modify the system file directly should be run in “Deferred Execution in System Context”. Deferred custom actions must be made in system context if they need to make system changes that require elevated privileges ... View more

Error: Reading 'Extension' table... skipping non-existent table ISDEV : warning -9019: There exist one or more conditionalized components which may not be converted correctly Conditionalized Component: KTGina.dll ISDEV : warning -9018: Custom action 'def_isc_EndOfInstall' will be ignored ISDEV : warning -9033: The conversion process does not support data in the MSI table 'RemoveRegistry'. See the help library for details on resolving this warning. ISDEV : warning -9053: 3 launch condition(s) will be ignored. This message can be suppressed for launch conditions that are not required for a successful conversion by adding them to msi.xml. Cause: After upgrading a project from a previous InstallShield version to the latest InstallShield version, for example, after upgrading a project from InstallShield 2015 to InstallShield 2020, Build Windows App Package under the Releases -> Release -> APPX/MSIX Tab is set to Yes. Solution: After upgrading a project from a previous InstallShield version to a newer InstallShield version, InstallShield  may automatically build an MSIX package. If an MSI package does not need to be built, Build Windows App Package under the Releases -> Release -> APPX/MSIX Tab should be set to No.  If this option is set to No, a MSIX package will not be built, only an MSI package will be built. ... View more