Dec 14 2021 10:07 AM - edited Dec 14 2021 10:53 AM
I just found out that users can no longer install my MSIX from my website. This is a WPF application packaged with "Windows Application Packaging Project" (wapproj). When users click the "Get the app" button they now see the error below saying the protocol has been disabled. Why is this? Is this permanent? Is there a way to enable it?
There's a short mention of this in the docs but it doesn't mention why this is happening or how to enable it.
Installing Windows 10 apps from a web page - MSIX | Microsoft Docs
Is this no longer supported?
<html>
<body>
<h1> MyApp Web Page </h1>
<a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubApp.msix"> Install app package </a>
<a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubAppBundle.msixbundle"> Install app bundle </a>
<a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubAppSet.appinstaller"> Install related set </a>
</body>
</html>
The ms-appinstaller protocol has been disabled. Please ask the vendor to update the weblink. For more information go to aka.ms/ms-appinstaller-disabled
Dec 21 2021 10:19 AM
Dec 23 2021 11:36 AM
Dec 24 2021 04:00 AM
Dec 24 2021 05:28 AM
Dec 24 2021 01:13 PM
Dec 28 2021 08:34 AM
Jan 03 2022 10:50 AM
Do you have a timeframe on when this will be addressed?
We have an .exe that is shipped on thousands of 3rd party drives that calls an ms-appinstaller link through the shell (no browser or web page involved). There isn't a way for us to just "update" the URL to not use ms-appinstaller.
Jan 04 2022 01:21 AM
Jan 04 2022 12:55 PM
To anyone else facing implementing a workaround and is using Azure pipelines:
here is a yaml task that will edit the generated html to remove the protocol and include explicit instructions that the button will cause a download, and the downloaded file should be run.
Anonymized example from my implementation:
And here is the task:
- task: PowerShell@2
inputs:
targetType: 'inline'
script: |
$x = gci -Recurse *.html
$page = get-content $x
$newpage = $page | foreach { [regex]::Replace( $_,'ms-appinstaller\:\?source\=','' ) }
$newpage = $newpage | foreach { [regex]::Replace( $_,'(<div class.*app-description[^<]*</div>)','$1'+[System.Environment]::NewLine+'<div class="insert instructions"><p style="color:red" >Installation instructions:<br>1. Click the install button to begin download of installer file<br>2. After download completes run installer file to install application</p></div>' ) }
set-content $x -Value $newpage
Note that there may be more efficient ways of accomplishing this, but I went with what I knew and could make generic.
Jan 05 2022 09:41 AM
Jan 11 2022 10:51 PM - edited Jan 11 2022 10:54 PM
It would appear this workaround requires end users to download, save, and open the application bundle. This is something we try to drill into there heads that they should not do. It also means that apps that normally automatically update will not be able to do so. Can you imagine Android or iOS disabling auto updates globally??? Unbelievable! As a result this only a partial work-around creates more problems than it solves, especially if updates need to distribute current data with the application. PLEASE MICROSOFT provide guidance on how long it will be before side loading from a web site will be enabled again!!!
Jan 12 2022 12:40 AM
Jan 12 2022 06:26 AM
@zipswich That is correct. The other thing we opted to do was add instructions to the html above the install button to handle the behavior change.
Jan 12 2022 10:49 AM
Jan 13 2022 02:48 AM
Jan 13 2022 02:49 AM
Jan 13 2022 11:13 AM
Jan 13 2022 11:16 AM
Jan 13 2022 06:15 PM
Jan 13 2022 06:45 PM