Draft of Store Support

[KevinLaMS]

Per issue 117, we need to add store support. This is a draft of the requirements to help drive the dev spec.

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

Missing issue id

[yao-msft]

Let me try the "free for download" apps and see how the API handles the case when user does not own the app yet

[yao-msft]

Paid apps?

[yao-msft]

I think we need more explanation on TransactionType and related fields.
Also the styling around this block does not align well in rich view

[yao-msft]

so is this -prerelease a cli switch dedicated to Store app? We might consider leveraging the Channel concept we already have?

[riverar]

Nits: Remove "in order", "flighting" is spelled incorrectly.

[KevinLaMS]

Agree this needs to be the same as the model we settle on for all packages.

[yao-msft]

Nit: BigID should be StoreId to be consistent :)

[yao-msft]

Somehow the image does not resolve in rich view

[yao-msft]

we should try to eliminate the duplicate entries by default
Seems like we need to prioritize the support for multiple installer in one manifest. And enforce it in manual review/ reject the manifest in index creation?

[yao-msft]

Suggested change

	When the user specifies install by default the client will choose to install the version of the app that is flagged as default in the manifest. If no default is specified, then the app will default to the store as the default app.
	When the user specifies install by default the client will choose to install the InstallerType of the app that is flagged as default in the manifest. If no default is specified, then the app will default to the store as the default app.

[denelon]

I think you can use a "DRAFT" PR rather than committing a document with draft in the title. If you merge this, you will have to come back and change it to remove this line.

[denelon]

I think we need to explain about the Microsoft catalog ID

[denelon]

I think we should retain the URL field and have it point to the store application https:// address

[KevinLaMS]

Are you suggesting it would be required? I think the URL you are suggesting would typically be the HomePage.

[denelon]

How is this different from a EULA? I'd like to try and get as much value in the manifest for each attribute. I'd also like to make sure optional attributes or those that only apply in certain situations to be located in a meaningful place.

[riverar]

A EULA requires acceptance, a privacy policy does not. You cannot combine the two.

[denelon]

Git keeps a history of all revisions to a document, this probably isn't necessary

[zachcarp]

flighing -> flighting

[zachcarp]

bigid casing is inconsistent throughout the document.

[JohnMcPMS]

The issue for installing things comes in two parts:

1. Processing a set of metadata (aka manifest) to result in an installed application
2. Discovery of said metadata

This spec seems to cover installation, but mostly glosses over discovery with the assumption that it would be the same as non-Store (aka through winget-pkgs). I think that we do need an installation spec much like this one that covers the manifest side of things. But I believe that discovery should be handled as a separate source, which will allow for the entire catalog to be available (at least, to the limits that we impose).

[riverar]

Great start.

Would like to see coverage/consideration of:

• Applications with durables and/or optional packages
• Applications with flight audience groups (can be handled via channel? what about auth?)
• Applications that are labeled as having IAP but don't really (Store bug with durables/optional packages)
• Dependencies (e.g. framework packages)
• Discovery, especially around localized product display
• Windows SKUs without Store support
  • Can we have two variants (but same version) of our app in winget to alleviate issues that arise due to SKU limitations?

[zooba]

then the app will default to the store as the default app.

Good. This is the best way to handle concerns about flaky remote servers causing download failures.

[lordcheeto]

The issue for installing things comes in two parts:

1. Processing a set of metadata (aka manifest) to result in an installed application
2. Discovery of said metadata

This spec seems to cover installation, but mostly glosses over discovery with the assumption that it would be the same as non-Store (aka through winget-pkgs). I think that we do need an installation spec much like this one that covers the manifest side of things. But I believe that discovery should be handled as a separate source, which will allow for the entire catalog to be available (at least, to the limits that we impose).

That would result in more collisions when searching for a program that has been distributed through both a standalone installer and the store. I don't think the behavior for multiple sources has been defined, so I'm not sure what that would look like.

They wouldn't have the benefit of being linked by their shared presence in a single versioned manifest, and it would be impossible to determine with confidence that two hits are for the same bits, so any collision would have to prompt the user to make a decision. You can't rely on the Publisher.Name.Version fully qualified name to resolve collisions, because those fields in the store are not necessarily consistent with the manifests as defined in winget-pkgs. For example, Windows Terminal has the Publisher field set to Microsoft in winget-pkgs, but is Microsoft Corporation in the Windows Store.

Because we have manifests that are based on publisher and appname, there should not be a case where we have multiple manifests with different installers. If we do, there is something wrong with the metadata.

With a curated central repository, that's manageable.

