Bug: Unable to Inherit from MUX WinUI 2.x Controls in C#

[robloo]

Describe the bug

Unable to create new controls inheriting from a MUX WinUI 2.x base control. The control template will never be applied.

Steps to reproduce the bug

Using the attached repro project below:

InheritTest.zip

1. Using the WUX namespace set a breakpoint on base.OnApplyTemplate(). When code is run the breakpoint should be hit:
   
2. Change to the MUX namespace for the base control and run again with the same breakpoint:
   
3. The breakpoint in OnApplyTemplate() is never hit and the control template is never applied.

Note that if you change the DefaultStyleKey = typeof(ColorPicker) (the base type) that will work.

Expected behavior

It should be possible to inherit from a MUX WinUI 2.x base control and have the new control template applied.

Screenshots

Using WUX the template is correctly applied:

Using MUX no template is applied:

Also see above.

Version Info

NuGet package version:

Microsoft.UI.Xaml 2.4.3

Windows app type:

UWP	Win32
Yes	N/A

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2020 Update (19041)	Yes
November 2019 Update (18363)
May 2019 Update (18362)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Xbox
Surface Hub
IoT

Additional context

This is a pretty major roadblock. I need a work-around or fix pretty quickly...

[robloo]

Seems I missed a bug report as well: #3499

[stevenbrix]

@robloo can you try adding this in your control as a workaround?

this.DefaultStyleResourceUri = new System.Uri("ms-appx:///Themes/Generic.xaml");

[robloo]

@stevenbrix Thanks for that trick, I never knew that property existed allowing you to set the default style location. Always relied on the magic generic.xaml being found behind the scenes. Regardless, this did "fix" the issue or at least provide a work-around. I guess this is one of those things that will just disappear with WinUI 3.0 so the work-around is probably enough for now.

Edit: This might need to be looked at in more detail from a controls library perspective. It should probably automatically resolve correctly by itself somehow even when using a controls library NuGet.

[stevenbrix]

@robloo, yeah this was something that I just came across a well. I agree, I like this better than the magical generic.xaml.

I don't think WinUI3 will fix this issue. The WCT had the exact same problem with WinUI3.

Edit: This might need to be looked at in more detail from a controls library perspective. It should probably automatically resolve correctly by itself somehow even when using a controls library NuGet.

I agree 100%. I think there are ways we could have our default item templates set this.

@MikeHillberg, do you have any thoughts?

[michael-hawker]

Any updates on this issue? Is this an inherent limitation in UWP compared to how this worked in WPF? Do we basically have to hard-code and merge the resource from the assembly into the app's resource dictionary? (See our discussion in the Toolkit here: CommunityToolkit/WindowsCommunityToolkit#3603)

[azchohfi]

Any updates on this? We started to get this on our TabbedCommandBar, so maybe we'll need to update every control on the toolkit. This will be a big hassle for any library porting to WinUI3, so we would appreciate a fix.
@codendone Is this being tracked for 1.0?

[robloo]

For the Windows Community Toolkit ColorPicker I also had to add the work around.

https://github.com/windows-toolkit/WindowsCommunityToolkit/pull/4010/files

[michael-hawker]

Just hit this again and forgot about DefaultStyleResourceUri.

However, when the platform can't find the specified style for a control before OnApplyTemplate is called, it feels like this should really be throwing an exception with those types of details like "Can't find resource X from ResourceUri Y" as then it'd be immediately obvious there's a problem. What it's trying to look for, and where it's trying to look (in the example above it'd be the WinUI generic.xaml instead of the Toolkit one as we would have expected).

Otherwise, with just a silent eating it, no OnApplyTemplate and no rendering of the control, it's just a black box and takes forever to debug. So many hours some times to realize what's going on or to find what's causing an issue.

[mrlacey]

X-Ref related discussion in #5525

[michael-hawker]

Hit this again, almost forgot about it again...

[robloo]

Did this get addressed in WinUI 3? Seems pretty fundamental of an issue...

[evelynwu-msft]

Looks like this same bug exists in WinUI 3. Repro project