Are msixbundles downloaded incrementally when installed via appinstaller? #1465
-
|
Suppose I create an misxbundle (or appxbundle) using Visual Studio, where the msix packages are contained within the bundle (so not a flat bundle). Suppose I also create an appinstaller file to install the msixbundle and publish them to a standard CDN like CloudFront. When the user clicks on a link to the applinstaller file, will the whole msixbundle file be downloaded, or will only the necessary bits be downloaded? For example, I don't want a user on an x86 64-bit machine to download the ARM64 msix package. As I understand it, the mxisbundle file is essentially a zip file and it's not normal to only download part of a zip file. However, it is technically possible to achieve this using range requests (according to a quick Google search). So I'd like a definitive answer on this if possible. The other alternative, which makes more sense to me, is to create a flat bundle whereby the msix packages are actually placed alongside the bundle file, which only contains metadata. However, Visual Studio doesn't have an option for this so I would have to use the command line which is a bit awkward. Also on initial testing I found that non-flat msixbundle packages will not work properly with appinstaller files that specify AutomaticBackgroundTask updates in some cases. Specifically it happened when I added a runtime component to the main app, but I'll need to do more testing. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
|
MSIX auto update over third party CDN feature depends on the client to have AppInstaller have installed & most importantly requires AppInstaller to function correctly. unfortunately, AppInstaller doesn't reliably function correctly which renders MSIX basically useless. MSIX is basically glorified zip file. declaring manifests has been a thing since win2k. the only thing it provides is virtualization aka clean install-uninstall. as a sane developer I actively encourage others to use real zip files with raw exes instead of glorified zips. |
Beta Was this translation helpful? Give feedback.
-
|
I've been using AppInstaller for years. While it has its quirks, I haven't hit any issues with it not functioning correctly. What specific issues are you hitting? |
Beta Was this translation helpful? Give feedback.
-
No
Yes Deployment accomplishes this through several techniques, including...
Flat bundles are convenient for package creation. As you note, a Flat Bundle only contains metadata which is much faster to create than e.g. a bundle containing 50GB of packages :-)
If VS doesn't support/facilitate flat bundle creation and it's something you're interested in please create a new issue to further discuss that enhancement. Thank you.
I'm not aware of any issue here. Please do share if/when you have more information. |
Beta Was this translation helpful? Give feedback.
-
|
@DrusTheAxe - thanks for the reply. Firstly, regarding the error with an appinstaller that specifies AutomaticBackgroundTask. I can no longer reproduce this error. However, I am reasonably confident the error existed at some point. So perhaps it's been fixed. Alternatively, it could perhaps have been an issue with my ISP (VirginMedia). A few days ago I had problems with accessing files on a DigitalOcean space and they said that they were having issues with VirginMedia to do with DNS and to change my DNS server to Cloudflare or similar, which solved the issue. Not sure whether it could have been related but it's a possibility I guess (I mean I wasn't using a DigitalOcean space for the appinstaller but perhaps it could have been the same underlying issue). The issue no longer occurs now anyway do I can't test that theory. Now, regarding what will be downloaded when packing my app as a bundle vs a flat bundle. I thought I'd do some testing on this to ensure the delivery optimization service is not downloading more than needed. In conclusion I found that it downloads significantly more bytes than needed, which is especially bad for small bundles. For a bundle where the MSIX packages are around 0.4MB in size, it downloads 10 times more bytes than needed. For a more realistic MSIX package size of 5MB, it downloads 2.2 times more bytes than needed. Using a flat bundle, there is a marked improvement, although it would be better if it simply downloaded the whole of the relevant MSIX once instead of trying to do byte range requests, at least for relatively small packages. For a bundle where the MSIX packages are around 0.4MB in size, it downloads 3.5 times more bytes than needed. For a more realistic MSIX package size of 5MB, it downloads 1.4 times more bytes than needed. For reference, here are the nginx logs I used to determine this (note after HTTP/2.0 comes the response status then the bytes sent). Installing a normal x86, x64, arm64 bundle on an x64 machine where the x64 package is 0.39MB in size: Total downloaded: 4.8MB Installing a normal x86, x64, arm64 bundle on an x64 machine where the x64 package is 4.9MB in size: Total downloaded: 10.8MB Installing a flat x86, x64, arm64 bundle on an x64 machine where the x64 package is 0.39MB in size: Total downloaded: 1.4MB Installing a flat x86, x64, arm64 bundle on an x64 machine where the x64 package is 4.9MB in size: Total downloaded: 7.0MB |
Beta Was this translation helpful? Give feedback.
-
|
Interesting data. Thanks for sharing. Yes we're aware Delivery Optimization (DO) has potential for improvement and are investigating. Unclear yet what optimizations we'll bring to bear or when as we're still in the analysis phase (as you can imagine, "make better" is a lot easier said than done). Given how significant the benefits can be (especially at Microsoft-scale) I expect something to happen here. As they say, measure twice |
Beta Was this translation helpful? Give feedback.
No
Yes
Deployment accomplishes this through several techniques, including...