windows-reactor-setup: not good to copy `resources.pri`

[Berrysoft]

windows-rs/crates/libs/reactor-setup/src/lib.rs

Lines 45 to 52 in 5141637

	copy_file(
	&interactive
	.join(&arch)
	.join("native")
	.join("Microsoft.UI.pri"),
	&dest,
	"resources.pri",
	);

WinUI3 needs a pri file to start after version 1.8. It is because of microsoft/WindowsAppSDK#4965 . It is a good refactor PR, but it violates the document, which says that the method MrmGetFilePathFromName will return a non-exist path with S_OK. I have created a PR to fix it, but nobody in MS cares: microsoft/WindowsAppSDK#5828

I think the file copying in windows-reactor-setup is a patch at the wrong place. It introduces more files to mitigate the bug. As my solution has been ignored for a long time, I hope you maintainers could contact with the real person in charge to solve the root issue.

[Scottj1s]

@Berrysoft Thanks for your WinAppSDK PR - sorry I missed it, but reviewing it now.

[kennykerr]

I take it this is the best we can do in windows-reactor-setup until a fix is available from the framework?

[Berrysoft]

I think it depends on how do you define the best, because the resources.pri alongside the exe could actually be an empty resource file instead of exactly the WinUI one: Alovchin91/winui3-rs#5 (comment)

[kennykerr]

cc @Alovchin91

[riverar]

Agreed. I verified (via gallery.exe) that no other lookups are occurring. This isn't foolproof but it doesn't look like we're doing anything with the local PRI beyond startup.

0x7ffb7d112e29  [MRM.dll]  _DefCreateFile  \dev\MRTCore\mrt\mrm\mrmmin\Platform.cpp:973
0x7ffb7d108168  [MRM.dll]  Microsoft::Resources::BaseFile::CreateInstance  \dev\MRTCore\mrt\mrm\mrmmin\BaseFile.cpp:177
0x7ffb7d11585d  [MRM.dll]  Microsoft::Resources::ManagedFile::InnerLoad  \dev\MRTCore\mrt\mrm\mrmmin\ManagedFiles.cpp:195
0x7ffb7d11532d  [MRM.dll]  Microsoft::Resources::ManagedFile::CreateInstance  \dev\MRTCore\mrt\mrm\mrmmin\ManagedFiles.cpp:97
0x7ffb7d114604  [MRM.dll]  Microsoft::Resources::PriFileManager::GetOrAddFile  \dev\MRTCore\mrt\mrm\mrmmin\PriFileManager.cpp:108
0x7ffb7d1050cd  [MRM.dll]  Microsoft::Resources::UnifiedResourceView::SetApplicationPriFile  \dev\MRTCore\mrt\mrm\mrmmin\UnifiedView.cpp:292
0x7ffb7d0f657d  [MRM.dll]  MrmCreateResourceManager  \dev\MRTCore\mrt\Core\src\MRM.cpp:535
0x7ffb7d14c443  [Microsoft.Windows.ApplicationModel.Resources.dll]  winrt::make<winrt::Microsoft::Windows::ApplicationModel::Resources::implementation::ResourceManager>  \obj\Release\x64\Microsoft.Windows.ApplicationModel.Resources\Generated Files\winrt\base.h:8056
0x7ffb7d14d49e  [Microsoft.Windows.ApplicationModel.Resources.dll]  winrt::impl::produce<winrt::Microsoft::Windows::ApplicationModel::Resources::factory_implementation::ResourceManager,winrt::Windows::Foundation::IActivationFactory>::ActivateInstance  \obj\Release\x64\Microsoft.Windows.ApplicationModel.Resources\Generated Files\winrt\base.h:6545
0x7ffcdbc1bcfb  [combase.dll]  WinRTCreateInstanceOfInprocClass  onecore\com\combase\objact\objact.cxx:3202
0x7ffcdbc1b4cb  [combase.dll]  WinRTActivateInstanceInternal  onecore\com\combase\winrtbase\winrtbase.cpp:576
0x7ffcdbc1c0a2  [combase.dll]  _RoActivateInstance  onecore\com\combase\winrtbase\winrtbase.cpp:826
0x7ffcdbc1d0c9  [combase.dll]  RoActivateInstance  onecore\com\combase\winrtbase\winrtbase.cpp:878
0x7ffb4cf6555a  [Microsoft.UI.Xaml.dll]  Windows::Foundation::ActivateInstance<ABI::Microsoft::Windows::ApplicationModel::Resources::IResourceManager>
0x7ffb4ce81ca7  [Microsoft.UI.Xaml.dll]  ModernResourceProvider::Create
0x7ffb4ce81b2b  [Microsoft.UI.Xaml.dll]  CWindowsServices::CreateResourceProvider

I'll hollow out the PRI for framework-deployed scenarios; shaves off ~100kb off the footprint. And then when microsoft/WindowsAppSDK#5828 lands we can update again and remove it completely.

[Alovchin91]

To be fair, I would still prefer the solution with subscribing to ResourceManagerRequested from my comment here. It was indeed quite some time ago, but if I remember correctly, that is the closest to the original behaviour of the ResourceManager factory: I give it a non-existent path, and it does what it always did before when resources.pri didn’t exist. If I’m not mistaken, the culprit was the default code path where the existence of resources.pri was suddenly additionally checked before calling the factory. ResourceManagerRequested subscription simply circumvents that default code path.

[Alovchin91]

Ah, I see now that that comment is a bit dated. You don’t need to give ResourceManager’s factory a real path, ResourceManager::CreateInstance(h!("resources.pri"))? should be enough from what I remember.

So something like this:

app.ResourceManagerRequested(&TypedEventHandler::new(
    move |_, args: Ref<ResourceManagerRequestedEventArgs>| {
        let args = args.as_ref().ok_or(E_POINTER)?;
        let resource_manager =
            ResourceManager::CreateInstance(h!("resources.pri"))?;
        args.SetCustomResourceManager(&resource_manager)
    },
))?;

Note that creating the default ResourceManager (ResourceManager::new()?) will not solve the issue here.