What is Microsoft.Windows.SDK.BuildTools.MSIX?

[riverar]

Snigdha noted on the WinUI call that this NuGet Package will be the only way to perform MSIX packaging in the near future. This is the first time I've heard of this NuGet package and am requesting more information.

• Who owns this?
• Will WinAppSdk support this NuGet package?
• Are there any docs on what this NuGet is meant to provide, how to use/configure it, etc.?
• Does it aim to cover all the existing MSIX packaging scenarios?
  • For example:
    • Does it support running on and off CI?
    • Is it a replacement for the Windows Application Packaging project?
    • Does it support publish profiles?
    • Does it support multiple target architectures?
    • Will use of the NuGet force a rebuild like the Packaging Project did?

Be aware, the license for this NuGet is incomplete/contains errors, such as, but not limited to:

        i.  **Windows App Requirements.** If you intend to make your
            program available in the Windows Store, the program must
            comply with the Certification Requirements as defined and
            described in the App Developer Agreement, currently
            available at: .

[riverar]

As of December 2024, it appears this NuGet is completely untested outside of WinUI 3 / WinAppSDK. We use the functionality that is going away in our non-WinAppSdk/non-WinUI 3 app today--are we doomed or?

[ghost1372]

@riverar
https://x.com/SergioPedri/status/1877389779718779359?t=IbOICxroT_G-lXKNrndW-A&s=19

[Sergio0694]

I can add context for this. This package contains all the single-project MSIX tooling that WindowsAppSDK includes (MSIX packaging, MRT Core stuff, etc.). We decoupled all of that for two main reasons: make it easier to service and decoupled from WindowsAppSDK, and also so that UWP .NET 9 projects could also leverage it easily (UWP .NET 9 has a dependency on this package).

All the new improvements for the single-project MSIX tooling are going into this package (eg. MSIX bundle support, improved .winmd harvesting for .NET projects, more .appxmanifest rewriting options, etc.). We do plan to eventually switch WindowsAppSDK to having a package dependency on this, we just haven't had a chance to do that yet, but it's definitely planned 🙂

We don't have a centralized place for docs on this package, though that's not a bad idea. There's a bunch of properties and configuration options we're adding that right now aren't documented anywhere, which isn't really great. For instance, we added support for the WindowsMetadataReference items to specify .winmd-s to harvest, and we updated Win2D and other packages to include this element in their .props, but we don't have any official documentation on what this is just yet.

[riverar]

Thanks @Sergio0694 that helps.

I'm still very confused and concerned about Snigdha's comments, where she says:

In future releases... in upcoming releases in Feb 2025 we will be supporting MSIX bundle through this NuGet only [...]

That seems like a very aggressive timeline for transition to a NuGet that has zero documentation and no clear migration plan for existing Windows Application Packaging Project developers.

Happy to jump on a call or walk across the street (I live by Microsoft One Esterra) to chat further.

[Sergio0694]

"in upcoming releases in Feb 2025 we will be supporting MSIX bundle through this NuGet only"

She'd need to confirm (is she on GitHub?), but I imagine what she meant is that we'll add support for MSIX bundles in February only to this NuGet package, as in, as opposed to being available through WindowsAppSDK. Actually I'm pretty sure the latest version (1.2.20250107.1) already has support for MSIX bundles (it's .msixupload bundles that are missing for now). We do plan on releasing a new version of this package in February (there's also other improvements I've been working on that I'd like to make publicly available), but like she said, this is only going to be available through the NuGet package, not in WindowsAppSDK.

I'm not entirely sure you can explicitly reference this package while using WindowsAppSDK 1.7 or lower. Because a lot of the same logic would be duplicated in .props/.targets that are embedded in WindowsAppSDK, I'd expect that to not work at all.

The switch to this package in WindowsAppSDK should be in 1.8 (ideally it should be there starting with 1.8-experimental1).

[riverar]

Ping @snigdha011997

[riverar]

No word from @snigdha011997; disappointed.

I spoke to @Sergio0694 some more and he beat into me clarified it quite nicely:

• The new MSIX package was created to decouple packaging from WASDK, primarily to support UWP and enable easier updates.
• Support for all other project types (WinForms, WPF, etc.) is planned/inevitable.
• The WASDK team is working on adding MSIX bundle and .msixupload support for WASDK 1.8.
• There are no plans to deprecate WAP; confusion arose from Snigdha’s statement about MSIX bundles being supported via the NuGet package in WASDK 1.8.

[snigdha011997]

Hi @riverar
Thanks for your interest in using Microsoft.Windows.SDK.BuildTools.MSIX for packaging your application. The context was about supporting MSIX Bundles for WinUI Single Packaging Project applications
As @Sergio0694 mentioned, the latest version (1.2.20250107.1) already supports MSIX bundles. Hopefully, starting in February, we will be adding support for MSIX uploads via NuGet.

Also, regarding your concern, there are no plans to deprecate WAP. I see @Sergio0694 has already responded to remaining queries.

Let me know if you need further clarification!

[MUJaCHe66]

Hi
This was shown as working during the last Winui Community Call. When I try, it fails to build, even with the latest experimental appskd and a new blank project. The nuget package doesn't list any prerequisites but am I missing something.
This is the error -
The "Microsoft.Build.Msix.Recipe.WinAppSdkMatchItemsByFileNameOnMetadataValue" task could not be loaded from the assembly C:\Users\user.nuget\packages\microsoft.windowsappsdk\1.6.250108002\buildTransitive..\tools\net472\Microsoft.Build.Msix.dll. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

[Sergio0694]

No need to file an issue, that's by design. I added that new task in the MSIX nuget package, but if you add that when also referencing WinAppSDK, VS will load the build task .dll from WinAppSDK instead, which doesn't have the new task. This is expected: like we said, WinAppSDK is not compatible with the MSIX nuget package yet. We plan on doing that work in WinAppSDK 1.8 🙂

[MUJaCHe66]

OK Thanks for the clarification.