Appx/MSIX Tab for a Release

InstallShield 2022 » Releases View » Release

Project:The Appx/MSIX tab is available in Basic MSI projects.

Windows app package (.appx/.msix) creation is enabled in the per-release tab titled Appx/MSIX tab. Here, some core settings can be specified that impact the Windows app package build process.

The Appx/MSIX tab settings are organized into the following main categories:

General 
App Installer Settings
Package Identity Overrides 
Display Properties 

General Settings

Use the General area on the Appx/MSIX tab to specify whether a Windows app package (.appx) will be built as part of building the release and to specify other core settings that impact the build process such as choosing whether to include desktop extensions or server extensions.

General Settings on the Appx/MSIX Tab

Setting

Project Type

Description

Build Windows App Package

Basic MSI

Specify whether you want a Windows app package (.appx/.msix) to be built as part of building this release.

Available options are:

Yes—Build the Windows app package (.appx/.msix). Choose Yes if you want to:
Distribute your app through the Windows Store.
Target Windows Server Nano.
Sideload a Appx/MSIX that leverages the Universal Windows Platform.
No—Do not build the Windows app package. If you select No, only the .msi will be built.

Package Type

Basic MSI

Choose a package type. This setting coverts your Windows desktop application to the modern Windows app packaging format. The available drop-down options are:

APPX - Build the Windows App Package
MSIX - MSIX is the next generation software deployment model for Windows platform, bringing in the best of MSI, AppX and App-V - together in a single package. MSIX has the capability to run a traditional Win32 app in a container, achieving application isolation, ease of deployment, fully clean uninstallation and seamless software updates all at the same time.
Both - Builds both .appx and .msix packages.

Distribution Method

Basic MSI

Choose a distribution method for your Windows app package. This setting directs which set of warnings are issued for potential problems related to Windows Store policies or requirements related to sideloading. Available drop-down options are:

Direct Distribution (Sideload)—Distribute a Windows app package without having it downloaded from the Windows Store. Sideloaded apps have not been certified by the Windows Store. A common example of a sideloaded app is one that is distributed to an enterprise environment and is internal to a company only. If a package will be sideloaded, you will typically need to sign it, unless your customer wishes to sign it themselves.
Windows Store—Distribute a Windows app package through the Windows Store. When this option is selected, additional warnings will be issued for items that are known to be rejected by Windows Store policy despite the build being valid in a sideloading scenario. If a package will be distributed through the Windows Store, it is subject to additional policies that limit its contents. This type of app doesn't need to be signed before it is uploaded to Microsoft because Microsoft signs the package.

Include Desktop Extensions

Basic MSI

Choose whether to include "full trust" apps and other Desktop Bridge extensions as part of the core Windows App package (.appx/.msixWindows App) format. If you want to enable your desktop apps to start leveraging Universal Windows Platform (UWP) APIs, you should enable desktop extensions.

If you select No, warnings are issued for any such items that cannot be represented.

If you select Yes, additional subsettings can be configured as needed to specify a minimum Windows version and maximum tested Windows version supported by the included apps and desktop extensions.

Tip:When using InstallShield to create a Windows App package, choose to include either desktop extensions or server extensions, but not both. Although a Windows App package can contain both desktop and server extensions, targeting one set over the other is a more likely scenario.

Minimum Version

(under Include Desktop Extensions)

Basic MSI

Optionally, specify the app's minimum supported Windows version number. If you leave this blank, the minimum version number of Windows 10 Anniversary Update is assumed.

The version must contain only numbers and it requires four parts using the following format (with values in each part ranging from 0 to 65535): majorversion.minorversion.buildnumber.revisionnumber, such as:

1.0.0.60325

Use as few characters as possible. For example, do not use unnecessary leading zeros; instead of entering 14.00.25.1, enter the following:

14.0.25.1

Tested Version

(under Include Desktop Extensions)

Basic MSI

Optionally, specify the app's maximum supported tested Windows version number. If you leave this blank, this setting defaults to match the Minimum Version (or the minimum version number of Windows 10 Anniversary Update if nothing is specified for Minimum Version).

