The attribute 'Version' with value '00.9' failed to parse. 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: '00.9' violates pattern constraint of To add to the answer by the max version number I managed to build and install was 65535.65535.65535.9 That's why the appinstaller files are more likely victims of this problem. If the URL changes, DoSvc HTTP client logic handles it as a different resource. The problem turns up if requests are performed to the same URL. You can check our current production appinstaller we use since April, 2021: We have even made a simple size test in our gitlab deployment pipeline to ensure that size of appinstaller was not accidentally changed. 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. 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ĭo 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. If your appinstaller file size decreases, it's likely that you will get 416 Range Not Satisfiable. Even if ETag is handled correctly and has been changed for the appinstaller HTTP resource! User-Agent: Microsoft-Delivery-Optimization/10.0īut 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. See below for the workaround.ĭelivery 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.įor example, if your appinstaller is 725 bytes long, first time Windows DO Service makes a well-formed HTTP request and downloads the whole XML. Well, after three days of hopeless debugging and several attempts to find the root of this problem, we finally figured it out.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |