Make it possible to install apps from the Store about windows-dev-box-setup-scripts HOT 42 OPEN

Thanks for discussing & sharing your thoughts on this.

As @DarthSpock points out, to temporarily circumvent this limitation, we re-publish Store WSL distros on our CDN, but this isn't a scalable way to deal with the issue.

We regularly make the request to the Store team for a way to install Store packages via the command-line, and encourage you to do the same via Feedback Hub - your voices often carry more weight than ours ;)

from windows-dev-box-setup-scripts.

@DarthSpock this doesn't address the issue I presented. This command is simply downloading something from somewhere. I want to install something from the Store, preferably using official Store APIs in my computer.

The .ps1 scripts here use this to download the .appx file from somewhere and then sideload them. My concerns with this are twofold:

1. The .appx download origin is not the Store (maybe the files in the script is the same file that is in the Store, but it is not coming from the same url the Store uses)
2. The .appx is being sideloaded. I'm not sure, but I think it will not get updated if the developer updates it in the Store. (please correct me if I'm wrong)

How do I install, for example, "Paint.NET" from the Store using scripting? Is it possible to generate an official download url for a Store .appx and use the combination Invoke-WebRequest + Add-AppxPackage to install it and still get updates? Do I need to know the app version in the Store to get the url or can I get a "default" url for the app that will always point to the latest version? How would I generate such urls for the apps I want/need to install when I repave?

An even better solution would be to have something like Acquire-StorePackage, where you would pass the app name, key or guid (or something) and it would install it from the Store. I understand that this request is more for the Windows Store team than for the champions in this repo, but I suppose the relevant people might see this and take pity on us folks trying to automate things...

from windows-dev-box-setup-scripts.

I just created a repo to store my repave related scripts repave-scripts. There I have the script I am currently using when I repave my PCs. I was storing those scripts in my OneDrive account, but I figured that having them in source control is a better solution. The code I mentioned above is there, if anyone is curious.

I used that script recently to repave my work laptop and it worked quite well, but not as well as it would have if I could automate the Windows Store installs. I also wish Visual Studio and SQL Server Management Studio where available in the store, but I get why they are not (yet anyway) and in any case this has nothing to do with this issue or repo.

from windows-dev-box-setup-scripts.

@DarthSpock Yep, I understand and agree this is a valid approach, but catering only to big companies isn't how things should work anymore. Specially in the dev circles, we have more and more hobbyists, remote workers and BYOD friendly companies.

What I am asking here (hoping actually) is for someone from Microsoft to acknowledge and address (or at least start the process of addressing) the need for APIs that will allow end users and IT managers to install apps from the Store in an automated way.

Of course, I also understand these kinds of APIs may be posed as a security threat and need to be properly implemented so as to not be abused by malicious actors (malware, viruses, rogue programs, hackers, disgruntled employees, bored/grounded kids, ...).

Anyway, hoping for a better automation story here and really excited by the mere existence of this repo. We are making progress ;)

from windows-dev-box-setup-scripts.

I am almost sure I had already added this feedback using the Feedback Hub app a long time ago (certainly more than a year).

I didn't find it, so I created a new one in the following link. Upvotes are appreciated. Provide a way (scripting api/commands) for users to install/remove Store apps via command-line scripts

from windows-dev-box-setup-scripts.

Reading some documentation while replying to @DarthSpock's comment, I found a few articles using a combination of Get-AppxPackage + Add-AppxPackage to reinstall apps the current user removed or that got "lost" in some Insiders update. It got me thinking:

If I use Get-AppxPackage on my machine before repaving it to get and save the manifest files for the apps I will want to get back after the repave, it might be possible to use Add-AppxPackage later pointing to the saved manifests and have the apps reinstalled. I'll have to investigate that on my next repave (might be time to do it on my old Surface Pro 2 anyway). If I find the time over the weekend, I'll let you know of my findings.

I'm now also thinking of using Remove-AppxPackage in my script to remove some unwanted apps that Microsoft now insists on pushing to users (I am looking at you Candy Crush...)

from windows-dev-box-setup-scripts.

Here is an update on my testing.

I was able to improve my personal post-repave script with some interesting bits.

• To install apps available on Chocolatey, I'm using choco install -y <package>
• To install apps and Microsoft Edge Extensions from the Store I am using start "" ms-windows-store://pdp/?ProductId=9NBLGGH5279M @REM Open Live Writer
  • In order to do be able to do that, I had to navigate to each of desired apps in the Store and click the "share" option, then get the share link and extract the product id. I tried just using that share link in my script, but it opened the browser and then I had to click to open in the Store App and then again to install. I changed that by using a protocol call to the Store app, so it now goes strait to the Store and I just click install. I had to put a pause between each store app in the script.
