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