microsoft
1.8 Create app bundle fails when manifest contains scaled images
Describe the bug
Using scaled visual assets in the package.appxmanifest results in the following error when trying to create a bundled app package -
The "WinAppSdkSignAppxPackageBundle" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files\Microsoft Visual Studio\18\Insiders\MSBuild\Current\Bin\amd64" directory.
This is for Winui Blank App Packaged. The exact same images worked perfectly in 1.7.
Steps to reproduce the bug
- Create new Winui Blank App Packaged with 1.8
- Create bundled package - no problem.
- Add scaled visual asset to manifest eg. SmallTile.scale-100.png.
- Create bundled package - Computer says no! Error MSB4036.
- Remove any scaled visuals and packages are again created no problem.
Expected behavior
No response
Screenshots
No response
NuGet package version
Windows App SDK 1.8.0: 1.8.250907003
Packaging type
Packaged (MSIX)
Windows version
Insider Build (xxxxx)
IDE
Other
Additional context
Windows Version 25H2 IDE VS 2026 Insider
My project also fail to Package & Publish after update to 1.8 with error: The "WinAppSdkSignAppxPackageBundle" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64" directory.
@ssparach @Scottj1s Please note that
- UapAppxPackageBuildMode = SideloadOnly works fine
- UapAppxPackageBuildMode = CI or StoreUpload cause the exception:
microsoft.windows.sdk.buildtools.msix\1.7.20250829.1\build\Microsoft.Windows.SD K.BuildTools.MSIX.Packaging.targets(2327,5): error MSB4036: The "WinAppSdkSignAppxPackageBundle" task was not found
I think this is the primary blocker from publishing Windows App SDK v1.8 and should be fixed ASAP
@ssparach @Scottj1s
I dig into the root cause it's a typo error !!!!
The only task that exists in the Microsoft.Windows.SDK.BuildTools.MSIX.Packaging.targets is WinAppSdkSignAppxPackage instead of WinAppSdkSignAppxPackageBundle
<!-- Signing -->
<UsingTask AssemblyFile="$(MsixTaskAssembly)" TaskName="$(MsixTaskAssemblyNamespace).Crypto.WinAppSdkSignAppxPackage" />
In the Target _CreateUploadResourcePackages your team use the name WinAppSdkSignAppxPackageBundle which is is totally incorrect
<Target Name="_CreateUploadResourcePackages"
Inputs="@(_AppxUploadBundleResourceFileMaps)"
Outputs="%(ResourcePack)"
Condition="'$(AppxBundleResourcePacksProducingPlatform)' == '$(PackageArchitecture)' and
'$(BuildAppxUploadPackageForUap)' == 'true' and
'$(UseAppxLayout)' != 'true'"
DependsOnTargets="_FindAppxContentGroupMap">
<WinAppSdkMakeAppxPack MakeAppxExeFullPath="$(MakeAppxExeFullPath)"
AppxContentGroupMap="$(AppxContentGroupMapFullPath)"
AppxStreamableMainPackage="$(AppxStreamableMainPackage)"
AppxStreamableResourcePackages="$(AppxStreamableResourcePackages)"
ResourcePack="true"
Parameters="$(CreateResourcePackageMakeAppxParameters)"
HashAlgorithmId="$(AppxHashAlgorithmId)"
ValidateResourcesReferencedByManifest="false"
AppxManifest="@(AppxUploadManifestForBundle)"
FileMap="%(_AppxUploadBundleResourceFileMaps.Identity)"
Output="%(_AppxUploadBundleResourceFileMaps.ResourcePack)"
VsTelemetrySession="$(VsTelemetrySession)"
IsUploadPackageOrComponent="true"
/>
<!--👇👇👇 Typo, Replace it with WinAppSdkSignAppxPackage 👇👇👇-->
<WinAppSdkSignAppxPackageBundle Condition="'$(AppxPackageSigningEnabled)' == 'true'"
AppxPackageToSign="%(_AppxUploadBundleResourceFileMaps.ResourcePack)"
CertificateThumbprint="$(PackageCertificateThumbprint)"
CertificateFile="$(PackageCertificateKeyFile)"
CertificatePassword="$(PackageCertificatePassword)"
HashAlgorithmId="$(AppxHashAlgorithmId)"
EnableSigningChecks="$(EnableSigningChecks)"
SignAppxPackageExeFullPath="$(SignAppxPackageExeFullPath)"
TempCertificateFilePath="$(TempCertificateFilePath)"
VsTelemetrySession="$(VsTelemetrySession)"
SigningTimestampServerUrl="$(AppxPackageSigningTimestampServerUrl)"
SigningTimestampDigestAlgorithm="$(AppxPackageSigningTimestampDigestAlgorithm)"
AzureCodeSigningEnabled="$(AzureCodeSigningEnabled)"
AzureCodeSigningDlibFilePath="$(AzureCodeSigningDlibFilePath)"
AzureCodeSigningEndpoint="$(AzureCodeSigningEndpoint)"
AzureCodeSigningAccountName="$(AzureCodeSigningAccountName)"
AzureCodeSigningCertificateProfileName="$(AzureCodeSigningCertificateProfileName)"
AzureKeyVaultEnabled="$(AzureKeyVaultEnabled)"
AzureKeyVaultDlibFilePath="$(AzureKeyVaultDlibFilePath)"
AzureKeyVaultUrl="$(AzureKeyVaultUrl)"
AzureKeyVaultCertificateId="$(AzureKeyVaultCertificateId)"/>
<Message Importance="high" Condition="'$(AppxPackageSigningEnabled)' == 'true'" Text="$(MSBuildProjectName) -> %(_AppxUploadBundleResourceFileMaps.ResourcePack)" />
<Message Importance="high" Condition="'$(AppxPackageSigningEnabled)' != 'true'" Text="$(MSBuildProjectName) -> %(_AppxUploadBundleResourceFileMaps.ResourcePack) (unsigned)" />
</Target>
I replace the WinAppSdkSignAppxPackageBundle with WinAppSdkSignAppxPackage and guess what? UapAppxPackageBuildMode = CI or StoreUpload works now~
What a stupid mistake. Please fire the develop who wrote the code 🙂 and the QA Tester who did not actually run a demo by him/herself for even once 🤬
Excellent catch @zhuxb711 that fixes it. I also get very frustrated when things don't work as we expect them to, but I think we need to remember to direct our anger in the appropriate direction. I don't feel we should be upset with the people working to help us and keep things maintained - but rather the board members, chair and ceo etc. of a multi trillion Dollar company, who lay off employees and disrupt teams, keeping them understaffed, making it so much harder for them to do the job properly. It used to be "Developers, Developers, Developers" now it's "Shareholders, Shareholders, Shareholders". Thanks for finding the issue and have a great day.
Excellent catch @zhuxb711 that fixes it. I also get very frustrated when things don't work as we expect them to, but I think we need to remember to direct our anger in the appropriate direction. I don't feel we should be upset with the people working to help us and keep things maintained - but rather the board members, chair and ceo etc. of a multi trillion Dollar company, who lay off employees and disrupt teams, keeping them understaffed, making it so much harder for them to do the job properly. It used to be "Developers, Developers, Developers" now it's "Shareholders, Shareholders, Shareholders". Thanks for finding the issue and have a great day.
Sorry for the anger, but it indeed a stupid mistake, they did not run the build even once, anyone who run the build process would find this error. They just release it without any testing which is unacceptable at all.
@zhuxb711 Thanks very much for reporting this, and for suggesting a workaround for the community. We'll have this fixed shortly and an updated Microsoft.Windows.SDK.BuildTools.MSIX published, which you can add an app-level reference to. We'll include that update in future WinAppSDK releases.
This is a blocker for our upcoming UWP -> WinUI migration release. @Scottj1s Do you have any ETA when fix for this issue will be released?
@zhuxb711 Thanks very much for reporting this, and for suggesting a workaround for the community. We'll have this fixed shortly and an updated Microsoft.Windows.SDK.BuildTools.MSIX published, which you can add an app-level reference to. We'll include that update in future WinAppSDK releases.
Have this fixed shortly? When will you release the new Microsoft.Windows.SDK.BuildTools.MSIX ?
@Scottj1s Microsoft.Windows.SDK.BuildTools updated 11 days ago but Microsoft.Windows.SDK.BuildTools.MSIX isn't
@zhuxb711 What and where is that file I can open to change WinAppSdkSignAppxPackageBundle to WinAppSdkSignAppxPackage?
@zhuxb711 What and where is that file I can open to change WinAppSdkSignAppxPackageBundle to WinAppSdkSignAppxPackage?
You could use the Github Action Script for workaround
# Must restore nuget first otherwise we would not be able to find the path of `microsoft.windows.sdk.buildtools.msix` in the next step
- name: Restore Nuget Packages
shell: pwsh
run: |
msbuild "<Your Solution Path>" `
/nr:false `
/restore `
/p:RestorePackagesConfig=true `
/p:PreferredToolArchitecture="x64"
- name: Patch Code For WindowsAppSDK#5820
shell: pwsh
run: |
$NuGetPackagesPath = $env:NUGET_PACKAGES ? $env:NUGET_PACKAGES : $env:USERPROFILE ? (Join-Path $env:USERPROFILE ".nuget/packages") : (Join-Path $env:HOME ".nuget/packages")
$TargetFilePath = Join-Path $NuGetPackagesPath "microsoft.windows.sdk.buildtools.msix/1.7.20250829.1/build/Microsoft.Windows.SDK.BuildTools.MSIX.Packaging.targets"
if (Test-Path -Path $TargetFilePath) {
$FileContent = Get-Content -Path $TargetFilePath -Raw -Encoding UTF8
$ModifiedContent = $FileContent -Replace 'WinAppSdkSignAppxPackageBundle', 'WinAppSdkSignAppxPackage'
if ($FileContent -eq $ModifiedContent) {
Write-Host "No changes made. The target string was not found."
Write-Host "Skipping code patching."
} else {
Set-Content -Path $TargetFilePath -Value $ModifiedContent -Encoding UTF8 -NoNewline
Write-Host "Successfully replaced 'WinAppSdkSignAppxPackageBundle' with 'WinAppSdkSignAppxPackage'"
Write-Host "File saved: $TargetFilePath"
}
} else {
Write-Host "File not found: $TargetFilePath"
Write-Host "Skipping code patching."
}
# Build your project again with MSBuild as normal in the next step
Interesting, I just updated to WindowsAppSDK 1.8.251003001 yesterday in my app and saw the same error message when creating app packages for the Microsoft Store using Visual Studio. However, the build output was still created, and I was able to load those packages into App Center last night and see my updated app in the Store today. The error is seemingly erroneous in my case.
The "WinAppSdkSignAppxPackageBundle" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64" directory.
@zhuxb711 Thanks very much for reporting this, and for suggesting a workaround for the community. We'll have this fixed shortly and an updated Microsoft.Windows.SDK.BuildTools.MSIX published, which you can add an app-level reference to. We'll include that update in future WinAppSDK releases.
Have this fixed shortly --> Microsoft.Windows.SDK.BuildTools.MSIX still not being updated for 3 months.