Is APPXUPLOAD-bundle creation of a packaged WinUI3 app supported by 1.7.x ?!

[kroestau]

Bundle creation always ends with a test folder content (including a MSIX-file) but no APPXUPLOAD-file. The MSIX-file is for testing only and runs only in administrator mode if submitted.

I was searching months before for a solution to upload a store app project bundle. At last I was forced to create a bundle via an unpackaged WinUI3 project, which brings some downsides with it.

Now I finshed another app project and nothing has changed. The needed store submission package creation is not happening.

You can easily reproduce by:
1 Create an empty packaged WinUI3 project.
2 Associate it to the store.
3 Start the bundle creation by VS2022.
4 Check the output folder.

Today I have read, that package generation for a packaged project is unsupported pre-1.8.x:
#3110 (comment)

Simple question: Is APPXUPLOAD-bundle creation of a packaged WinUI3 app w/o extra package project even supported by the latest stable 1.7.250606001 ?!

[DarranRowe]

One thing that I will point out, the .appxupload/.msixupload file isn't something special. As documented by Packaging MSIX apps, the store submission file is a .zip file that contains the following:

1. The .appx/.msix files, or the .appxbundle/.msixbundle files.
2. The .appxsym/.msixsym files for each package. These themselves are just the .pdb files compressed into a .zip file with the extension changed.

Then the extension is just changed to .appxupload or .msixupload. So you shouldn't have to do anything weird using another package project.

[ghost1372]

WinAppSDK: planned, not supported yet (will be in WinAppSDK 1.8)

#5061 (comment)

[kroestau]

As for me for building a store package the two projects solution is the best for now and it works perfectly (SDK 1.7.250606001).
What I cannot understand is that developers are pushed on the one project path w/o differentiation. It may be appropriate for certain scenarios, but definitely not for store packaging.