• After the store apps are installed/queued, I call some websites from the script, to download apps not available in the Store (SQL Server Express, SQL Management Studio, Visual Studio...). I wish all of those where available in the Store (at least SQL Management Studio and Visual Studio).
• Finally, I call 2 inline powershell scripts to uninstall and unprovision a few unwanted apps and games that always come with Win10:
  • @powershell -NoProfile -ExecutionPolicy Bypass -Command "$AppList = @('*Microsoft.Office.OneNote*', '*Microsoft.MicrosoftOfficeHub*', '*Microsoft.BingNews*', '*bingfinance*', '*sports*', '*adobe*', '*Microsoft.DrawboardPDF*', '*facebook*', '*bethesda*', '*farmville*'); foreach ($App in $AppList) { Get-AppxProvisionedPackage -Online | Where-Object {$_.DisplayName -like $App} | Remove-AppxProvisionedPackage -Online }"
  • @powershell -NoProfile -ExecutionPolicy Bypass -Command "$AppList = @('*Disney*', '*king.com*', '*HiddenCity*', '*DolbyLaboratories*', '*Microsoft.MicrosoftOfficeHub*', '*Microsoft.BingNews*', '*getstarted*', '*gethelp*', '*bingfinance*', '*sports*', '*adobe*', '*Microsoft.DrawboardPDF*', '*facebook*', '*bethesda*', '*farmville*'); foreach ($App in $AppList) { Get-AppxPackage -Name $App | Remove-AppxPackage }"

PS.: my script is a .bat file, not .ps1, but I do call powershell from it in the end, as you can see.

from windows-dev-box-setup-scripts.

@kelps: Thanks for the feedback and suggestions.

Alas, the point of these scripts is to automate the setup of a newly-installed/re-paved dev box.

Since Windows Store doesn't yet provide an app installation automation mechanism, automating the installation of store apps is sub-optimal at best, and breaks our automation goals at best :(

However, we do continue to discuss with the store team. Hoping we'll be able to use the feedback like the above as fuel for these discussions ;)

And, yes, MSIX, doesn't directly benefit the install automation story for end-users, but it does provide benefits wherein if app vendors publish their apps in MSIX packages, it'll make the automation job a little easier and more consistent.

from windows-dev-box-setup-scripts.

You can absolutely download the .appx files and their dependencies from the Microsoft Store via PowerShell in a completely automated fashion, as long as the app is already installed on your computer. It's not because you need the package contents, it's because you need the app info to force the Store to re-download the .appx files and keep them permanently.
Installing a new app from PowerShell from the store is a bit tricky. I am currently working on it.

from windows-dev-box-setup-scripts.

Love this feedback, thank you.

from windows-dev-box-setup-scripts.

@gep13, maybe "documentation" isn't a proper way to classify them. How about "tech articles"? Here are a couple:
How to reinstall default apps in Windows 10
Adding and Removing Windows 10 Apps with PowerShell

from windows-dev-box-setup-scripts.

@kelps: I'd suggest creating & sharing a new feedback item using the same text, but targeting the "Microsoft Store" | "Installing Apps" categories. This isn't really about payment per se (though that will have to be part of the equation for any solution).

from windows-dev-box-setup-scripts.

@bitcrazed Ohhhh, That was the intent. I must've slipped or scrolled to the next sub category without noticing it. Thanks for pointing it out. I just created a new feedback in the correct sub-category.

Here is the link for the new feedback (I also edited the previous post to add the correct link): Provide a way (scripting api/commands) for users to install/remove Store apps via command-line scripts

from windows-dev-box-setup-scripts.

@DarthSpock I agree with all you said. If it sounded like I was disagreeing, I apologize.

from windows-dev-box-setup-scripts.

@manhinhang Appreciate your effort here, but driving the Microsoft Store via UI automation is likely to be very error prone and fragile.

As @WSLUser and others have stated and as I can confirm, installation via winget will be the preferred approach. Appreciate everyone's patience, but it'll be worth the wait ;)

from windows-dev-box-setup-scripts.

@Floccinaucinihilipilification11 No, even worse than that!

from windows-dev-box-setup-scripts.

Weird. I just opened both feedbacks here. I don't get why we can only see and vote on feedbacks with the Feedback Hub app (this could and should be a website, at least for viewing and voting on feedbacks). Try from another computer, but if it doesn't work and you end up creating a new feedback, add a link to mine in yours and put your link here too so I and others can upvote it as well. I'll add a comment to mine with a link to yours when I have it. Maybe they get grouped together this way...

Mine is https://aka.ms/AA1bl1g

from windows-dev-box-setup-scripts.

Winget would most likely be the best way forward with this