---

General question: is support for the Microsoft Store for Business and Education
on the radar, and would this spec be compatible without breaking changes later on down the line?

[JohnMcPMS]

That would result in more collisions when searching for a program that has been distributed through both a standalone installer and the store. I don't think the behavior for multiple sources has been defined, so I'm not sure what that would look like.

They wouldn't have the benefit of being linked by their shared presence in a single versioned manifest, and it would be impossible to determine with confidence that two hits are for the same bits, so any collision would have to prompt the user to make a decision. You can't rely on the Publisher.Name.Version fully qualified name to resolve collisions, because those fields in the store are not necessarily consistent with the manifests as defined in winget-pkgs. For example, Windows Terminal has the Publisher field set to Microsoft in winget-pkgs, but is Microsoft Corporation in the Windows Store.

Because we have manifests that are based on publisher and appname, there should not be a case where we have multiple manifests with different installers. If we do, there is something wrong with the metadata.

With a curated central repository, that's manageable.

General question: is support for the Microsoft Store for Business and Education on the radar, and would this spec be compatible without breaking changes later on down the line?

Indeed, we have already received feedback that we should value the curation over the full list of Store offerings. This would also enable direct linkage between things offered in multiple ways, as you state. I just want to ensure the user choice of Store vs external. It may end up being a setting to prefer one or the other.

As to Store for Business, that will require more investigation. I don't think that the design will preclude it, but I don't know if additional namespacing information will be required or not. This could either be rolled into the existing value, or added as a new field. In either case, I expect that to come much later with enterprise support features, as nothing in winget-pkgs will be in SfB.

[lordcheeto]

Indeed, we have already received feedback that we should value the curation over the full list of Store offerings. This would also enable direct linkage between things offered in multiple ways, as you state. I just want to ensure the user choice of Store vs external. It may end up being a setting to prefer one or the other.

Agreed. Having it as a separate source, if linked in some way, would allow users to just remove the source. Robust InstallerType filtering (configurable with flags or user configurable settings) would allow for that, as well as filtering of other installer fields like language or scope.

[riverar]

In addition to earlier comments, would like to also throw out there that downloading from the Store should not require initial configuration of credentials or require any authentication. I typically click through quite a few dialogs in the Store client to get our supported download-without-login experience. I'd expect winget to just work.

[Karl-WE]

Consideration of Store background updating behaviour

Microsoft Store often enough does not fetch apps updates, unless the user starts the Microsoft Store app, clicks on the pending downloads icon, click get updates. Store would the actively search for new GA or flighting updated also install all previous queued ones.

I've reported this several times for months now to the store team and insider team but no one feels responsible. Affected 18xx or later builds.

The problem is that the store will still update apps but based on a non transparent schedule which misses for following scenarios :

• users assigned guest role cannot use (store) apps at all, all builds
• users with users role assigned likely get no apps updates
• users with local admin roles assigned (default) will receive updates but only when the computer is on and online for an undocumented time, eventually depending on idle status like search.

[Karl-WE]

Considerations for Business Store / Intune / Autopilot

The draft imho does consider Microsoft Store, yet I am missing a major usecase for business users

• Microsoft Store for Business
• in junction with app deployment via Intune over Store for Business and Autopilot

Limitations of Store support for Winget

• the team / author @KevinLaMS might want add conceptual remarks on the limitations with LTSC Client and and Servers and Server SAC which have no Store support.

In these cases users have to fall back to native winget features. Referencing planned backport of winget to LTSC versions, likely including SAC versions of Windows Server, for consistency.

[ghost]

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

[Karl-WE]

@KevinLaMS is this still a thing being worked on?

[ghost]

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

[riverar]

Uh guys. @KevinLaMS @JohnMcPMS @denelon

[denelon]

Sorry all. We've had quite a bit of internal discussion going on about store support. The latest release has some code behind a feature toggle with a POC that we've been working on. Unfortunately, we haven't gotten as far along as we had hoped.

There is other activity going on right now to look at how we can build a set of manifests for some store apps that are free, and rated e for everyone. We're thinking about building the manifests for those and putting them into a different source for the package manager.

The challenges associated with commerce and other requirements we have with store Apps have been a bit more involved than originally anticipated. We may have to split #117 into smaller pieces in order to get functionality out, and to make the right subset of store apps available as we can.

[Karl-WE]

Good news @denelon my previous mentioned general issues that store app might not update automatically seemed to be fixed in Insider Dev but also outside. Needs more careful observation if is entirely fixed.

[ghost]

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.