Install Microsoft Store Apps about winget-cli HOT 50 CLOSED

Current state is, due to lack of complete Store api and other legal concerns, an experimental store feature is released with support of a list of curated "free" and "rated e" apps. The feature is disabled by default but it can be turned on through 'winget settings'.

We are continuing to work with Store team towards the full Store integration for winget.

from winget-cli.

@maxkatz6 I don't think it's an issue since Microsoft can make exceptions for it's own software, for example if you try to get Microsoft Office through the store it will redirect you to download the installer from the Microsoft website.

I hate when that happens (if I used the store I expect the store download the app and updates it when necessary)

from winget-cli.

This is life changer! I've just reinstalled Windows 10 yesterday and installing all apps I need from the MS Store was such a pain, the possibility to create a script to install my (already purchased) apps from the store using winget would be awesome.

Please allow all apps in the Store to be installed with winget, at least those which are already purchased by the logged user

from winget-cli.

Same. I hope we can install ANY app in the store with WinGet. At present manual search-and-install of a list of apps is such a pain.

from winget-cli.

One of the greatest complaints for Windows Store is that it cannot be easily managed by domain owners, and it could be solved by proceeding this issue. By the way I believe Window Store is the "ultimate solution" where every programs/apps should be, and winget only needs to be a command line version of it - like the Ubuntu Snap Store.

Really disagree with the second half of this. Every attempt Microsoft has made with Windows to limit software installations to just the Microsoft Store has been negatively received. Windows is simply not a walled garden ecosystem. I think the Store is a cool idea, but it's clear that many developers have no intention of moving their apps in there.

That being said, I think it's important that winget can mange Store applications so that it can be a one stop shop (or as close to that as possible) for managing software. That also helps with the domain owners management issue, as you could potentially just disable the Store all together in the Group Policy and run everything through winget.

from winget-cli.

There are also paid applications in the Microsoft Store.
Can I purchase a paid application through the winget cli?
(Maybe this shouldn't be possible. I think, I should only be able to install the apps I've purchased).

This is an interesting challenge. One approach (at least at first) would be to require users to make the purchase through the Microsoft Store, then sign in to winget to be able to download the app. I do really hope MS doesn't require sign in to use winget for free stuff on the web, but I'd understand the need to do so for paid Store apps.

from winget-cli.

@denelon Demitrius Nelon FTE thanks for that update. Quick question: Nightingale has IAPs. Will this winget installation process break a customer's ability to access/purchase those IAPs?

@dpaulino winget search nightingale will display the Microsoft Store version of Nightingale (if you have the experimental feature enabled).

winget install "Nightingale REST Client" will install it by name
winget install 43891JeniusApps.NightingaleRESTAPIClient will install it by ID

from winget-cli.

#908

from winget-cli.

@davidanthoff we've experimented with a few different scenarios, and the results were inconclusive. We ended up returning to the state where two or more identical "PackageIdentifiers" across sources requires the user to disambiguate with -s <source>. We will likely add settings so users can have a preference for the default source in these cases. At one point we defaulted to the "first" source added, but we quickly realized changing the order of the sources was a bit heavy-handed. especially if you wanted to control the behavior.

from winget-cli.

This feature was released in https://github.com/microsoft/winget-cli/releases/tag/v1.1.12653

from winget-cli.

From MVP Summit feedback:

Will there be a way to automate installation of Store apps? I have a script I run to install my programs after Windows reinstall with Chocolatey, but I have to install Microsoft Store apps manually afterwards, which is a bit annoying.

And how do you handle some apps installing for the current user only and other apps installing for all users. At the moment, this is a total mess on Windows. Application installation is inconsistent and there seems to be this misguided assumption that a host machine only has one account. In this scenario, then signing in with Microsoft account and install from the store seems ok. But when you have multiple accounts on the same system, which all need access to the same apps, this model simply does not work.

from winget-cli.

The source is explicitly defined in the export file. The real challenge is dealing with packages that are in multiple sources when the export is generated. There will be an option to specify a source for export. In that event if a package is in multiple sources, it's likely you would see it in the export for each source if you performed them individually. The tie breaker logic will likely follow the first source added and then down the line.

from winget-cli.

Full support of Windows Store including integration with Windows Store Service (or custom implementation) to support licensing and verification of paid apps as an OPTIONAL supported feature should be on future roadmap, really.

from winget-cli.

Is there some documentation somewhere that explains how this works in the build you just linked to? Also, fantastic news :)

from winget-cli.

How should it work with MS Store Policies?

10.1.5
Your app may promote or distribute software only through the Microsoft Store.

https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies#101-distinct-function--value-accurate-representation

By the way, I would love to see store apps in winget too.

I think you're misunderstanding what it means. It means that lets say a DLC for a game which is promoted within the game would be purchasable/downloadable through Windows store instead of leading you to third party service.

from winget-cli.

@maxkatz6 I don't think it's an issue since Microsoft can make exceptions for it's own software, for example if you try to get Microsoft Office through the store it will redirect you to download the installer from the Microsoft website.

