WinAppSDK 1.8: MRM.cpp's MrmGetFilePathFromName now reports error when the resources.pri file doesn't exist #5814

Activity

1. microsoft-github-policy-service

   added

   needs-triage

   on Sep 10, 2025
2. ssparach

   added

   area-MRTCoreResourceManagerResourceManager

   on Sep 11, 2025
3. Alovchin91 commented on Sep 13, 2025

   

   Alovchin91

   on Sep 13, 2025

   More actions

   Simon Mourier (@smourier) I think you might be facing the same issue as Yuyi Wang (@Berrysoft) did here: Alovchin91/winui3-rs#5

   I've found a workaround that seems to work in my setup: you need to subscribe to the Application.ResourceManagerRequested event, and offer it a custom ResourceManager instance pointing to the <WinAppSDK_FrameworkPackage>\resources.pri file.

   You can see the Rust example here: Alovchin91/winui3-rs#5 (comment)
4. Berrysoft commented on Sep 13, 2025

   

   Yuyi Wang (Berrysoft)

   on Sep 13, 2025

   Contributor

   More actions

   Alovchin91 I'm afraid that your solution might not work as expected if the user really wants WinUI to read their custom resources file(?)

   Anyway it's a workaround, and MrmGetFilePathFromName is violating its documents here.
5. smourier commented on Sep 13, 2025

   

   Simon Mourier (smourier)

   on Sep 13, 2025

   Last edited by smourier

   Author

   More actions

   @smourier I think you might be facing the same issue as @Berrysoft did here: Alovchin91/winui3-rs#5

   I've found a workaround that seems to work in my setup: you need to subscribe to the Application.ResourceManagerRequested event, and offer it a custom ResourceManager instance pointing to the <WinAppSDK_FrameworkPackage>\resources.pri file.

   You can see the Rust example here: Alovchin91/winui3-rs#5 (comment)

   It's probably the same issue yes. Your workaround the regression seems to work, thanks, but is there a simple way to determine the WinAppSDK's current (loaded) runtime's path from .NET?

   FWIW, this is how I currently do it (and my repo where the initial link points has now this workaround applied):

       private class DummyApp : Application, IXamlMetadataProvider
       {
           public DummyApp()
           {
               ...
               ResourceManagerRequested += (s, e) =>
               {
                   var module = GetModuleHandleW("MRM");
                   var sb = new StringBuilder(1024);
                   _ = GetModuleFileNameW(module, sb, sb.Capacity);
                   var resources = Path.Combine(Path.GetDirectoryName(sb.ToString())!, "resources.pri");
                   e.CustomResourceManager = new ResourceManager(resources);
               };
           }
   
           [DllImport("kernel32", CharSet = CharSet.Unicode)]
           private static extern nint GetModuleHandleW(string lpModuleName);
   
           [DllImport("kernel32", CharSet = CharSet.Unicode)]
           private static extern int GetModuleFileNameW(nint hModule, StringBuilder lpFilename, int nSize);
       }
   
6. Alovchin91 commented on Sep 13, 2025

   

   Alovchin91

   on Sep 13, 2025

   More actions

   You might want to take a look at an example in the official unpackaged apps deployment documentation: https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/deploy-unpackaged-apps#option-2-deploy-windows-app-sdk-runtime-packages-directly

   You should be able to use the PackageManager class methods with Microsoft.WindowsAppSDK.Runtime.Packages.Framework.PackageFamilyName to find the package, and then use one of the Package object's path properties.
7. smourier commented on Sep 13, 2025

   

   Simon Mourier (smourier)

   on Sep 13, 2025

   Last edited by smourier

   Author

   More actions

   Alovchin91 Thanks. I've seen that but it's very complicated, for a runtime which is already loaded and running (in fact it means the bootstrap loader has already ran through this code internally to find the right package, to me they should add some export to this dll so we know what we're really running off), seems really overkill and in the end possibly less safe to me.
8. Alovchin91 commented on Sep 13, 2025

   

   Alovchin91

   on Sep 13, 2025

   More actions

   Well ideally Microsoft should fix this because it's clearly a bug. But in the meantime seems like this workaround could unblock some people.

   👍React with 👍1Reacted by Simon Mourier
9. beeradmoore commented on Sep 14, 2025

   

   Brad (beeradmoore)

   on Sep 14, 2025

   Last edited by beeradmoore

   More actions

   I think this is the same problem as what is causing #5832 ? As of 1.8 the app no longer produces resources.pri but AppName.pri so the correct one is not loaded. A workaround is to rename AppName.pri to resources.pri on every change to the file, but I'll try that above thing.

   EDIT: I misunderstood what Simon Mourier (@smourier) code above does. That is not the problem I am facing in the update from 1.7 to 1.8.
10. ssparach

    closed this as a duplicateof MrmGetFilePathFromName violates its document #5940 on Oct 23, 2025
11. ssparach

    removed

    needs-triage

    on Oct 27, 2025
12. Scott Jones (Scottj1s)

    added 2 commits that reference this issue on Jul 10, 2026

    Fix MrmGetFilePathFromName to return S_OK with a valid fallback path …

    ...

    91160b0

    [1.8-stable] Gated port: MrmGetFilePathFromName S_OK fallback (from #…

    ...

    00db8a8