Unpackaged C++ app using xaml islands - xaml/xbf resources embeded in pri file cannot be loaded

[PetrMinar]

When I build Release configuration for my sample application in this repository, I get pri file with embeded xbf resources in it as well as standalone xbf/xaml files. In theory the application should run without xbf/xaml files and only use data from pri file. But that is not the case - when I delete both xbf and xaml files, the application encounters 0x802b000a error.

Digging deep into the WindowsAppSDK code I think the problems is somewhere inside ModernResourceProvider::Create where ProbeForFrameworkPackageResourcesPri function cannot find application package (call to GetCurrentPackageInfo returns APPMODEL_ERROR_NO_PACKAGE). This leads to resource manager that does not use pri file. At least I think so...

Is there anything I can do to force application to use pri file? Should I call manually LoadPriFiles from resource manager?

[DarranRowe]

I would have to spend some time digging into this, but I find it hard to believe that there would be a failure for loading the resources in an unpackaged Xaml Islands context because unpackaged Xaml applications work. Unpackaged Xaml applications load their components in the same kind of way:

    template <typename D, typename ... I>
    void MainWindowT<D, I...>::InitializeComponent()
    {
        if (!_contentLoaded)
        {
            _contentLoaded = true;
            ::winrt::Windows::Foundation::Uri resourceLocator{ L"ms-appx:///MainWindow.xaml" };
            ::winrt::Microsoft::UI::Xaml::Application::LoadComponent(*this, resourceLocator, ComponentResourceLocation::Application);
        }
    }

This leads to the application using the .pri file properly, even when the application is unpackaged.

Before I start digging into this, is your application's .pri file named correctly? MRTCore is able to find it when it is named resources.pri (even in an unpackaged application) or <Executable Name>.pri. As an example of the second option, if the executable is named MyApp.exe, then MRTCore will search for MyApp.pri.

The second thing to check, if your application does have a .pri file named properly, does the resource it is looking for actually have a match in the .pri file? In some circumstances, other desktop application templates don't properly handle .pri files.

[PetrMinar]

The name of the pri file coresponds to the dll, where the xaml islands implementation resides. The executable is MFCApp.exe, which is regular unpackaged MFC app. The xaml islands implementation resides in dll named zxamlslands.dll ("Windows Runtime Component (Win UI)" template was used). So the pri file has the name of the dll. I tried to rename the file to resources.pri and something changed - the app now probably finds the pri file, but fails later in XamlControlsResources::UpdateSource. It looks like this is the right direction to continue my investigation...

BTW MFCApp.pri already exists from the project build and is empty.

Do you think this "MFC exe / xaml islands dll" approach is so strange that WindowsAppSDK does not support it out of the box?

[DarranRowe]

Do you think this "MFC exe / xaml islands dll" approach is so strange that WindowsAppSDK does not support it out of the box?

No, without going into too much detail, MFC applications are almost indistinguishable from other C++ desktop applications at the project level. I think the only notable difference is the Keyword element being set to MFCProj in an MFC application but it is set to Win32Proj for the desktop application templates. This has no impact on the build process.

BTW MFCApp.pri already exists from the project build and is empty.

This has been edited.
This shouldn't be empty. Testing your project shows that the executable's .pri file has all of the resources merged in it. The file generated for me is 1.26MiB.

To give an example of this from a working WinUI 3 application that references a component, here is the directory layout of this application. This is also unpackaged.

I highlighted both of the .pri files, but also note that resources.pri doesn't exist here. The application does work properly though. The component has a string resource. If I dump the contents of the component's .pri file, I get the following.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PriInfo>
	<ResourceMap name="TestComponent" version="1.0" primary="true">
		<Qualifiers>
			<Language>EN-US,JA-JP</Language>
		</Qualifiers>
		<ResourceMapSubtree name="TestComponent">
			<ResourceMapSubtree name="Strings">
				<NamedResource name="Greeting" uri="ms-resource://TestComponent/TestComponent/Strings/Greeting">
					<Candidate qualifiers="Language-JA-JP" type="String">
						<Value>こんにちは</Value>
					</Candidate>
					<Candidate qualifiers="Language-EN-US" isDefault="true" type="String">
						<Value>Hello</Value>
					</Candidate>
				</NamedResource>
			</ResourceMapSubtree>
		</ResourceMapSubtree>
	</ResourceMap>
</PriInfo>

If I then dump the contents of the application's .pri file, I get the following.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PriInfo>
	<ResourceMap name="TestWinUI3Cpp" version="1.0" primary="true">
		<Qualifiers>
			<Language>EN-US,JA-JP</Language>
		</Qualifiers>
		<ResourceMapSubtree name="Files">
			<NamedResource name="App.xbf" uri="ms-resource://TestWinUI3Cpp/Files/App.xbf">
				<Candidate type="Path">
					<Value>App.xbf</Value>
				</Candidate>
			</NamedResource>
			<NamedResource name="MainWindow.xbf" uri="ms-resource://TestWinUI3Cpp/Files/MainWindow.xbf">
				<Candidate type="Path">
					<Value>MainWindow.xbf</Value>
				</Candidate>
			</NamedResource>
		</ResourceMapSubtree>
		<ResourceMapSubtree name="TestComponent">
			<ResourceMapSubtree name="Strings">
				<NamedResource name="Greeting" uri="ms-resource://TestWinUI3Cpp/TestComponent/Strings/Greeting">
					<Candidate qualifiers="Language-JA-JP" type="String">
						<Value>こんにちは</Value>
					</Candidate>
					<Candidate qualifiers="Language-EN-US" isDefault="true" type="String">
						<Value>Hello</Value>
					</Candidate>
				</NamedResource>
			</ResourceMapSubtree>
		</ResourceMapSubtree>
	</ResourceMap>