from windows-dev-box-setup-scripts.

Searching the MS Store from PowerShell, First Beta

https://dev.to/ledgeruser2/search-microsoft-store-from-powershell-2bjj

from windows-dev-box-setup-scripts.

So in Windows proper we do have this Powershell command (The example comes from https://docs.microsoft.com/en-us/windows/wsl/install-on-server):

Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1604 -OutFile ~/Ubuntu.zip -UseBasicParsing

(due to this example there are extra bits on the end and thus require the below)

Expand-Archive ~/Ubuntu.zip ~/Ubuntu

Distro.exe where Distro in this case = Ubuntu

We also have curl and tar available in Windows now. Don't see tar being very useful other than for Linux distros (or any tar files that somehow make it into the Store) but curl does sorta replace (but not entirely) Invoke-WebRequest

from windows-dev-box-setup-scripts.

So the https://aka.ms/wsl-ubuntu-1604 is from the Store but automatically provides the option to install the appx without the need to go through the Store to get it. As far as getting updates goes, well if you're in a corporate network, you probably won't get them if you don't have Store access. Which makes standalone appx for different apps extremely useful. In larger organizations, there is typically a workstation that will have access in order to obtain certain apps and will go through a test, then update phase. We can't assume all devs will have access to the Store so while this may not fit your specific needs, it will address somebody else's.

from windows-dev-box-setup-scripts.

@kelps can you perhaps to the documentation that you were looking at? Thanks!

from windows-dev-box-setup-scripts.

@kelps thanks for providing those links, appreciate it!

from windows-dev-box-setup-scripts.

Yes, I think this project needs to address both scenarios. Those who can use the Store and those can't. I'm still looking forward to the day when we can honestly get all dev work done using a combo of WSL and Windows but unfortunately the dev community targetted doesn't include anything GUI or hardware related if it's for Linux, which is a shame in my mind. If they could get AMD/NVIDIA/Intel onto WSL, well now, they would be able to bring in far more profit and the rest of us would have the advantage of fully harnessing our hardware for WSL (thus drastically improving performance).

from windows-dev-box-setup-scripts.

We regularly make the request to the Store team for a way to install Store packages via the command-line

Where on the Feedback Hub would you recommend providing input or similarly, would a UWP UserVoice be appropiate? This is bearing in mind it would need to encompass more than just WSL Distros. (We'll need a make a list of commonly used apps)

from windows-dev-box-setup-scripts.

@DarthSpock I think the apis should allow installing apps directly from the Store, no matter what kind of app it is, so not only WSL or a specific kind/category. It should behave with the same restrictions you would get when using the Store app, so if an app is blocked by a policy or unavailable to the user, it also would be blocked via scripts. Any powershell commands created for this should use the same code the Store already uses, to ensure all the same rules apply.

I would also add some security features like: by default the command only installs apps the user already owns or apps that are free (there should be argument flags to override this behavior, of course). If the user doesn't own the app, the Store purchase UI should be displayed to confirme the purchase (there could be a flag that dispenses this step if the app is free, but it shouldn't be on by default).

from windows-dev-box-setup-scripts.

@kelps Nothing you said is opposite of what I was saying. I'm in full agreement, there should be APIs for installing from the store. But if those APIs require connectivity to the Store itself, it will most likely be blocked on most corporate networks. But it also might be an easier sell to corporations to allow API connectivity for command-line only access vice giving users Store access (not to mention no admin account should have web access whatsoever including the API connectivity). This access could then be created as a security group in AD that only those who require it would be granted access to it.

from windows-dev-box-setup-scripts.

Also a note to bear in mind for future: there is a initiative to make apps cross-platform that would be hosted in the Store. In essence, a one and done for developers who have to target multiple platforms. This is still early in it's infancy but eventually this project will need to address those APIs for connection to other platforms besides Windows.

from windows-dev-box-setup-scripts.

If the user doesn't own the app, the Store purchase UI should be displayed to confirm the purchase (there could be a flag that dispenses this step if the app is free, but it shouldn't be on by default)

To add to that, if the app not owned is a free app or has a free trial, that will need to be addressed as well. I'm also seeing a logistic and security issue here. If in a corporate environment, the developer won't have authorization to purchase an app from the Store. It would have to go through their finance and security first. A mechanism will need to exist to ensure that unauthorized apps aren't installed (that prevents Group Policy/HIPS, etc. from kicking off). It wouldn't be fair to the business to have to put safe rails on something they aren't responsible for that they now need to dedicate resources towards if they want to allow the connection.

from windows-dev-box-setup-scripts.

I found something that may be useful to us that was announced at MS Build: https://developer.microsoft.com/en-us/events/build/content/announcing-it-pro-package-tool?playlist=9f769669-4695-4eba-a14c-6ac7bb0001ba

