Appx/MSIX Tab for a Release

InstallShield 2018 » 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 
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

 

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 native 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 native 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.

Minimum Version

(under Include Server Extensions)

Basic MSI

Optionally, specify the version number of the app's minimum supported Windows Server operating system. If you leave this blank, the minimum version of Windows Server 2016 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 Server Extensions)

Basic MSI

Optionally, specify the version number of the app's maximum supported tested Windows server operating system. If you leave this blank, this setting defaults to match the Minimum Version setting (or the minimum version of Windows Server 2016 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

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.

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 overrides, 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=Flexera, O=Flexera, 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:

Flexera

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.