Upgrading to v1.8 breaks ResourceLoader in unpackaged apps

[qiutongMS]

Describe the bug

When updating from v1.7 to v1.8 my app (DLSS Swapper) no longer launches. Constructing Windows.ApplicationModel.Resources.ResourceLoader causes the app to crash. There is a repro linked below.

The error appears to come from WinRT.Runtime.dll and is

System.IO.FileNotFoundException: Unable to find the specified file.

The full stacktrace is,

at WinRT.ExceptionHelpers.g__Throw|38_0(Int32 hr)
at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32 hr)
at ABI.WinRT.Interop.IActivationFactoryMethods.ActivateInstanceUnsafe(IObjectReference objectReference, Guid iid)
at Windows.ApplicationModel.Resources.ResourceLoader..ctor()
at ResourceLoaderTest.MainWindow.Grid_Loaded(Object sender, RoutedEventArgs e) in D:\git\beeradmoore\WindowsAppSDK_ResourceLoaderIssue\ResourceLoaderTest\ResourceLoaderTest\MainWindow.xaml.cs:line 37

I was not able to reproduce the issue in a packaged app.

Comparing the files in bin between the two I notice that v1.7 produces resources.pri whereas v1.8 produces ResourceLoaderTest.pri. If I put the app config in its broken state and confirm it does not work as intended, but then copy/paste ResourceLoaderTest.pri to resources.pri it will now work as expected.

Steps to reproduce the bug

See the project in this repo: https://github.com/beeradmoore/WindowsAppSDK_ResourceLoaderIssue

1. Run the project in debug mode (runs as unpackaged by default).
2. Observe that the first Debugger.Break(); is hit indicating ResourceLoader constructed
3. Update nuget package from 1.7.250606001 to 1.8.250907003
4. Run the project again and now observe you hit the Debugger.Break(); in the catch statement.

Expected behavior

The first Debugger.Break(); is hit in both cases.

Screenshots

No response

NuGet package version

Windows App SDK 1.8.0: 1.8.250907003

Packaging type

Unpackaged

Windows version

Windows 11 version 24H2 (26100, June 2025 Update)

IDE

Visual Studio 2022

Additional context

No response

[qiutongMS]

This looks like it is a long running issue with the single project packaging tools. When the project that has been set to unpackaged has EnableMsixTooling in the project file, 1.7 and older just produced resources.pri. But if you remove EnableMsixTooling or even started from the WinUI Blank App (Packaged with Windows Application Packaging Project), or any older iterations of this, then it would alwas produce <executable_name>.pri.

[qiutongMS]

Yep, I can confirm setting EnableMsixTooling to false or removing it completly results in the same crash because the pri is <executable_name>.pri in v1.7. In v1.8 the pri is always <executable_name>.pri no matter what this setting is.

There are some comments here about MrmGetFilePathFromName which may be related. But the comments also seem to make it sound like it looks for [modulename].pri and then resources.pri if it is not found.

I am unsure if the code is broken here, or if this is just not part of this execution path for the exception we are seeing and the code that is running is still specifically looking for resources.pri.

[qiutongMS]

The problem with MrmGetFilePathFromName should be unrelated, since this is part of MRT Core. Windows.ApplicationModel.Resources.ResourceLoader, AKA MRT, is a completely separate component not tied to the Windows App SDK and MRT Core. In this case, MRT (not MRT Core) was designed exclusively for UWP applications, which should always be packaged. This means that resources.pri is a safe bet since it should always be made as part of the packaging process. MRT Core took unpackaged desktop applications into account and so it started looking for [modulename].pri first, but this was not back ported to MRT.

In the end, we still need confirmation as to whether the older single project packaging tools producing resources.pri when the project was set to unpackaged was a bug. If it was, then an unpackaged application should have always been required to produce resources.pri somehow. Copying [executable].pri would be the best option here. If it wasn't, then that means that the Windows App SDK ended up producing the wrong file name in the majority of cases, which is bad. It is also problematic for non WinUI 3 use of the Windows App SDK and MRT Core.