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.

Diastase

Hi @LostButFound, would you mind sharing the detail log here and pipeline definition here? – Birdlime

Answer 1

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.

Wallflower

I posted my findings about the ranges as a separate answer. Too much info to fit into a comment. Feel free to update your answer to keep it all in one place. – Spelt

@Spelt Thanks for sharing your results. I was having an issue going above 0.0.9.0 to 0.0.10.0, resulting in the DoSvc service going into a corrupt state when the client tried to update. Your results on what will build are useful but to complete the picture I still intend to test what ranges cause this issue, which happens after a build is completed and uploaded and an update is triggered on the client machine. – Wallflower

The problem is reproduced because the size of appinstaller increased when additional digit was added to the version string. See my answer for the explanation. – Nodal

Answer 2

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.

Nodal

Thanks for putting the time in. I don't like the idea of manually editing the appinstaller after every build but it is nice to at least know that is an option. Being limited to 999 versions could be pretty crippling in the long term. This information might also be useful for encouraging Microsoft to fix the issue. You have pretty much handed them all the debugging and diagnosis work on a silver plate. Please everyone who reads this file a report. – Wallflower

I reported this developercommunity.visualstudio.com/t/…? for visual studio, and if you go into the windows feedback app and search for "DoSvc service fails to install appinstaller" you should find the windows feedback report I filed. Anyone affected by this issue should vote on these issues. I think you have to be logged in for both services. – Wallflower

@Nodal thanks for the workaround. when do you pad the XML? is there a way to run a powershell script or something during the publish process, before the *.appinstaller file is included in the package? I tried to add a custom Target that executes a powershell script to the *.wapproj project file but it doesn't seem to support it xml <Target Name="Test" AfterTargets="Publish"> <Exec Command="powershell $(MSBuildProjectDirectory)\appinstaller-length-fixer.ps1 $(MSBuildProjectDirectory)\Package.appinstaller\"/> </Target> – Grocer

@Grocer We don't use Windows Application Packaging projects and MSBuild too during our build and publishing process, so I think our solution doesn't help you. Our application is Electron-based, and tooling is basically Node.js-based, so we just have a custom script for this. – Nodal

@Grocer btw, what do you mean by "before appinstaller file is included in the package"? We build MSIXs during CI, store them in Artifactory, and only when we are going to make a public release - we upload the new MSIX package AND generate appinstaller file on-the-fly from the template, padding it to the desired constant size. appinstaller file cannot and should not be included in MSIX. – Nodal

With Visual Studio if you include a file named Package.appinstaller into the MSIX project it will automatically use that as a template for generating the appinstaller during publish and then copies it to a specific output folder. so I was looking for a way to do the padding during this publish process. but I found a way to generate the appinstaller from CI pipeline (I'm using Azure DevOps). will use this approach and do the padding in CI as well. thanks for the tips – Grocer

Answer 3

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.

Diastase

Strange, a restart fixed this. – Mathildemathis

@LucaZiegler apparently it's something to do with cached .installer file. It doesnt make sense to me but it does work. – Diastase

Restarting/stopping the Delivery Optimization Service seems to do the trick; saves you restarting your PC. – Rick

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

Spelt