Removing EnableMsixTooling from project file for unpackaged applications produces crashing published app

[Balkoth]

Describe the bug

From my observations EnableMsixTooling is responsible for renaming the pri file from [ProjectName].pri to resources.pri. If EnableMsixTooling is ommited because it is not needed for unpackaged applictations and such an application is then published from the Visual Studio wizard, the [ProjectName].pri file is not copied to the publish directory.

Steps to reproduce the bug

1. Create a new application
2. Set <WindowsPackageType>None</WindowsPackageType>
3. Remove EnableMsixTooling
4. Publish the application with the Visual Studio wizard

Expected behavior

The pri-resource-file should be copied in every possible case, as not copying it produces a non runnable crashing output.

Screenshots

No response

NuGet package version

Windows App SDK 1.3.2: 1.3.230602002

Packaging type

Unpackaged

Windows version

Windows 10 version 22H2 (19045, 2022 Update)

IDE

Visual Studio 2022

Additional context

No response

[DarranRowe]

Before I comment, I want to point out that I agree with this report. This has been one of my biggest annoyances for a long time. The process of providing the .pri file may not be a simple renaming and copy. If you query MRT core for the default paths, you will notice something interesting.

This is from an application packaged with a separate packaging project. The first is the path that Microsoft.ApplicationModel.Resources.ResourceLoader.GetDefaultResourceFilePath returns for the executable. The second is the path it returns for a component that the application references. Both of these are resources.pri. The package resources themselves also get merged into resources.pri. It is almost the same for unpackaged projects.

The biggest thing to note here is that the executable and the component default to looking for "executablename".pri.

This means that the project may need to merge all .pri files from referenced projects too.

[Balkoth]

This is a really nasty bug, which i got around once i noticed it, by copying the pri file manually from the Release to the Publish folder. This was done because I had no time to investigate further and was not sure if i am doing something wrong.

I really hope this gets fixed soon.

[Psychlist1972]

Hi Team

Any update on this?

There are other issues as well. If you omit EnableMsixTooling from the project, or you set it to false (as you mention), you can't use a dotnet command-line or any other type of automated build because the process which generates the pri doesn't run at all. That's better than a runtime failure, but not by much.

Of course, without the pri file, the app launches but, at least in my case, never shows UI.

The other annoyance with all this is that the pri file is unknown to dotnet publish, so you have to manually copy it as a completely separate post-build step, making a mess of any sort of automated build process.

[Balkoth]

See #4603

[Balkoth]

Why are now both issues closed without a resolution?

[riverar]

Just helped another user with this, so adding a comment to bump it.

@beth-panx @michael-hawker This might be a good candidate for inclusion in the new world order.