</PriInfo>

Do you notice that the component's resources are present in this file? This is also from the debug build, so the .xbf files not being embedded is expected. The reason why I am calling this out is because the WinUI 3 templates places all of the relevent resources in the executable's .pri file when unpackaged. The thought here would be to emulate the WinUI's layout when trying to get things to work.

Anyway, as I said, I would have to look into things here, but a quick check shows that the component looks for the executable's resources file by default.

--Edit--

Right, using a component to access resources in a WinUI 3 application shows the following.

In this case, the component is TestComponent.dll and the associated resources file is TestComponent.pri. The executable is TestWinUI3Cpp.exe and the associated resources file is TestWinUI3Cpp.pri. This is what process monitor shows is happening in the application. Something important to mention is that the code accessing the resources is:

    winrt::hstring Class::GetGreeting()
    {
        auto resource_manager = winrt::Microsoft::Windows::ApplicationModel::Resources::ResourceManager{};
        auto resource_map = resource_manager.MainResourceMap();
        auto component_map = resource_map.GetSubtree(L"TestComponent");

        auto greeting = component_map.GetValue(L"Strings/Greeting");

        winrt::hstring resource = greeting.ValueAsString();

        return resource;
    }

This means that it is accessing the default resources. The application, which is running from TestComponent attempts to access resources.pri and then the executable's .pri file. One thing I also tried was to rename the executable's .pri file after the application was loaded but before I queried the resource through the component, and the application crashed.

MRTCore only ever looked for resources.pri and then the executable's .pri file. So all of the resources must be present in the executable's .pri file, even if you are accessing the resources from somewhere else.

[DarranRowe]

Well, a quick check of your project shows one very obvious problem, if you know what you are looking for.

The resources are as follows.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PriInfo>
	<ResourceMap name="ZXamlslands" version="1.0" primary="true">
		<Qualifiers/>
		<ResourceMapSubtree name="Files">
			<ResourceMapSubtree name="ZXamlslands">
				<NamedResource name="TestPage.xbf" uri="ms-resource://ZXamlslands/Files/ZXamlslands/TestPage.xbf">
					<Candidate type="Path">
						<Value>ZXamlslands\TestPage.xbf</Value>
					</Candidate>
				</NamedResource>
				<NamedResource name="XamlIslandsApp.xbf" uri="ms-resource://ZXamlslands/Files/ZXamlslands/XamlIslandsApp.xbf">
					<Candidate type="Path">
						<Value>ZXamlslands\XamlIslandsApp.xbf</Value>
					</Candidate>
				</NamedResource>
			</ResourceMapSubtree>
		</ResourceMapSubtree>
	</ResourceMap>
</PriInfo>

But the generated code for XamlIslandsApp and TestPage shows is:

//From XamlIslandsApp.xaml.g.h
        void InitializeComponent()
        {
            if (_contentLoaded)
                return;
           
            _contentLoaded = true;

            ::winrt::Windows::Foundation::Uri resourceLocator{ L"ms-appx:///XamlIslandsApp.xaml" }; //This line is wrong.
            ::winrt::Microsoft::UI::Xaml::Application::LoadComponent(*this, resourceLocator);
        }

//From TestPage.xaml.g.hpp
    template <typename D, typename ... I>
    void TestPageT<D, I...>::InitializeComponent()
    {
        if (!_contentLoaded)
        {
            _contentLoaded = true;
            ::winrt::Windows::Foundation::Uri resourceLocator{ L"ms-appx:///TestPage.xaml" }; //This line is wrong.
            ::winrt::Microsoft::UI::Xaml::Application::LoadComponent(*this, resourceLocator, ComponentResourceLocation::Nested);
        }
    }

So the generated code disagrees with the resource file names. These should be ms-appx:///ZXamlIslands/XamlIslandsApp.xaml and ms-appx:///ZXamlIslands/TestPage.xaml respectively. The runtime internally does the .xaml -> .xbf conversion so the extension doesn't matter.

--Edit--

Well, this is one of those situations where the cause is something that I definitely wouldn't expect you to know.

I noticed in your library's project file that you have both WindowsPackageType and WindowsAppSDKSelfContained set. These should not be in the library, they must only ever be in the executable's project file. These being set cause the build to believe that ZXamlIslands is an executable and not a library. This causes it to omit the library name in the generated code.

Removing the WindowsPackageType and WindowsAppSDKSelfContained values from the library project will cause the generated code to add the project name properly, but then you will hit another problem. The project is named ZXamlslands but the root namespace is ZXamlIslands. This will cause the resources file to be placed in the ZXamlIslands directory, but the resource lookup will be based upon the project name, ZXamlslands. Your best bet is to recreate the project file so that everything agrees. I modified everything so that everything agreed here and the application worked without issue for the release configuration, even after I removed the files that were embedded.

[snigdha011997]

@PetrMinar , on confirmation does @DarranRowe approach solved your issue? let us know any additional assistance is needed.

[PetrMinar]

@DarranRowe Thank you for your help. I would never be able to find out myself that the source of the problem are the WindowsPackageType and WindowsAppSDKSelfContained values in the library project. When I removed them everything started to work correctly.

@snigdha011997 Yes, it solved my problem. I need no further assistance. I am closing this issue.