from winget-cli.

I feel like it should have already been an option to install an app from microsoft store via cli. Since that would be just sending install arguments to the executable.
But im guessing there isn't and that's why we now have winget.
Cant seem to get anything out of WinStore.App.exe executable either (missing dll errors).

from winget-cli.

I seem to remember that the Microsoft Store does have a way to install apps through a cli, it just isn't available for use outside of Microsoft.

from winget-cli.

One of the greatest complaints for Windows Store is that it cannot be easily managed by domain owners, and it could be solved by proceeding this issue. By the way I believe Window Store is the "ultimate solution" where every programs/apps should be, and winget only needs to be a command line version of it - like the Ubuntu Snap Store.

from winget-cli.

I read this whole thing and i still have ZERO clue as to what is the state of the issue and where it is all heading. Like, can I install something like this:

https://www.microsoft.com/en-us/p/ori-and-the-will-of-the-wisps/9n8cd0xzklp4

If not - why? And are there any plans? Will it be ever possible?

from winget-cli.

To install apps from the Microsoft Store, I need to sign in to the store with my Microsoft account.
All the applications I have installed are recorded in my Microsoft account.
If winget supports installing apps from the Microsoft Store, do I need to sign in to my Microsoft account through the winget cli?

There are also paid applications in the Microsoft Store.
Can I purchase a paid application through the winget cli?
(Maybe this shouldn't be possible. I think, I should only be able to install the apps I've purchased).

You don't need to sign in with a Microsoft account to install free apps. Yes they make it seem like you have to do it but you can just click the close button on top and it does download and install just fine

from winget-cli.

@Kein we are working with the Microsoft Store team. This is one of the areas of discussion. I'd absolutely LOVE to be able to use the Windows Package Manager to install applications that I've paid for. I'll add a feature for that specific use case.

from winget-cli.

If you are asking how to enable it, enable the experimental feature with winget settings. To check what features you have enabled use winget features.

If you are asking about where it's located, it's a "private" source of ~300 curated developer related packages that are rated "E" for everyone, and are also free.

from winget-cli.

@davidanthoff we're working with the store team on a completely new source based on the REST API. I think we're close to pushing another version of the client out soon [tm]. I don't know if this is in the list yet as we're still working on the search APIs.

from winget-cli.

Note: GPO (Group Policy Objects) can specify sources in enterprise scenarios and users wouldn't be able to modify these settings. You can see if GPOs are configured via winget --info.

To get back to the "default" state with the msstore available, users can run winget source reset --force in administrator mode.

Search and install can also be restricted by adding "--source " or "-s ".

Examples:
winget search PowerToys -s winget
winget search PowerToys -s msstore

You can see the difference against winget search PowerToys

from winget-cli.

How should it work with MS Store Policies?

10.1.5
Your app may promote or distribute software only through the Microsoft Store.

https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies#101-distinct-function--value-accurate-representation

By the way, I would love to see store apps in winget too.

from winget-cli.

The Microsoft Store never really had that option. There are some ways to sideload apps from a command line. If the Store had that command line option and it embraced other application types (like command line apps and Win32 apps), we probably wouldn't have needed this project.

from winget-cli.

To install apps from the Microsoft Store, I need to sign in to the store with my Microsoft account.
All the applications I have installed are recorded in my Microsoft account.
If winget supports installing apps from the Microsoft Store, do I need to sign in to my Microsoft account through the winget cli?

There are also paid applications in the Microsoft Store.
Can I purchase a paid application through the winget cli?
(Maybe this shouldn't be possible. I think, I should only be able to install the apps I've purchased).

from winget-cli.

When i think about it, there are games in Windows Store, would it really be optimal for example to download Halo MCC via winget.

from winget-cli.

It looks like "The Nightingale REST API Client" will meet initial requirements for a store App inclusion in terms of "Free" and "Rated E for Everyone". jenius-apps/nightingale-rest-api-client#69

from winget-cli.

@denelon thanks for that update. Quick question: Nightingale has IAPs. Will this winget installation process break a customer's ability to access/purchase those IAPs?

from winget-cli.

@dpaulino I don't believe it will, but let me confirm with a test.

from winget-cli.

I feel like being able to get paid apps would be important for this implementation. There are a lot of apps on the store that are pay-gated (i.e. paint.net, krita, etc.) for the purpose of providing streamlined updates from the store. Even some windows components on the store and microsoft products (i.e. HEVC extension pack, paid microsoft-provided wallpapers, and minecraft [java version cannot be distributed via winget]) would not be installable without support.

from winget-cli.

from winget-cli.

Okay, so in theory nothing strictly "MS-bureaucratical" really limits the ability to implement something like user auth by login/pass access to owned apps, it just matter of time? It is wonderful news if this is really true, so we could have something similar as handy and useful as https://github.com/derrod/legendary but for WinStore.

from winget-cli.

What about duplicated IDs like Microsoft.WindowsTerminal? Will the IDs be changed e.g. different format for different sources, or the source will be explicitly defined?
If latter, a default source could be set and any Microsoft Store app could be virtually installed.

