Partner Center reporting a bug for latest version of BuildTools

[DRAirey1]

Describe the bug

I have an application that builds, runs and passes all validation tests locally, but when I submit it to the store, I get:

Package acceptance validation error: The package Desktop (Package)_1.35.14.0_x86_Production.msix uses an unsupported version of file makepri.exe (10.0.26100.1). The following versions are allowed: < 10.0.10500.0; >= 10.0.10586.0 & < 10.0.11000.0; >= 10.0.14383.0 & < 10.0.14800.0; >= 10.0.15053.0 & < 10.0.15100.0; >= 10.0.16299.0 & < 10.0.16350.0; >= 10.0.17134.0 & < 10.0.17500.0; >= 10.0.17763.0 & < 10.0.18199.0; >= 10.0.18362.0 & < 10.0.18799.0; >= 10.0.19041.0 & < 10.0.19399.0; >= 10.0.20348.0 & < 10.0.21242.0; >= 10.0.22000.194 & < 10.0.22350.0; >= 10.0.22621.0 & < 10.0.25054.0. Please update your Visual Studio build tools and try again.
Package acceptance validation error: The package Desktop (Package)_1.35.14.0_x64_Production.msix uses an unsupported version of file makepri.exe (10.0.26100.1). The following versions are allowed: < 10.0.10500.0; >= 10.0.10586.0 & < 10.0.11000.0; >= 10.0.14383.0 & < 10.0.14800.0; >= 10.0.15053.0 & < 10.0.15100.0; >= 10.0.16299.0 & < 10.0.16350.0; >= 10.0.17134.0 & < 10.0.17500.0; >= 10.0.17763.0 & < 10.0.18199.0; >= 10.0.18362.0 & < 10.0.18799.0; >= 10.0.19041.0 & < 10.0.19399.0; >= 10.0.20348.0 & < 10.0.21242.0; >= 10.0.22000.194 & < 10.0.22350.0; >= 10.0.22621.0 & < 10.0.25054.0. Please update your Visual Studio build tools and try again.
Package acceptance validation error: The package Desktop (Package)_1.35.14.0_ARM64_Production.msix uses an unsupported version of file makepri.exe (10.0.26100.1). The following versions are allowed: < 10.0.10500.0; >= 10.0.10586.0 & < 10.0.11000.0; >= 10.0.14383.0 & < 10.0.14800.0; >= 10.0.15053.0 & < 10.0.15100.0; >= 10.0.16299.0 & < 10.0.16350.0; >= 10.0.17134.0 & < 10.0.17500.0; >= 10.0.17763.0 & < 10.0.18199.0; >= 10.0.18362.0 & < 10.0.18799.0; >= 10.0.19041.0 & < 10.0.19399.0; >= 10.0.20348.0 & < 10.0.21242.0; >= 10.0.22000.194 & < 10.0.22350.0; >= 10.0.22621.0 & < 10.0.25054.0. Please update your Visual Studio build tools and try again.

Steps to reproduce the bug

1. Install the latest version of SDK BuildTools in your WinUI project.
   

2. Update to the latest version of Visual Studio.

3. Build your application.

4. Submit it to the Windows Store.

Expected behavior

I expect the application to pass the validation tests.

Screenshots

NuGet package version

None

Packaging type

Packaged (MSIX)

Windows version

No response

IDE

Visual Studio 2022

Additional context

No response

[myokeeh]

Seeing this too

[myokeeh]

To clarify, the app I tried submitted is a UWP app. I think the Partner Center isn't ready for 10.0.26100 yet.

[shyamshr93]

facing the same issue. any update on this ?

[gagansuie]

Same issue here as well. Reverting back to this version in the mean time.

<PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.22621.3233" />

[Armorost]

uninstall "Microsoft.Windows.SDK.BuildTools" from the app Packages seems to remove the pb to me

[ritesh3103]

The version 10.0.26100.1 was updated on May 22, 2024 and after a month or more, Microsoft Partner Center is not ready for it. Reverting back to the version 10.0.22621.3233 solved the issue.

[jbe2277]

