MSIX support apparently cannot now be disabled on .NET Core

[wjk]

Describe the bug

#5228 forces MSIX tooling to be enabled when .NET CLI is being used. While the objective of this was to avoid problems with the legacy PRI tooling, it also prevents the user from developing an AppSDK program that is not in an MSIX package. Except if deploying to the Windows Store, MSIX packages are still completely unusable in real-world situations, mostly due to the requirement that they be signed with a commercial certificate (which is unreasonably expensive and requires that the developer create a corporation first). Besides, one of the big draws of WinUI 3 was that it no longer requires MSIX to function. Unless I am mistaken about the behavior of this switch (which is entirely possible, as I am not that familiar with this codebase), this needs to be fixed.

Steps to reproduce the bug

1. Create a WindowsAppSDK project that builds using .NET Core.
2. Observe that MSIX is now required.

Expected behavior

Instead of creating this patch, the MRT Core tooling should be divorced from the rest of the WinUI build tooling so that you can use the CLI-compatible targets without also requiring the use of MSIX. I would submit a PR to do this myself except that the targets are still proprietary. 😒

Screenshots

No response

NuGet package version

None

Packaging type

No response

Windows version

No response

IDE

No response

Additional context

I am not developing an app using WindowsAppSDK currently, so none of the versioning questions apply. I noticed this issue while browsing recently merged GitHub PRs.

[kythant]

Hi William.

As we will not be moving forward with this fix to enable MSIXTooling by default on DotNetCLI.
Instead, we will be doing a proper fix in the MRTCore PRI Gen targets to use the same assemblies MSIX tooling was using so we don't have to enable MSIXTooling when using DotNet CLI.