The version must contain only numbers and it requires four parts using the following format (with values in each part ranging from 0 to 65535): majorversion.minorversion.buildnumber.revisionnumber, such as:

1.0.0.60325

Use as few characters as possible. For example, do not use unnecessary leading zeros; instead of entering 14.00.25.1, enter the following:

14.0.25.1

Include Server Extensions

Basic MSI

Choose whether to include Windows Server extensions as part of the core Windows App package (.appx/.msixWindows App) format, thus creating a Windows Server App. If you want to target Windows Server Nano's installation package format and deploy a service, WMI provider, event source, or performance counter, you should enable server extensions.

If you select No, warnings are issued for any items that cannot be represented.

If you select Yes, additional subsettings can be configured as needed to specify the minimum Windows Server operating system and maximum tested Windows Server operating system supported by the included apps.

Tip:When using InstallShield to create a Windows App package, choose to include either desktop extensions or server extensions, but not both. Although a Windows App package can contain both desktop and server extensions, targeting one set over the other is a more likely scenario.

Include MSIX Core Extensions

Basic MSI

The MSIX Core enables the installation of MSIX apps on previous versions of Windows, provided the apps are already built to work on those versions of Windows.

The MSIX Core is built for the following Windows versions that do not currently support MSIX:

Windows 7 SP1 - 6.1.7601.0
Windows 8.1 Update 1 - 6.3.9600.0
Windows 10 2015 LTSB (1507) - 10.0.10240.0
Windows 10 2016 LTSB (1607) - 10.0.14393.0
Windows Server 2008 R2 - 6.1.7601.0
Windows Server 2012 - 6.2.9200.0
Windows Server 2012 R2 - 6.3.9600.0
Windows Server 2016 - 10.0.14393.0

By default, the No option is selected. The possible options are:

No - When you select this option, the MSIX Core entry will not be added to the manifest file.
Yes - When you select this option, the MSIX Core entry will be added to the manifest file along with the specified minimum Windows version and maximum tested Windows version.

Tip:The MSIX Core package needs MSIX pre-requisite to be installed on the older package.

Minimum Version

(under Include Server Extensions)

Basic MSI

Optionally, specify the app's minimum supported Windows version number. If you leave this blank, the minimum version number of Windows 7 SP1 Update (6.1.7601.0) is assumed.

The version must contain only numbers and it requires four parts using the format of majorversion.minorversion.buildnumber.revisionnumber (with values in each part ranging from 0 to 6553).

Tested Version

(under Include Server Extensions)

Basic MSI

Optionally, specify the app's maximum supported tested Windows version number. If you leave this blank, this setting defaults to match the maxium MSIX core supported version number 10.0.14393.0 (Windows 10 2016 LTSB - 1607).

The version must contain only numbers and it requires four parts using the format of majorversion.minorversion.buildnumber.revisionnumber (with values in each part ranging from 0 to 65535).

Framework Dependencies

Basic MSI

Select the retail or debug build of the C++ runtime that matches the one used in your product.

Note:This setting does not cause the dependency packages to be installed in sideloading scenarios. For those scenarios, the dependency may have to be delivered manually. Also, the debug versions of the of the C++ runtime are only useful for internal testing and cannot be uploaded to the Windows Store. For local testing or sideloading, you may also have to deploy the framework package that is included in the Windows 10 SDK.

Merge Dependencies

Basic MSI

Edition:This setting is available in the Premier edition of InstallShield.

Specify a list of Windows App packages to merge into the resulting package. Click the ellipsis button (…) to browse for a Windows App package (.appx/.msixWindows App), or type one or more paths directly in this setting, separated by semicolons.

Registry data and files from the VFS are copied into this package, but any duplicates of data already in the package are omitted.

App Installer Settings

Use the App Installer Settings area on the Appx/MSIX tab to generate an App Installer file and configure package update capabilities.

