search

microsoft / WindowsAppSDK

The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.
https://docs.microsoft.com/windows/apps/windows-app-sdk/
MIT License
3.85k stars 323 forks source link

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

Open Balkoth opened 1 year ago

Balkoth commented 1 year ago

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 commented 1 year ago

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.

Screenshot 2023-07-10 185434

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.

Screenshot 2023-07-10 185515

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 commented 1 year ago

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 commented 1 year ago

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 commented 3 months ago

See #4603