from winget-cli.

Current state is, due to lack of complete Store api and other legal concerns, an experimental store feature is released with support of a list of curated "free" and "rated e" apps. The feature is disabled by default but it can be turned on through 'winget settings'.

We are continuing to work with Store team towards the full Store integration for winget.

@yao-msft @denelon is there a way to script this "experimental feature" so that a powershell script that installs apps can also include apps that are free like windows terminal?

from winget-cli.

@angry-bender I'm sure it's possible, but it would likely be complex. You would need to find and modify the settings.json file to enable the experimental store feature. Then you could either call the "install" command or the "import" command.

You will likely see some additional changes in our manifest schema and REST API as we work towards a better implementation for the Windows Package Manager to be able to install more of the Apps in the store.

from winget-cli.

so where is msstore source repo?

from winget-cli.

@denelon
Is possible to let people send a "Wish List" about msstore?

from winget-cli.

If you are asking about where it's located, it's a "private" source of ~300 curated developer related packages that are rated "E" for everyone, and are also free.

What do you think about adding Finebits apps to this list?

from winget-cli.

We're working on building a more comprehensive store source. The current one is experimental so we can iterate. We're not investing in the current source so we can focus on the new one. Adding anything to the current experimental source is a manual process.

from winget-cli.

@denelon could you maybe add https://www.microsoft.com/store/apps/9NJNWW8PVKMN to the list of curated experimental store sources?

One question about that: what happens if a user then enables the experimental store feature and types winget install julia? There is also a listing for Julia at https://github.com/microsoft/winget-pkgs/tree/master/manifests/j/Julialang/Julia, and then it is not clear to me what the UE would be? I think eventually, once the store source is on by default, we would want the store source to be the only one for Julia, but until then I think it would make sense to keep the legacy installer that is configured in winget-pkgs around.

from winget-cli.

@denelon Just a quick follow up: is there a chance that you could add Julia (https://www.microsoft.com/en-us/p/julia/9njnww8pvkmn) to the (hard coded?) list of store apps that winget makes available from the store when the experimental store feature is turned on? I think the package would make a good candidate for that. Thanks :)

from winget-cli.

Sounds good! I've also thought a bit more about multiple sources for the same thing. Here is where I think things would ideally come down for something like Julia:

1. If a user is on a system with Windows Store support and types in winget install julia, we would want them to get the store version automatically, without them having to decide between different sources.
2. If a user is say on Windows Server, though, we would want winget install julia to still work, and in that case it would presumably ideally install the "old style" installer that we have currently registered in the winget registry.

If our Windows Store installer supported all Windows platforms, we'd be happy to have that the only option to show up for winget users, but given that things like Windows Server are out, we kind of need both vehicles. But we would like to have an option to mark either one as the "default" for a given platform, and then not have users confronted with a choice.

Does that make sense?

from winget-cli.

How would this work for Windows 10/11 LTSC which by default has no storefront "app" but can technically install any store apps? I think an ability to explicitly specify flag as to what you want to install of course should be present to avoid any auto-detection issues.

from winget-cli.

@davidanthoff, yes that makes perfect sense. We've been discussing deduplication across sources. Even on a system without the Microsoft Store UX, users would still be able to leverage the Microsoft Store "source" for the Windows Package Manager.

Note: it's currently an experimental feature for the Windows Package Manager. Run winget features to see if it's enabled.

One of the approaches discussed is a setting to determine which source is a preference/requirement for a package when duplicates exist. Users would still be able to override via command line winget install Julia -s <source>.

from winget-cli.

Even on a system without the Microsoft Store UX, users would still be able to leverage the Microsoft Store "source" for the Windows Package Manager.

Oh, that would be wonderful!! If it means what I think it means :) Does that mean that even on say a Windows Server 2019 system, or a managed system where an admin blocked the store UI, a user would be able to write winget install julia and just get the MSIX we have published in the store? That would be fantastic!

The MSIX we have for Julia has the unvirtualizedResources capability. We got permission to use that for the Windows Store, but we are now in a situation where our MSIX only works when installed from the Windows Store, because neither app installer nor just double clicking on an MSIX works if that capability is used. So if winget would be a way to use our existing MSIX, with the unvirtualizedResources capability on Windows Server 2019 and other currently non-supported platform, it would mean that we could actually just have one installer solution (the MSIX via the store), which would be great. At the moment we were planning to have two completely separate setup solutions, one for Windows platforms where the Windows Store works, and another one for other platforms. That would obviously be very far from ideal...

Would store sourced MSIX setups auto-update, even if the Store UX is not available?

from winget-cli.

We have some notes on Microsoft Docs. I'm drafting a blog that should go out in the next day or two as well.

from winget-cli.

If anyone else is looking for it: Store support can be disabled as admin using
winget source remove msstore

This reduces ambiquity for apps/search patterns that are available via msstore and winget.

It is great that sources can be managed as simple as that.

from winget-cli.