You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
Max Katz (@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.
Max Katz (@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)
Reacted by Poopooracoocoo, Nathan Crum, Tormod Fjeldskår, NilFusion, Nino Padrutt, Carlo Mendoza, Kelps Leite de Sousa, someniatko, Talia Flôr and Mr Beedell, Roke Julian Lockhart
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).
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.
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).
Demitrius Nelon (@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 :)
David Anthoff (@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.
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:
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.
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.
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.
David Anthoff (@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>.
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?
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 ".
Activity
maxkatz6 commentedon May 25, 2020
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.
Jasius commentedon May 25, 2020
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.
yair100 commentedon May 25, 2020
Max Katz (@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.
blogcraft commentedon May 26, 2020
I hate when that happens (if I used the store I expect the store download the app and updates it when necessary)
ThomasAunvik commentedon May 26, 2020
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.exeexecutable either (missing dll errors).RobCannon commentedon May 26, 2020
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.
yair100 commentedon May 26, 2020
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.
aetos382 commentedon May 26, 2020
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).
38 remaining items
davidanthoff commentedon Aug 13, 2021
Demitrius Nelon (@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 :)
denelon commentedon Aug 18, 2021
David Anthoff (@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.
davidanthoff commentedon Aug 18, 2021
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:
winget install julia, we would want them to get the store version automatically, without them having to decide between different sources.winget install juliato 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
wingetusers, 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?
Kein commentedon Aug 18, 2021
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.
denelon commentedon Aug 18, 2021
David Anthoff (@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.
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>.davidanthoff commentedon Aug 18, 2021
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 juliaand just get the MSIX we have published in the store? That would be fantastic!The MSIX we have for Julia has the
unvirtualizedResourcescapability. 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 ifwingetwould be a way to use our existing MSIX, with theunvirtualizedResourcescapability 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?
denelon commentedon Oct 4, 2021
This feature was released in https://github.com/microsoft/winget-cli/releases/tag/v1.1.12653
davidanthoff commentedon Oct 4, 2021
Is there some documentation somewhere that explains how this works in the build you just linked to? Also, fantastic news :)
denelon commentedon Oct 4, 2021
We have some notes on Microsoft Docs. I'm drafting a blog that should go out in the next day or two as well.
JustMyGithub commentedon Apr 5, 2023
If anyone else is looking for it: Store support can be disabled as admin using
winget source remove msstoreThis 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.
denelon commentedon Apr 5, 2023
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 --forcein administrator mode.Search and install can also be restricted by adding "--source" or "-s ".
Examples:
winget search PowerToys -s wingetwinget search PowerToys -s msstoreYou can see the difference against
winget search PowerToys