1.2 Schema Proposal for Portable and Zip InstallerTypes #1989

ryfu-msft · 2022-03-01T18:12:28Z

Related to:

This PR adds the necessary schema changes to support installing portable apps and zip files.

Changes:

Settings schema:

Addition of ~~WinGetInstallerUserRoot~~ "PortablePackageUserRoot" to allow the user to specify the default root directory where portable apps should be installed to under User scope.
Addition of ~~WinGetInstallerMachineRoot~~ "PortablePackageMachineRoot" to allow the user to specify the default root directory where portable apps should be installed to under Machine scope.

InstallerManifest schema:

Changes to 'Installer' object:

Addition of ~~NestedInstallers~~ "ArchiveInstallers" which is an object array of ~~NestedInstaller~~ "ArchiveInstaller"
Addition of "AppendPathToProcess" which is utilized during the installation of portable apps. We will be registering the app using the App Paths registry subkey. This value would be used to determine whether we should create a ‘Path’ string value in the registry to indicate whether to pre-pend the ‘Path’ value to the PATH environment variable on a per-application, per-process basis

Addition of ~~NestedInstaller~~ "ArchiveInstaller" object:

Similar to the existing 'Installer' object but more refined to fit the zip scenario.
Addition of "RelativeFilePath" to declare the relative file path to the installer/portable exe that will be installed.

Microsoft Reviewers: Open in CodeFlow

JohnMcPMS · 2022-03-01T18:38:29Z

schemas/JSON/manifests/v1.2.0/manifest.installer.1.2.0.json

@@ -462,6 +476,17 @@
        "InstallerType": {
          "$ref": "#/definitions/InstallerType"
        },