Any updates regarding this issue?

[Rarisma]

I am experiencing this too.

[zhuxb711]

Same here. Only way to solve this is downgrade the BuildTools.

[MartinZikmund]

Also just hit this problem, but have no workaround, as some of my dependencies already bumped to latest stable as well

[matthewacme]

Aug 14th and I'm still seeing this

[IsmailHassani]

Same here

[Sevael]

:( Same here

[SolidRockProgrammer]

Same here, we can't deploy our latest version UNO app, and we can't down grade.

[MartinZikmund]

@SolidRockProgrammer if you don't mind using older version of Uno.Extensions, you can use the following in Directory.Build.Props:

<!-- Temporary workaround for https://github.com/microsoft/WindowsAppSDK/issues/4480 -->
<WinAppSdkBuildToolsVersion Condition="$(TargetFramework.Contains('windows10'))">10.0.22621.3233</WinAppSdkBuildToolsVersion>
<UnoExtensionsVersion Condition="$(TargetFramework.Contains('windows10'))">4.2.2</UnoExtensionsVersion>

This is, of course, just a workaround, and the issue itself needs to be resolved

[PIN0L33KZ]

Is that really STILL a thing??

Got the following error: Package acceptance validation error: The package Packaging Project_2.2.1.0_x86.appx uses an unsupported version of file makepri.exe (10.0.26100.1). The following versions are allowed: < 10.0.10500.0; >= 10.0.10586.0 & < 10.0.11000.0; >= 10.0.14383.0 & < 10.0.14800.0; >= 10.0.15053.0 & < 10.0.15100.0; >= 10.0.16299.0 & < 10.0.16350.0; >= 10.0.17134.0 & < 10.0.17500.0; >= 10.0.17763.0 & < 10.0.18199.0; >= 10.0.18362.0 & < 10.0.18799.0; >= 10.0.19041.0 & < 10.0.19399.0; >= 10.0.20348.0 & < 10.0.21242.0; >= 10.0.22000.194 & < 10.0.22350.0; >= 10.0.22621.0 & < 10.0.25054.0. Please update your Visual Studio build tools and try again.

[MartinZikmund]

CC @Sergio0694 @dpaulino - do you have a point of contact for this at Partner Center team that could help please?

[Sergio0694]

I'd suggest pinging ankur06 in the microsoft-store channel on Discord (https://aka.ms/microsoftstorediscord).
He's the PM for Partner Center working on the submission pipeline, he might be able to help.
As far as I know though this is just a matter of the pipeline not having been updated yet, so it likely just needs time.
Keep in mind that 26100 isn't even out yet (the SDK is stable, but Windows 26100 isn't available yet in GA).

[under3415]

myokeeh has pinged ankur06 in microsoft-store Discord channel 👍

[KevinLaMS]

Hey, @DRAirey1 I am newly joining the team and will take a look at this? Thanks!

[BrianDT]

Microsoft have requested an update to one of my apps and will delist the app at the end of the September if a new version has not been published by then. This issue is a major inconvenience.

[DCorrBECare]

Is there any news regarding this problem?

[myokeeh]

@KevinLaMS, slightly off topic: I have some devices that are already on 10.0.26100 and I'm noticing a pattern that those devices are not getting automatic updates for UWP apps that I have in the Store with new updates. TargetPlatformVersion is 10.0.22621.0 and TargetPlatformMinVersion is 10.0.19041.0 for those apps. They are LOB apps.

I assumed insider builds would get apps automatically updated since they're always going to be higher than the TargetPlatformVersion. What's preventing automatic updates?

[DRAirey1]

I think I finally fixed this. I got rid of all the package references to Microsoft.WindowsAppSDK and Microsoft.Windows.SDK.BuildTools in all my .csproj files. That is, I deleted this line wherever I found it:

<PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.22621.3233" />

IMPORTANT NOTE: You need to do this to all the packages you consume as well. I had a package of WinUI resources (controls, formatters, etc.), that was still referencing the SDK.BuildTools. It wasn't until I removed the ALL the references in every package that I imported that I was able to successfully upload to the Microsoft Partner Center with the latest version of everything.

