Loading UI components at runtime from a .dll

[benaclejames]

Hey there, I was just wondering if anyone had figured out a way to load .xaml from a dll at runtime? I have no way of referencing the .dlls at compile time, but I still want to load them once the program has started, either a usercontrol or page.

[pmmachado1971]

Same problem here ....
Can't pass "xaml parsing failed" trying to create a plugin host app with xaml in the plugins created as WinUI Class Library.
If dll referenced in the host project it works, but if dll is loaded on runtime always get "xaml parsing failed"

If a solution is found, please share :-)

[DarranRowe]

There are a couple of things that get put in place at compile time that do not get set properly if you reference the control dynamically at runtime.

If you look at the .pri files involved. As an example:

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

This is the resources of a component. This was dumped from the .pri file using makepri.
Now, if we then look at an application's .pri file for how it looks.

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

This is without the control referenced.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PriInfo>
	<ResourceMap name="Meh" version="1.0" primary="true">
		<Qualifiers/>
		<ResourceMapSubtree name="Files">
			<NamedResource name="App.xbf" uri="ms-resource://Meh/Files/App.xbf">
				<Candidate type="Path">
					<Value>App.xbf</Value>
				</Candidate>
			</NamedResource>
			<NamedResource name="MainWindow.xbf" uri="ms-resource://Meh/Files/MainWindow.xbf">
				<Candidate type="Path">
					<Value>MainWindow.xbf</Value>
				</Candidate>
			</NamedResource>
			<ResourceMapSubtree name="TestControl">
				<NamedResource name="SillyPage.xbf" uri="ms-resource://Meh/Files/TestControl/SillyPage.xbf">
					<Candidate type="Path">
						<Value>TestControl\SillyPage.xbf</Value>
					</Candidate>
				</NamedResource>
				<ResourceMapSubtree name="Themes">
					<NamedResource name="Generic.xbf" uri="ms-resource://Meh/Files/TestControl/Themes/Generic.xbf">
						<Candidate type="Path">
							<Value>TestControl\Themes\Generic.xbf</Value>
						</Candidate>
					</NamedResource>
				</ResourceMapSubtree>
			</ResourceMapSubtree>
		</ResourceMapSubtree>
	</ResourceMap>
</PriInfo>

This is with the control referenced.
There is another issue as well. Metadata. If you look at the generated Xaml code, there is a member where the Xaml metadata provider loads all of the referenced providers.

std::vector<::winrt::Microsoft::UI::Xaml::Markup::IXamlMetadataProvider> const& XamlTypeInfoProvider::OtherProviders()
{
    std::lock_guard<std::recursive_mutex> lock(_xamlTypesCriticalSection);
    if (_otherProviders.empty())
    {
        _otherProviders.push_back(::winrt::Microsoft::UI::Xaml::XamlTypeInfo::XamlControlsXamlMetaDataProvider());
        _otherProviders.push_back(::winrt::Microsoft::UI::Xaml::XamlTypeInfo::XamlControlsXamlMetaDataProvider());
        _otherProviders.push_back(::winrt::TestControl::XamlMetaDataProvider());
    }
    return _otherProviders;
}

While this is C++, C# should do something similar.
So right now, the two things getting in the way of this are:

1. The Xaml runtime looks in the default resources for any control resources.
2. The Xaml compiler provides a static list of metadata providers to the Xaml runtime.

This would mean that in order to be able to dynamically load a control, you would have to be able to dynamically load and merge .pri files, translating the control paths as needed. You would also have to dynamically add providers to the application's metadata provider list. If you do some extra work with InitializeComponent in your applications App class, I'm sure you could get the metadata provider to work, but it is the resources that is currently the problem.
If you use 1.4 Preview 1, then it could be possible to get something going with the new event added to Microsoft.UI.Xaml.Application, at the very least you could use the PRI generation functions to dynamically generate a merged .pri file. However, once you hand this off to the Xaml runtime, you are stuck with the controls you have until you restart the application. Since the event asks for an IResourceManager interface rather than a ResourceManager runtime class, it should also be possible to write a custom implementation to do a more dynamic runtime load and use. But since this is still in preview, I haven't looked too deeply into it yet.
For current versions, if you are working with an unpackaged application then it should be possible to do the dynamic resource merge, you just have to have it output to the default application .pri file. But this is impossible with packaged applications due to the package being immutable.
As a disclaimer, this could be wrong since it is based upon about 15 minutes of research.

[MEK3DK]

I think you are hitting this known bug that has been around for years: #6299

Very important bug, but still not fixed.