How to load XAML dynamically via a Uri

[billhenn]

We have a need where we want to dynamically load XAML that has been added to our application with build action of "Page" and render it as the content of our window. We have hundreds of these XAML files and a list of the paths to each of them. Our app UI lets us navigate around them.

In WPF where we have a similar setup, we could call Application.LoadComponent, pass it the path, and it would return the resulting object. The object was a FrameworkElement and we'd simply set it as ContentControl.Content and it would display in the window.

However in WinUI, the Application.LoadComponent API is different. There doesn't seem to be an overload that returns a created and initialized instance of whatever was at the path. We could really use that.

Instead, the WinUI version seems to want you to have already created an instance of the object to initialize, and then it will further initialize the object based on the XAML at the specified path. In our case, this is bad because we don't always know the type that the XAML is associated with. Sometimes it might be a basic UserControl. Other times it might be a special Control-based class with custom code-behind.

Is there any other way to get behavior like what is in the Application.LoadComponent in WPF, where you point it to a path and it returns the object that was created AND initialized? If not, can that be added to WinUI?

[ranjeshj]

@billhenn XamlReader.Load can load markup and build an object for you. Would that work for you ?

[billhenn]

@ranjeshj I did see that API and it probably would work if I could get the XAML. The problem is that when the XAML (and its possible code-behind file) are included in the project as the default Build Action of "Page", I'm not sure how to access the XAML.

I may be wrong, but it seems like the XAML might have to be included with a Build Action of "Content" in order to even access the file via "ms-appx://", and that's only because it's then shipping the file as a loose file, which is not what I want to do.

I want to be able to access the XAML from the normal "Page" compilation. However Application.LoadComponent is getting to it, and be able to then do a XamlReader.Load like call on that XAML.

The simplest thing would be if there was an Application.LoadComponent implementation like in WPF where you just passed it a path and it returned an appropriate object that it created itself and then initialized. That's what I was hoping to see.

[michael-hawker]

@billhenn if the XAML pages are being included in the compilation as Page and included in the application, how do they need to loaded dynamically?

Why is using a Frame and Navigate(typeof(PageTypeNameHere)) not sufficient? What am I missing that's extra in your scenario?

You can use general reflection APIs to crawl your app's included assemblies for the pages in whatever namespaces you've put them in too, so if it's just a matter of not knowing type names at runtime due to conditional build steps coming from other sources, that should be fine as well. (Though a better solution now would be to have an incremental source generator do that instead at compile time and create a registry of all known XAML page types that the app can then just use to grab a particular page).

[michael-hawker]

Related to #6299 as well.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.