[matthewacme]

@DRAirey1
Hey David,

I'm successfully submitting a WinUI app with

<TargetFramework>net8.0-windows10.0.22621.0</TargetFramework>
<TargetPlatformMinVersion>10.0.19044.0</TargetPlatformMinVersion>

and

<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.5.240802000" />
<PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.22621.3233" />

in all the packages.

Any upgrade from those libraries however and I get the "not supported" error.

I'm using 1.5.240802000 for the WAS and you are 1.5.240428000 for your WAS

I don't know if that is any help to you.

[myokeeh]

@KevinLaMS I made another attempt to submit for version 26100 thinking this would be fixed now that 24H2 is GA. No luck.

[IsmailHassani]

@KevinLaMS I made another attempt to submit for version 26100 thinking this would be fixed now that 24H2 is GA. No luck.

I'm wondering what the issue could be. Any chance you can share your csproj file and the pipeline yaml file?

[under3415]

The issue seems quite simple. When store validates the package, it does not recognize the new SDK. Probably just needs a config update, but this is very low on Microsoft backlog. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Ismail Hassani ***@***.***> Sent: Wednesday, October 2, 2024 11:07:46 PM To: microsoft/WindowsAppSDK ***@***.***> Cc: under3415 ***@***.***>; Mention ***@***.***> Subject: Re: [microsoft/WindowsAppSDK] Partner Center reporting a bug for latest version of BuildTools (Issue #4480) @KevinLaMS<https://github.com/KevinLaMS> I made another attempt to submit for version 26100 thinking this would be fixed now that 24H2 is GA. No luck. I'm wondering what the issue could be. Any chance you can share your csproj file and the pipeline yaml file? — Reply to this email directly, view it on GitHub<#4480 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA5N3HWYVMWREBKWPMYOMPLZZPAXFAVCNFSM6AAAAABI6RUFFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBYGIZTANRYHA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[myokeeh]

I agree with @under3415. It's on the Partner Center side. What's frustrating is this is not the first time this happened. I don't know why the lesson hasn't been learned. Almost every time there's a new SDK version, they fumble here.

[under3415]

Someone needs to tell them this is affecting AI and it will get fixed in 10 minutes :-D

[frogcrush]

Still an issue, can't downgrade due to Uno and even other Microsoft packages using the newer version of the SDK.

[zhuxb711]

You guys still not fix this issue even 24H2 released already

[applefanbois]

What a shameful disgusting disgrace.
Don't you have any self respect Microsoft?

Steve Balmer loved the developers and treated us like kings.
Now we are treated like trash.
Don't you realize that if we don't make app for Windows, you will disappear?

[michalleptuch]

If you don't want to downgrade the package, you can always modify the final manifest:

[under3415]

Hi, @michalleptuch
I tried your MSIX Packaging Tool workaround but am getting this error:

Package acceptance validation error: APPX_E_INVALID_BLOCKMAP - The package's block map is invalid. The package must be created with a valid app packager.

This is what I tried:

1. Installed "MSIX Packaging Tool" from Windows app store
2. Unzipped my .msixupload file
3. Unzipped my .msixbundle file
4. Used "MSIX Packaging Tool" to modify manifests in 3 msix files (x86, x64 and arm64) to set makepri.exe version to 10.0.25053.0 which is acceptable to the store. I saved the msix files as new files, then replaced the existing files with modified versions.
5. Zipped the files into a new .msixbundle file using 7zip
6. Zipped the files into a new .msixupload file using 7zip
7. Submitted to the store

I suspect I should not have used 7zip to create bundles in steps 5 & 6, but not sure how to use "MSIX Packaging Tool" to (re)create a bundle.

[michalleptuch]

Hi @under3415, unfortunately I didn't test it on msixbundle, sorry for the oversight :(

[frogcrush]

I think I finally figured out a workaround.

$sourceDirectory = "C:\temp\output"
$newFolder = "C:\temp\appxbundles"

# cleanup old stuff
Remove-Item -Path $sourceDirectory -Recurse
Remove-Item -Path $newFolder -Recurse

# Define the MSBuild command for x64 platform
$msbuildCommand_x64 = "msbuild ParaMeter/ParaMeter.csproj /r /p:TargetFramework=net8.0-windows10.0.22621 /p:Configuration=Release /p:Platform=x64 /p:GenerateAppxPackageOnBuild=true /p:AppxBundle=Never /p:UapAppxPackageBuildMode=StoreUpload /p:AppxPackageDir=""C:/temp/output/"" /p:AppxPackageSigningEnabled=true"

# Define the MSBuild command for x86 platform
$msbuildCommand_x86 = "msbuild ParaMeter/ParaMeter.csproj /r /p:TargetFramework=net8.0-windows10.0.22621 /p:Configuration=Release /p:Platform=x86 /p:GenerateAppxPackageOnBuild=true /p:AppxBundle=Never /p:UapAppxPackageBuildMode=StoreUpload /p:AppxPackageDir=""C:/temp/output/"" /p:AppxPackageSigningEnabled=true"

# Execute the MSBuild command for x64 platform
Invoke-Expression -ErrorAction Stop -Command $msbuildCommand_x64

# Execute the MSBuild command for x86 platform
Invoke-Expression -ErrorAction Stop -Command $msbuildCommand_x86

# Define the source directory and the new folder where MSIX files will be copied

# Get the newest directory in the source directory
$newestDirectory = Get-ChildItem -Path $sourceDirectory -Directory | Sort-Object LastWriteTime -Descending | Select-Object -First 1

# Check if any directories are found
if (!$newestDirectory) {
    Write-Host "No directories found in the source folder."
    exit
}

# Get the name of the newest directory
$directoryName = $newestDirectory.Name

# Extract the version number from the directory name
$versionNumber = $directoryName -match "(\d+(\.\d+)+)"

# Check if version number is extracted successfully
if ($versionNumber) {
    $versionNumber = $matches[0]
    Write-Host "Version number extracted: $versionNumber"
} else {
    Write-Host "Version number not found in the directory name."
    exit
}

# Check if the source directory exists
if (!(Test-Path $sourceDirectory)) {
    Write-Host "Source directory not found."
    exit
}

# Check if the new folder exists, if not, create it
if (!(Test-Path $newFolder)) {
    New-Item -Path $newFolder -ItemType Directory | Out-Null
}

$x86path = Join-Path -Path $sourceDirectory -ChildPath "ParaMeter_${versionNumber}_x86_Test"
$x64path = Join-Path -Path $sourceDirectory -ChildPath "ParaMeter_${versionNumber}_x64_Test"

# Copy MSIX files to the new folder
$msixFiles = Get-ChildItem -Path $x86path -Filter "*.msix"
foreach ($file in $msixFiles) {
    $destination = Join-Path -Path $newFolder -ChildPath $file.Name
    Copy-Item -Path $file.FullName -Destination $destination -Force
    Write-Host "Copied $($file.Name) to $($newFolder)"
}

Write-Host "MSIX files copied successfully to $($newFolder)"

# Copy MSIX files to the new folder
$msixFiles = Get-ChildItem -Path $x64path -Filter "*.msix"
foreach ($file in $msixFiles) {
    $destination = Join-Path -Path $newFolder -ChildPath $file.Name
    Copy-Item -Path $file.FullName -Destination $destination -Force
    Write-Host "Copied $($file.Name) to $($newFolder)"
}

Write-Host "MSIX files copied successfully to $($newFolder)"

Read-Host -Prompt "Press Enter after editing the MSIX packages to fix Microsoft's mistake...'"

# Define the path to makeappx.exe
$makeAppxPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\makeappx.exe"

# Define the input directory and bundle path for makeappx command
$inputDirectory = $newFolder
$bundlePath = Join-Path -Path $newFolder -ChildPath "$versionNumber.msixbundle"

# Execute makeappx command to create the MSIX bundle
$makeAppxCommand = "& '$makeAppxPath' bundle /d ""$inputDirectory"" /p ""$bundlePath"""

Write-Host "Going to execute $makeAppxCommand"

Invoke-Expression -Command $makeAppxCommand

Write-Host "MSIX bundle created successfully at: $bundlePath"

Essentially this script generates x86 and x64 packages and then prompts you to edit them with MSIX Packaging Tool. You can set the version to 10.0.22621.0 which as of right now seems to be the last supported version on Partner Center. Once you hit enter to continue it will generate a bundle for you as well.

I'm not a PowerShell scripter so please adapt as necessary aha

[DrusTheAxe]

• Used "MSIX Packaging Tool" to modify manifests in 3 msix files (x86, x64 and arm64) to set makepri.exe version to 10.0.25053.0 which is acceptable to the store. I saved the msix files as new files, then replaced the existing files with modified versions.
• Zipped the files into a new .msixbundle file using 7zip
• Zipped the files into a new .msixupload file using 7zip

You modified package content, than created the package archive without a matching appxblockmap.xml or tools that create such.

A .msix and .msixbundle are not merely a .zip file. They have additional rules beyond there mere .zip file format, e.g. a signed package contains the file appxblockmap.xml which lists all files in the package and hashes, used to verify the package content matches the expected content (this happens when content's extracted from a .msix[bundle] and post-install if/when validation is needed e.g. Package.VerifyContentIntegrityAsync().

One does not simply walk into Mordor create ZIP file named .msix. There's more to it. The simplest way to create a (valid) .msix[bundle] is via makeappx.exe. There's other options but nowhere as simple e.g. use the PackageWriter API to create the .msix[bundle]).

P.S. To make a signed MSIX package you typically run makeappx.exe then signtool.exe which does yet more stuff beyond writing a mere .zip file (e.g. signing info's injected into the .zip file at a very specific location). You can find more info about makeappx.exe and signtool.exe across the net, for example WinAppSDK construction uses MakeMsix.targets to create signed test packages for various test cases; mostly that's MSBuild goo but if you jump towards the end the <Exec> commands at lines 72 and 84 and their preceding properties/macros are one example how to use makeappx.exe and signtool.exe to create signed MSIX packaged.

[vincentlaucsb]

Encountering this issue as well. It's doubly frustrating because the suggested guidance is wrong. We don't need to upgrade our build tools. In fact, we should downgrade them.

[shinta0806]

I have encountered the same phenomenon.
Visual Studio 17.12.0 / Windows App SDK 1.6.241114003 (1.6.3) / .NET 9

[matthewacme]

Hello Folks.
So we finally managed to figure out a work-around that allows us to build our WinUI project with all of the latest tools and still submit to the MS store and get past this error.

This is not an automated process for us, and it may not be exhaustive for you folks, but this is how we got around it:

• We build just the separate MSIX files from the Store package building system in VS
• Then we manually modify the individual manifest files in the separate MSIX files using the MSIX Packaging Tool from MS
• Then we use the CLI of makeappx.exe, located at C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x86 to then build the combined .msixbundle that we then submit to the store.

Full instructions are at

XSGeek Microsoft Store Hack Instructions

[under3415]

I'm starting to think Microsoft does not want us in their app store :-(

[MartinZikmund]

It seems to be working now!

Tried uploading my app with latest Build Tools and it got validated, can someone else confirm as well?

[shinta0806]

Thanks for the information.
I just tried and I was able to upload .msixupload.
Visual Studio 17.12.2 / WinUI desktop app / Windows App SDK 1.6.241114003 (1.6.3) / BuildTools 10.0.26100.1742 / .NET 9

[under3415]

I was able to submit my UWP app targeting 10.0.26100 and pass validation step! Yay, they fixed it!

[Mikozans]

Thanks for the information. I just tried and I was able to upload .msixupload. Visual Studio 17.12.2 / WinUI desktop app / Windows App SDK 1.6.241114003 (1.6.3) / BuildTools 10.0.26100.1742 / .NET 9

Same config here and it also worked.

[MartinZikmund]

@DRAirey1 I think this can be closed now