AppInstaller XML Issue

Question

I'm trying to follow the Microsoft documentation but I'm confused as to why my appinstaller is failing:

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller xmlns="http://schemas.microsoft.com/appx/appinstaller/2018" Uri="https://xxxxxx.blob.core.windows.net/installer/Package.appinstaller" Version="1.0.0.0">
    <MainPackage Name="MyApp" Version="12.21.289.0" Publisher="CN=xxxxxx" ProcessorArchitecture="x64" Uri="https://xxxxxx.blob.core.windows.net/installer/MyApp.msix"/>
    <UpdateSettings> <OnLaunch HoursBetweenUpdateChecks="1" /> <AutomaticBackgroundTask/> </UpdateSettings>
</AppInstaller>

If I run the MSIX file, it installs as it should. I've been trying to follow this: https://learn.microsoft.com/en-us/windows/msix/desktop/azure-dev-ops I get this error: And if I remove the UpdateSettings attribute it will just cause another error: "App installation failed with error message: Appinstaller operation failed with error code 0x80D05011. Detail: Unknown error (0x80d05011)"

Kindly please help.

Answer 1

Well, after three days of hopeless debugging and several attempts to find the root of this problem, we finally figured it out. See below for the workaround.

Delivery Optimization Service incorrectly caches the size of any HTTP resource it retrieves (it can be appinstaller file or MSIX package), and includes the Range HTTP header in the subsequent requests with potentially outdated byte range values.

For example, if your appinstaller is 725 bytes long, first time Windows DO Service makes a well-formed HTTP request and downloads the whole XML. Request example:

GET https://foobar.com/baz.appinstaller HTTP/1.1
Connection: Keep-Alive
Accept: */*
Range: bytes=0-724
User-Agent: Microsoft-Delivery-Optimization/10.0
MS-CV: ......
Content-Length: 0
Host: foobar.com

But if you have updated the appinstaller file at your web server, and its size is increased, for example, up to 4096 bytes, DoSvc still requests only first 725 bytes, and obviously gets a broken XML it couldn't parse. Even if ETag is handled correctly and has been changed for the appinstaller HTTP resource!

If your appinstaller file size decreases, it's likely that you will get 416 Range Not Satisfiable.

Here is the real response from Amazon S3 (where we host our appinstaller and MSIX packages) we have dumped using Fiddler:

HTTP/1.1 206 Partial Content
x-amz-id-2: ...
x-amz-request-id: ...
Date: Tue, 06 Apr 2021 21:45:12 GMT
Last-Modified: Tue, 06 Apr 2021 21:40:24 GMT
ETag: "af2d8bb5c638eca059cdb4dc6c694123"
Accept-Ranges: bytes
Content-Range: bytes 0-724/4096
Content-Type: application/appinstaller
Content-Length: 725
Server: AmazonS3

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller 
  Uri="https://tvd-packages.tradingview.com/beta/latest/win32/TradingView.appinstaller" 
  Version="1.0.0.1071"
  xmlns="http://schemas.microsoft.com/appx/appinstaller/2017/2">
  <MainPackage 
    Name="TradingView.Desktop" 
    Version="1.0.0.1071" 
    Publisher="CN=&quot;TradingView, Inc.&quot;, O=&quot;TradingView, Inc.&quot;, STREET=470 Olde Worthington Road Suite 200, L=Westerville, S=Ohio, PostalCode=43082, C=US" 
    ProcessorArchitecture="x64" 
    Uri="https://tvd-packages.tradingview.com/beta/1.0.0-beta.1.5/win32/x64/TradingView.msix" />
  <UpdateSettings>
    <OnLaunch HoursBetweenUpdateChecks="0" />
  </UpdateSettings>

<!--
- WHAT TH

Do you note Content-Range: bytes 0-724/4096 and the comment cut off?? This is the result of ill-formed HTTP Range request by Delivery Optimization Service.

WORKAROUND: Have you guessed it already? Yeah, just don't change the size of the appinstaller! For example, we padded it with XML comment up to 4096 bytes exactly, and if we need to add more sensible content to XML, we just remove some chars from XML comment to make it 4096 bytes again. We have even made a simple size test in our gitlab deployment pipeline to ensure that size of appinstaller was not accidentally changed.

You can check our current production appinstaller we use since April, 2021: https://tvd-packages.tradingview.com/stable/latest/win32/TradingView.appinstaller

P.S. The problem turns up if requests are performed to the same URL. If the URL changes, DoSvc HTTP client logic handles it as a different resource. That's why the appinstaller files are more likely victims of this problem.

Answer 2

If this helps anyone, I found this thread: https://techcommunity.microsoft.com/t5/msix-deployment/windows-10-2004-msix-not-updating-please-check-whether-the/m-p/1466701

Basically the answer was restart your machine. Which I did, and it seem to have fixed it

as @The-pademelon also mentioned restarting the Delivery Optimization Service also works.

Answer 3

This is a bug in the windows delivery optimisation service, all we can do for now is a workaround.

Developers: The issue is caused by part of version number the changing how many digits it has, like going from 1.0.9.9 to 1.0.10.0 which happens pretty quickly if you let the build process automatically increment these. The workaround is to roll over to the next version up (1.1.0.0) instead. The best way to deal with this is probably to always start with a base version of 0.100.100 or 0.1000.1000 because otherwise you will be severely limited in how many total version number are available.

Users: Task Manager -> Services -> DoSvc -> Restart This is a bit quicker and more convenient than a system restart.

Note: the broken state of the service is caused by this version numbering bug, but once it happens a restart is the only way to correct it.

Answer 4

To add to the answer by @user3190036: the max version number I managed to build and install was 65535.65535.65535.9

It seems that the 4th range is where the bug is because it is not compliant with the schema which comes up as part of the error message if you use an arbitrary large number like this:

MakeAppx : error: Error info: error C00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 7, Column 33, Reason: '1.0.125500.9' violates pattern constraint of 
'(0|[1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])(\.(0|[1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])){3}'.
The attribute 'Version' with value '1.0.125500.9' failed to parse.

Deconstructing the regex as

(0
|[1-9][0-9]{0,3}
|[1-5][0-9]{4}
|6[0-4][0-9]{3}
|65[0-4][0-9]{2}
|655[0-2][0-9]
|6553[0-5])

(\.
(0
|[1-9][0-9]{0,3}
|[1-5][0-9]{4}|6[0-4][0-9]{3}
|65[0-4][0-9]{2}
|655[0-2][0-9]
|6553[0-5])
){3}

we can see the possible range of values more clearly: 0..65535 for any of the 4 parts, but since there is a bug, the 4th part is limited to a single digit 0..9.

The smallest version number that worked for me was 0.0.0.0.

Tested on an up-to-date Win Server 2019 on 05 May 2021