Sideload AppInstaller cache

Chris Hurst 1 Reputation point
2020-03-26T21:21:25.413+00:00

I have a Sideload AppInstaller (MSIXBundle) that I'm testing for deployment. I have published locally to disk and manually pushed to an IIS server. When I load the index.html file in a web browser the new package version, etc shows up as expected, but when I click the link to install the *.appinstaller, the older version of the app is displayed and downloaded/installed.

Is there caching built into the AppInstaller which is causing this? What steps are needed to flush/clear any caching (the old ClickOnce required caching like this as well and was very annoying)?

Universal Windows Platform (UWP)
{count} votes

2 answers

Sort by: Most helpful
  1. John Torjo 861 Reputation points
    2020-03-26T23:49:44.17+00:00

    Please check this out: https://learn.microsoft.com/answers/questions/4027/uwp-cant-install-signed-application-non-ms-storeco.html

    Having said that, look at that test installer file, and everything needs to be exact - there's no room for error. All the files in the app installer need to be exactly as you describe them in the appinstaller file.

    Also, the appinstaller file will work only if you download it from your server. If you use the local appinstaller, it will NOT work.

    Hope this helps.

    0 comments No comments

  2. Chris Hurst 1 Reputation point
    2020-03-27T14:05:40.837+00:00

    Not sure the link really applies to what I'm seeing. In my case I have a WPF/WCF app that I need a way to web deploy as a stop gap and thus it's a .NET Framework app that I'm hosting on Windows 2016 IIS (any before you think it, I've already worked through the mimetype mapping issues, etc). I'm downloading/installing the appinstaller from the remote server using an FQDN url (inside the network) to my Win10 1903 with sideloading enabled (I downgraded it from Dev to verify for user in the field).

    The need to manually create an .appinstaller file is currently done via VisualStudio (but plans to automate via script for CI/CD). With that being said, I do believe you may have triggered something that I missed/wasn't expecting. When I browse to the index.html file with a link to the *.appinstaller, I was expecting this workflow to read/load/execute the .msixbundle from the MainBundle element. While I had manually changed this URL path to reflect the \Download directory change I neglected to also change the AppInstaller element's Uri="" attribute to iwhich was pointing to the older *.appinstaller in the root directory of the webserver.

    This too me is very odd as it means the browser is downloading the *.appinstaller file then reading the internal <AppInstaller> element to then read the *.appinstaller file again from the server to launch the *.msixbundle.