An App Installer file is an XML document (*.appinstaller) that contains set of attributes for defining the package properties and the location where it has been deployed. The App Installer file is introduced as of Windows 10 Version 1709. It specifies where your app package is located and how to update it. If you choose to use this method of app distribution, you must share with your users the App Installer file, instead of the actual app package. The user must then click on the App Installer file. At this point the familiar App Installer UI will appear and guide the user through the installation. Once the user has installed the application using these steps, the application is associated with the App Installer file.

Later, when you have an update to the application, you only update the App Installer (.appinstaller) file. When you update the file, the new version of the application is pushed to the user automatically based on settings configured 'Update Settings' section below.

Refer App Installer File Schema for more information.

App Installer Settings on the Appx/MSIX Tab

Setting

Project Type

Description

AppInstaller File URL

Basic MSI

Specify App Installer file location.

The App Installer file can be hosted in a shared location like a HTTP endpoint or a UNC shared folder or a local file share, and includes the path to find the MSIX packages to be installed. Users install the app from the shared location or from the web and enable periodic checks for new updates.

AppInstaller Version

Basic MSI

Specify the version of App Installer file. A version string in quad notation, 'Major.Minor.Build.Revision', such as 1.0.0.60325.

Main Package URL

Basic MSI

Specify the Uri to the app package location. The Uri specified for AppInstaller File URL will be considered if this option is empty. Other information of the MainPackage element, which includes name, publisher, and version can be changed using Package Identity Overrides section mentioned in this page. Information provided in Package Identity Overrides will be considered during build time for both MSIX package and App Installer file as all these information must match with the information included in the manifest of the MSIX application package.

Update Settings

Basic MSI

Use the Update Settings category to configure the auto update capabilities of MSIX package using App Installer file.

Update Settings on App Launch

Basic MSI

Specify whether you want to configure update settings for this package during app launch. This behavior during OnLaunch shows the UI and is further configurable with the support of HoursBetweenUpdateChecks, ShowPrompt, and UpdateBlocksActivation child attributes as explained below.

Hours Between Update Checks

Basic MSI

The HoursBetweenUpdateChecks option specifies the frequency with which the deployment service will check for an update to the App Installer file.

When HoursBetweenUpdateChecks is set to 0, the deployment service will check for updates every time the application is launched. For other values, the deployment service will check for updates when the application is launched only if it hasn't previously checked within the last number of hours specified by HoursBetweenUpdateChecks.

For example, if HoursBetweenUpdateChecks is set to 10, the deployments service will check for updates when the application is launched only if it hasn't already checked for updates in the previous 10 hours. The Windows deployment service will automatically download it If there is a new update available and install the update once the application is closed.

Show Prompt

Basic MSI

Specify whether deployment will show a prompt or not, informing the user about the update. Available in Windows 10, version 1903 and later.

For latest updates, refer to Microsoft documentation.

Update Blocks Activation

Basic MSI

Choosing Yes will stop the user from launching the application until the update has been applied. This option allows the user to only take the update or close the app. Should only be used if ShowPrompt option is chosen as it needs the UI to show the options. This option will help to deliver critical updates where app must be launched with some important fixes.

Automatic Background Task

Basic MSI

Specify whether or not to check for updates in the background regardless the app is lunched or not. A check is made every 8 hours independently of whether the user launched the app. This type of update cannot show UI. Choose 'Update Settings on App Launch' for displaying the interactive UI before update process gets triggered. Available in Windows 10, version 1803 and later.

Force Update From Any Version

Basic MSI

Specify whether the app's version to be incremented or decremented based on the requirement. Without this element, the app can only be updated to a higher version and Windows deployment service will not allow downgrade to older version. This option is useful to perform rollbacks to older app package versions. Available starting in Windows 10, version 1809 and later.

Package Identity Overrides Settings

Use the Package Identity Overrides area on the Appx/MSIX tab to uniquely identify a package to Windows. These fields are typically not shown to an end user. Also, because the settings are overridden, the fields are not expanded by default.

