SOLVED

The ms-appinstaller protocol has been disabled.

Copper Contributor

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

 

appinstaller.png

 

 

57 Replies
Hi all,
To confirm, yes, we do plan on correcting this. I know the team is working on bringing it back, but don't have a date for this yet.
Thanks for the update Aditi! We have had a critical issue open with Microsoft premiere support for over a week, and unfortunatly have gotten nowhere except links to articles about workarounds, so at least your responding here. At this point we are having to figure out ways around this issue and abandon this funtionality (probably for good). It is a shame though as it worked very well for quite a while.
If you have a workaround which is feasible it would be good to know. I doubt a good solution exists.
The workaround is for users to download the XML file and open it. If you need the custom parameters then there's no workaround.

If you don't need custom parameters then it's worth maybe taking a deep breath and looking at the actual UX change. Before:

1. Click the link.
2. Click the yes button in "Open this link in App Installer?"
3. Click Install/Launch in App Installer.

After:

1. Click the link. It downloads.
2. Click the download in the browser. App Installer opens.
3. Click the Launch/Install button.

Same number of clicks. The URL handler _is_ better because it has more features, because the permission to open URLs is remembered per site, because URLs work in more places, because it doesn't clutter the user's downloads folder and so on. So we all hope it'll return. But, for distribution via a web page, the difference isn't that large.
@MikeH Thanks for the details! How do automatic updates work with the workaround? Do they still happen automatically or does the user need to go download the installer manually?

Tom
Updates do work, yes. The .appinstaller file helpfully contains its own URL and that's what's used for update checking.

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.

Unfortunately not a workable solution. Where on earth is the fix Microsoft?

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:

new page.png

 

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.

Our Microsoft Store app package for sideloading on our website has this issue.
If my understanding is correct, we just need to remove "ms-appinstaller:?source=" in index.html generated by Visual Studio.
In other words:
Change
<a href='ms-appinstaller:?source=https://www.mydomain.com/download/myapp.appinstaller'>
to
<a href='https://www.mydomain.com/download/myapp.appinstaller'>

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!!!

I assume the Engineer responsible for this has carried out a thorough risk assessment, taking into account customer impact and loss of service.

This is despicable, can anyone in Microsoft be actually bothered to reply. Also what compenmsation scheme is in place for Microsoft customer.

@hrb-1 PLEASE MICROSOFT provide guidance on how long it will be before side loading from a web site will be enabled again!!!

@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.

@jmiddour I assume Visual Studio will do this automatically so that we do not need to remember to do this every time we build the bundle. If so, do you know when this Visual Studio update will be released?
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.
Microsoft,
How do we auto update side loaded UWP / WinUI3 Apps now that you have disabled this?
How long will this be disabled for? it is a critical feature.
@zipswich -- I do not know of any pending updates to Visual Studio to do this for you. As far as I know, this step must be done every time you build the package until the protocol is re-enabled.
@JamievanWalsum -- 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.
@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)
Genous! I am going to test this out, but I have to wonder how MS will shut this down as this is a potential work-around for those that were using app installer to pass mal-ware which was the security issue that caused the shutdown as well.