Forum Discussion
bvenhaus
Dec 14, 2021Copper Contributor
The ms-appinstaller protocol has been disabled.
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...
- Dec 15, 2021
bvenhaus Thank you for your question. We removed the ms-appinstaller custom scheme due to a security vulnerability. We do intend to bring this back, and are working on it. For now, you can update the link on your website by removing 'ms-appinstaller:?source='
<html> <body> <h1> MyApp Web Page </h1> <a href="http://mywebservice.azureedge.net/HubApp.msix"> Install app package </a> <a href="http://mywebservice.azureedge.net/HubAppBundle.msixbundle"> Install app bundle </a> <a href="http://mywebservice.azureedge.net/HubAppSet.appinstaller"> Install related set </a> </body> </html>
jmiddour
Jan 04, 2022Copper Contributor
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.
JamievanWalsum
Jan 13, 2022Copper Contributor
Thanks for this.
Do you know if the auto update feature to work still when applying this work around?
I am using the AppInstallerUpdateFrequency msbuild argum in my build pipeline.
Do you know if the auto update feature to work still when applying this work around?
I am using the AppInstallerUpdateFrequency msbuild argum in my build pipeline.
- jmiddourJan 13, 2022Copper ContributorJamievanWalsum -- as far as I know, the auto update will still work. Our apps that have been converted to msix don't have frequent updates right now, so I don't know from first hand experience yet. If I run into issues, I will post here.
- JamievanWalsumJan 14, 2022Copper Contributor@jimddour Ok thanks.
I was able to get this working without loss of functionality by:
- updating my mime types of the server hosting the app installer (AppInstallerUri flag on vsbuild) to set the .appinstaller extension to 'application/octet-stream'
- distribute to my users the produced .appinstaller file (https://{AppInstallerUri}/{AppName}.appinstaller) [You can check this under Additional links -> App Installer File].
From what I see, updates are still working and the only change is the above URL downloads the .appinstaller file to run opposed to the 'get the app' link which streams it to the browser.
I've just put a link to the https://{AppInstallerUri}/{AppName}.appinstaller on my products landing page. (this URL stays the same and is updated automatically for new deployments through an Azure DevOps pipeline)- hrb-2Jan 14, 2022Brass ContributorI should have read closer, this is good you have found a way to "automate" the work-around, but it does not fix the fact that users must save a file they downloaded from the internet and execute it themselves. Once on their hard drives this can be distributed in many ways intended or otherwise. The real advantage here is that updates can be supported in the same multi-step way, or are the users not required to save the next update to the hard drive and execute it because it just happens in the background?