Sideload AppInstaller cache

Question

question

ChrisHurst-7144 asked · Mar 26 at 09:21 PM

Sideload AppInstaller cache

I have a Sideload AppInstaller (MSIXBundle) that I&#39;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)?

windows-uwp

1

10 |1000 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

ChrisHurst-7144 · Mar 26 at 09:39 PM

This gets better... When publishing the package, I simply use the root hostname of the server as a placeholder (e.g. https://myserver.mydomain.com/) but I'm actually hosting the package in a \Downloads directory below that and I've modified the index.html to reflect this. What appears to be happening is when clicking the "Get the app" link, the AppInstaller is picking up the older *.appinstaller that I have in the root of the host instead of actually following the source path as indicated in the html file

<a href='ms-appinstaller:?source=https://myserver.mydomain.com/Download/MyPackageDeploy.appinstaller'>;

Why is the correct appinstaller not being used? This sounds like a bug in the ms-appinstaller logic.

This is on Chrome, not that it should matter

0 · ·

Answer 1 · 2020-03-26T23:49:44.17Z

jtorjo answered · Mar 26 at 11:49 PM

Please check this out: https://docs.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.

Share

10 |1000 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Answer 2 · 2020-03-27T14:05:40.837Z

ChrisHurst-7144 answered · Mar 27 at 02:05 PM

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.

5 Share

10 |1000 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

FayWang-MSFT · Mar 30 at 07:18 AM

From what you said, it seems to indicate that the reason why still display the older version of the app is you neglected to also change the AppInstaller element's Uri="" attribute, have you solved this issue now? If you have solved it, you can mark your answer to help others with the same problem.

0 · ·

ChrisHurst-7144 FayWang-MSFT · Mar 30 at 02:13 PM

Can you confirm this is the expected functionality?

0 · ·

FayWang-MSFT ChrisHurst-7144 · Mar 31 at 06:18 AM

You could try to change the AppInstaller element's Uri="" attribute to see if it can display the newest app successfully.

0 · ·

Show more comments

question