+        "NestedInstallers": {
+          "type": "array",


I don't see how we need more than one installer; what is the scenario?

I can only think of one, and it doesn't need complicated nested installer data. Multiple portables inside an archive, and we want to register app paths for all of them.

I could see where someone may put an exe and an MSI into a zip file. If the user has a preference for their installer type, having an array here could be useful. It's a rare edge case, but could be used.

Or where some publishers publish multiple locales in a single zip file, then being able to select the correct locale would be important

We can do all of the multi-installer scenarios by having multiple installers defined at the top level and having all of them reference the same archive, but different files within.

We can do all of the multi-installer scenarios by having multiple installers defined at the top level and having all of them reference the same archive, but different files within.

We can, yes, but then there is a lot of duplication of data. The Installer URL and Sha256 at minimum would be repeated for however many installer nodes there are, which could be many when considering the multiplicative effect of locale and architecture.

In my mind it would make updating manifests more difficult and would complicate the flow of wingetcreate and YamlCreate even further. Whereas, having the multi-installer scenarios handled by an array here would likely result in a cleaner user experience

JohnMcPMS · 2022-03-01T18:39:06Z

schemas/JSON/manifests/v1.2.0/manifest.installer.1.2.0.json

+    "NestedInstaller": {
+      "type": "object",
+      "properties": {
+        "InstallerLocale": {


If there is only one nested installer per outer installer, then the outer properties are already appropriate. The only data needed for the nested installer would be type and relative path.

There could be an x86 binary, an x64 binary, and an arm64 binary all inside a single archive as nested installers. In this case, using the neutral architecture and allowing the nested installers to have the data would make sense.

schemas/JSON/settings/settings.schema.0.2.json

JohnMcPMS · 2022-03-01T19:05:33Z

schemas/JSON/manifests/v1.2.0/manifest.installer.1.2.0.json

+            "nullsoft",
+            "wix",
+            "burn",
+            "portable"


This isn't actually the correct PR for it, but since I'm thinking of it in the context of archives anyway...

I think we need to consider a portableWithInit type (or some other way of achieving it) where the package installer files are intended to stay on the device like portable, but there is also some initialization step to run. Example: I wrote a very simple .pfx viewer that invoked the existing UI on them, but it needed to be run once in order to add the shell verb to the registry. This would be a portable installer as the exe was needed after install, but it was more cumbersome if you would have to run it once by hand since afterward you never needed to use the exe directly again.

It might also require adding uninstall switches that are only applicable to this new type.

Trenly · 2022-03-01T20:09:13Z

schemas/JSON/manifests/v1.2.0/manifest.installer.1.2.0.json

@@ -462,6 +476,17 @@
        "InstallerType": {
          "$ref": "#/definitions/InstallerType"
        },
+        "NestedInstallers": {
+          "type": "array",


I could see where someone may put an exe and an MSI into a zip file. If the user has a preference for their installer type, having an array here could be useful. It's a rare edge case, but could be used.

Or where some publishers publish multiple locales in a single zip file, then being able to select the correct locale would be important

Trenly · 2022-03-01T20:14:14Z

schemas/JSON/manifests/v1.2.0/manifest.installer.1.2.0.json

+    "NestedInstaller": {
+      "type": "object",
+      "properties": {
+        "InstallerLocale": {


There could be an x86 binary, an x64 binary, and an arm64 binary all inside a single archive as nested installers. In this case, using the neutral architecture and allowing the nested installers to have the data would make sense.

schemas/JSON/manifests/v1.2.0/manifest.installer.1.2.0.json

schemas/JSON/settings/settings.schema.0.2.json

schemas/JSON/manifests/v1.2.0/manifest.installer.1.2.0.json

yao-msft · 2022-03-02T17:47:52Z

schemas/JSON/manifests/v1.2.0/manifest.installer.1.2.0.json

        },
        "InstallerType": {
          "$ref": "#/definitions/InstallerType"
        },
+        "ArchiveInstallers": {


Since we do decide to use multiple ArchiveInstallers, do we have decision on the installer selection behaviors? (i.e. same app with different installers vs different apps)

For example, for some apps, we may have below and we want to install both of them
app1.exe
app2.exe

For some apps, we may have below and we want to only pick 1 to install
app1_x86.exe
app1_x64.exe

I think we can only support 1 of the scenarios above without further manifest entries and making the logic more complex.

After discussing this further, we're leaning towards supporting the following scenarios for zip:

~~1. Single or multiple portable exes contained inside a zip, which will all be installed.~~

Single or multiple portable exes contained inside a zip, but we will only install one portable.

Single Installer inside a zip.

Multiple installers inside a zip, but only installing one from the selection of installers. This would ensure that we support examples such as zips having multiple architecture installers or multiple locale installers residing in the same zip. If a specific architecture or locale is not specified, winget will choose the best option to install for you.

Regarding the edge case of a zip file containing multiple installerTypes (such as msi and exe), we would need to add support for enabling a user to select which installerType they would prefer to install.

I do not support this:

multiple portable exes contained inside a zip, which will all be installed.

That will just complicate things unnecessarily (although given how messy things are even when we try not to be, it might actually help us to need to handle it head on). But generally, dependencies are a better solution than having a bunch of stuff in a single archive and installing it all. Even if all of those things are in a single archive.

Option 3 is just like our current manifest, but directly supporting the installer set expansion from a single archive rather than requiring repetition of the archive as a top level installer.

Updated the comment above. We decided that we will only install a single portable inside a zip even if the zip archive contains multiple portables. This is to ensure that we limit the complexity that comes with installing multiple packages at the same time. It is better to have that be driven through dependencies when that feature is ready.

why not just select the main portable exe, chuck a shortcut to the desktop and the folder to program files?

solomoncyj · 2022-03-04T14:09:44Z

quick q does the pr cover zips with installers + install data and zips with the application ready to extracted to install location?

ryfu-msft · 2022-03-04T18:38:44Z

quick q does the pr cover zips with installers + install data and zips with the application ready to extracted to install location?

Yes, this PR just covers manifest changes related to zips with installers and zips with portables (where we would extract and copy to a specified install location)

solomoncyj · 2022-03-07T11:25:03Z

can the portable zip use a .bat or .ps1 instead on .exe for main executable?

Trenly · 2022-03-07T12:17:04Z

can the portable zip use a .bat or .ps1 instead on .exe for main executable?

As far as I know, no. Those are a separate installer type for their own feature

denelon · 2022-03-07T15:39:08Z

@solomoncyj,

No, we don't support scripts as installers.

denelon · 2022-03-09T19:32:54Z

schemas/JSON/settings/settings.schema.0.2.json

+    "PortableAppMachineRoot": {
+      "description": "The default root directory where packages are installed to under Machine scope. Applies to the portable installer type.",
+      "type": "string",
+      "default":  "%LOCALAPPDATA%/WPM_Packages/Machine"


Suggested change

"default": "%LOCALAPPDATA%/WPM_Packages/Machine"

"default": "%LOCALAPPDATA%/WinGet_Packages/Machine"

superusercode · 2022-04-02T23:38:17Z

Does this current schema cover portable apps within zips that include the runtimes and file structures necessary to run them? i.e. multimc:

denelon · 2022-04-04T15:19:14Z

Does this current schema cover portable apps within zips that include the runtimes and file structures necessary to run them? i.e. multimc:

I believe this case would be supported as there is only one "portable" application.

gerardog · 2022-04-07T02:22:18Z

For zip files containing a group of files belonging to a portable app, and assuming that to add the app to the PATH it must either be shimmed or sym-linked (whatever one the team chooses).

Does the schema supports to specify which files need to be added to the path? (yes, more than one)
Does it support to symlink/shim a bash script (file with no extension), or .ps1 file? (which are part of the application, not installers).
A possible conflict would be if two portable apps may try to create the same shim/symlink. And in that case what happens? first/last one wins?, installation error?

Examples:

gsudo ships with a gsudo file (no extension) which is a bash wrapper of gsudo.exe, intended to be called when the app is invoked from WSL (required for improved functionality). In a similar fashion, a PowerShell wrapper also exists. Both wrappers need to be in the Path.
Edge case: gsudo generates an alias: sudo => gsudo by creating a sudo.exe symlink to gsudo.exe.

denelon · 2022-04-08T15:17:00Z

Initially, we're looking at a single portable app inside a .zip file, or a single installer inside a .zip file. The cartesian of other possibilities is a bit much to tackle with the initial implementation. We will continue to iterate to capture more of the other scenarios in future releases.

solomoncyj · 2022-04-12T23:58:03Z

For portable apps uninstallation, can winget.just delete install path and component registration?

ryfu-msft · 2022-06-22T18:40:32Z

Closing this as Portable has been implemented and ZIP schema changes will be addressed and proposed in a separate PR

ryfu-msft and others added 3 commits February 28, 2022 16:21

Add proposed schema changes for review

c3efafe

fix changes

bc4706b

add msix support

68e2522

JohnMcPMS requested changes Mar 1, 2022

View reviewed changes

ghost added the Needs-Author-Feedback Issue needs attention from issue or PR author label Mar 1, 2022

Trenly reviewed Mar 1, 2022

View reviewed changes

yao-msft reviewed Mar 1, 2022

View reviewed changes

schemas/JSON/manifests/v1.2.0/manifest.installer.1.2.0.json Outdated Show resolved Hide resolved

yao-msft reviewed Mar 1, 2022

View reviewed changes

schemas/JSON/manifests/v1.2.0/manifest.installer.1.2.0.json Outdated Show resolved Hide resolved

address initial feedback

08bec80

ghost removed the Needs-Author-Feedback Issue needs attention from issue or PR author label Mar 1, 2022

yao-msft reviewed Mar 2, 2022

View reviewed changes

denelon reviewed Mar 9, 2022

View reviewed changes

ryfu-msft closed this Jun 22, 2022

ryfu-msft deleted the schemaProposal branch July 29, 2022 20:08

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

1.2 Schema Proposal for Portable and Zip InstallerTypes #1989

1.2 Schema Proposal for Portable and Zip InstallerTypes #1989

ryfu-msft commented Mar 1, 2022 •

edited

Loading

JohnMcPMS Mar 1, 2022

Trenly Mar 1, 2022

JohnMcPMS Mar 1, 2022

Trenly Mar 1, 2022

JohnMcPMS Mar 1, 2022

Trenly Mar 1, 2022

JohnMcPMS Mar 1, 2022 •

edited

Loading

JohnMcPMS Mar 1, 2022

Trenly Mar 1, 2022

Trenly Mar 1, 2022

yao-msft Mar 2, 2022

ryfu-msft Mar 3, 2022 •

edited

Loading

JohnMcPMS Mar 3, 2022

ryfu-msft Mar 4, 2022

solomoncyj Mar 15, 2022

solomoncyj commented Mar 4, 2022

ryfu-msft commented Mar 4, 2022

solomoncyj commented Mar 7, 2022

Trenly commented Mar 7, 2022

denelon commented Mar 7, 2022

denelon Mar 9, 2022

superusercode commented Apr 2, 2022 •

edited

Loading

denelon commented Apr 4, 2022

gerardog commented Apr 7, 2022

denelon commented Apr 8, 2022

solomoncyj commented Apr 12, 2022

ryfu-msft commented Jun 22, 2022

	"default": "%LOCALAPPDATA%/WPM_Packages/Machine"
	"default": "%LOCALAPPDATA%/WinGet_Packages/Machine"

1.2 Schema Proposal for Portable and Zip InstallerTypes #1989

1.2 Schema Proposal for Portable and Zip InstallerTypes #1989

Conversation

ryfu-msft commented Mar 1, 2022 • edited Loading

Microsoft Reviewers: Open in CodeFlow

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JohnMcPMS Mar 1, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryfu-msft Mar 3, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

solomoncyj commented Mar 4, 2022

ryfu-msft commented Mar 4, 2022

solomoncyj commented Mar 7, 2022

Trenly commented Mar 7, 2022

denelon commented Mar 7, 2022

Choose a reason for hiding this comment

superusercode commented Apr 2, 2022 • edited Loading

denelon commented Apr 4, 2022

gerardog commented Apr 7, 2022

denelon commented Apr 8, 2022

solomoncyj commented Apr 12, 2022

ryfu-msft commented Jun 22, 2022

ryfu-msft commented Mar 1, 2022 •

edited

Loading

JohnMcPMS Mar 1, 2022 •

edited

Loading

ryfu-msft Mar 3, 2022 •

edited

Loading

superusercode commented Apr 2, 2022 •

edited

Loading