from windows-dev-box-setup-scripts.

@DarthSpock I am very interested in that, but that won't be viable until the next release of Windows 10 for support of the .MSIX format.

from windows-dev-box-setup-scripts.

True, it would only help those on the latest Win 10 but does have the potential for resolving this issue at least for that build and up and of course recommend upgrading to that build. But yes, we'll need something else in the mean-time to support earlier versions of Win 10 along with 7 and 8.1.

from windows-dev-box-setup-scripts.

To me, it looks like MSIX is a tool mainly for enterprises and software vendors/developers. It doesn't look like it'll help people that simply want to script the installation of software from the Microsoft Store on Windows 10+.

I'm not saying MSIX is bad. It is a HUGE step forward for client software deployment on Windows and I can't wait for vendors to start making their app installers available in this format, as it'll improve computer stability, app isolation and auto-update. MSIX is actually a perfect format for stuff to be delivered using Chocolatey, IMHO. And, if I'm not mistaken, there is a KB that adds support for MSIX on Windows 7. Of course app isolation and some of the other aspects will be Win10+ only, but this makes MSIX more useful, by being available in more places.

from windows-dev-box-setup-scripts.

Hey @kelps. Thanks for sharing. A few notes:

1. If you were to rename your script to *.ps1, you wouldn't need to invoke PowerShell at the start
2. I recommend you begin and end your script by disabling and re-enabling UAC, etc.
3. Another benefit of moving to PowerShell is that you can explicitly modify your registry settings via HKLM:... or HKCU: registry mounts, further reducing your file count.
4. Visual Studio can be installed by Chocolatey and you can control which features you want enabled! See https://chocolatey.org/packages/visualstudio2017enterprise for more info
5. Same as above for SQL Management Studio: https://chocolatey.org/packages/sql-server-management-studio
6. You may also prefer to NOT pause between each package install so you can walk away and leave your machine to install everything as quickly as possible without requiring constant monitoring :)

HTH.

from windows-dev-box-setup-scripts.

Thanks for the tips @bitcrazed.

1- I know I could use .ps1 files for this instead of .bat, but I prefer the simplicity of being able to double click it to run. This was a conscious decision, but I might change it to a .ps1 file and have the .bat simply invoke PowerShell to run it.
2- I'll look into it. Do any of the scripts here have the code for disabling and enabling UAC? Is it doable from .bat or only .ps1?
3- Ok, that is definitely a benefit that I have not considered before. I do like the .reg files because I just had to export them, but having it in the script reduces the click count.
4- 5- This I didn't know and I love it! I'll have to try it. At least 2 manual installations I will not have to deal with.
6- I had the pauses there because those installations from chocolatey used to fail a lot when I started doing this. This made it easier for me to see that something went wrong, but I suppose you're right. I only really need the pauses now between the Windows Store apps (I really hope this will improve eventually)

Once again, thanks for the tips.

from windows-dev-box-setup-scripts.

This old issue remains relevant, and I found it by searching for a solution to a problem that impacts my daily job. I install Windows 10 from scratch frequently using an answer file for unattended install. One of the apps I need to install is Windbg Preview (from the microsoft store). Not having a proper way to install this in an unattended manner creates waste every time I do an OS install, where I have had to "fix" the computer by interactively installing the app from the microsoft store.

I am unable to view the content of the feedback hub issue that is mentioned in #30 (comment). @kelps, did you ever get a helpful resolution within your feedback hub issue?

from windows-dev-box-setup-scripts.

@jjulianoatnv No, I did not get any resolution to this. Unfortunately my feedback had only 22 Upvotes (+ another 13 upvotes in the first feedback I created in the wrong category).

Maybe with more votes, someone might prioritize it. One can aways hope...

from windows-dev-box-setup-scripts.

Thanks for responding. FWIW, when I click your link to feedback hub I get, "Your account doesn't have access to this feedback."
I'm planning to file my own separate feedback later this week.

from windows-dev-box-setup-scripts.

Thanks for responding. FWIW, when I click your link to feedback hub I get, "Your account doesn't have access to this feedback."

Same for me :(

from windows-dev-box-setup-scripts.

I have found a temporary solution by allowing the user to manually click the install button in the store app. see my solution here

from windows-dev-box-setup-scripts.

I created CLI tools for download app from store but it required start Appium server locally to automate stuff. Some app from Microsoft app are not available on winget or chocolatey.
https://github.com/manhinhang/ms-store-install-cli

from windows-dev-box-setup-scripts.

@bitcrazed You mean, about as error-prone as your average piece of Microsoft software? 🤣🤣🤣

from windows-dev-box-setup-scripts.