Note:Architecture is also part of a Windows App package’s identity. Use the Template Summary setting in the Product Configuration, or in General Information, to specify the architecture of your Windows App package.

Package Identity Overrides Settings on the Appx/MSIX Tab

Setting

Project Type

Description

Name

Basic MSI

Specify a unique alphanumeric string that identifies your Windows App package to Windows. If this is left blank, InstallShield generates a name based on the Product Name setting in the Product Configuration or General Information.

Publisher

Basic MSI

To override the actual value of the certificate if one is specified on the Signing tab, specify the Subject name (name of the owner) of the certificate that will be used to sign the package. For example:

CN=Revenera, O=Revenera, L=Itasca, S=Illinois, C=US

If a package will be distributed through the Windows Store, it doesn't need to be signed before it's uploaded to Microsoft, in which case a signing certificate may be skipped. If a package will be sideloaded, it may or may not need to be signed, depending on how your customers expect to handle the package:

If the customer prefers to sign the package themselves, they may need a specific publisher defined in the Publisher override setting that matches their certificate.
If the customer merely wants to deploy the package, they may expect it to be signed with a trusted Authenticode Certificate. The requirements on this are equivalent to those for a trusted UAC prompt.
Sideloading requires that the Sideloading setting in Windows is enabled. Sideloading is enabled by default in the Windows 10 Anniversary Update.

Tip:The following settings on the Signing tab of the Releases view also influence the built package by controlling whether and how the Windows App package is signed: Digital Certificate Information, Certificate Password, and Sign Output Files.

Version

Basic MSI

Enter a version number for the Windows App package to which the certificate conforms. If nothing is specified, the version number is copied from the Product Version setting in General Information or Product Configuration.

The version must contain only numbers and requires four parts using the following format (with values in each part ranging from 0 to 65535): majorversion.minorversion.buildnumber.revisionnumber, such as:

1.0.0.60325

Use as few characters as possible. For example, do not use unnecessary leading zeros; instead of entering 14.00.25.1, enter the following:

14.0.25.1

Display Properties

Use the four fields in the Display Properties area on the Appx/MSIX tab to identify a package to an end user..

Display Properties Settings on the Appx/MSIX Tab

Setting

Project Type

Description

Display Name

Basic MSI

Specify the string that users will recognize as the name of the package. This is typically the name of the application. If nothing is specified, the Display Name is copied from the Product Name setting in General Information or Product Configuration.

When you type a value for this setting, you are creating a string entry and setting its initial value for all of the languages that are currently in the project. As an alternative to typing a new value, you can click the ellipsis button (...) in this setting to select an existing string. For more information, see Using String Entries in InstallShield.

Note:Localization of Windows App packages requires the Windows 10 SDK be installed on the same machine as InstallShield. If it is not present, InstallShield will build a Windows App package containing only the default language.

Publisher Display Name

Basic MSI

Specify the string that users will recognize as the publisher's name. For example:

Revenera

If nothing is specified, the Display Name is copied from the Publisher setting in General Information or Product Configuration.

When you type a value for this setting, you are creating a string entry and setting its initial value for all of the languages that are currently in the project. As an alternative to typing a new value, you can click the ellipsis button (...) in this setting to select an existing string. For more information, see Using String Entries in InstallShield.

Note:Localization of Windows App packages requires the Windows 10 SDK be installed on the same machine as InstallShield. If it is not present, InstallShield will build a Windows App package containing only the default language.

Description

Basic MSI

Optionally, specify a description to help distinguish the package to an end user.

When you type a value for this setting, you are creating a string entry and setting its initial value for all of the languages that are currently in the project. As an alternative to typing a new value, you can click the ellipsis button (...) in this setting to select an existing string. For more information, see Using String Entries in InstallShield.

Note:Localization of Windows App packages requires the Windows 10 SDK be installed on the same machine as InstallShield. If it is not present, InstallShield will build a Windows App package containing only the default language.

Logo

Basic MSI

Specify the image used to represent the package. This is typically a 50x50 logo. If no logo is specified, it is created from the Display Icon setting in General Information.