Standard: Add ContentPropertyAttribute class attribute

[dotMorten]

I'd like to propose adding the ContentPropertyAttribute class to the standard. This property allows you to specify the default property to assign to, when using a markup language to define a property.
This is most typically used in XAML, where for instance any XAML specified inside a parent object automatically gets added to the specified property, like for instance the Text property of a TextBlock control.

Specifying the ContentProperty on data object (not just UI controls) is very useful for simplifying how you in markup can define various objects without adding too much extraneous markup.

This attribute already exist in 3 frameworks today

• WPF: System.Windows.Markup.ContentPropertyAttribute
• UWP: Windows.UI.Xaml.Markup.ContentPropertyAttribute
• Xamarin.Forms: Xamarin.Forms.ContentPropertyAttribute

While they are all in separate namespaces, they essentially are the same and confirms that there is a need cross-platform for such a class attribute.

The implementation is just a simple attribute with Name property, and thus nothing platform specific implementation wide - it's up to the individual UI frameworks to look for and use it.

[System.AttributeUsage(System.AttributeTargets.Class)]
public sealed class ContentPropertyAttribute : Attribute
{
    public ContentPropertyAttribute(string name)
    {
        Name = name;
    }
    public string Name { get; }
}

There are already several other classes in the standard who's primary use is XAML, like for instance TypeConverter and INotifyPropertyChanged.

[rrelyea]

If this is considered, should likely look at all XAML related attributes. In .NET, they mostly moved to System.Xaml.dll in v4.

[danmoseley]

@dotMorten if you are proposing a new, common type (although that would be 4...) then corefx is the right repo to propose it. this repo is about designating an existing type as part of the standard surface area

[terrajobst]

@danmosemsft

I asked @dotMorten to file it here because it's more about coming up with a story how we can converge all these types. Once we have a design, we can make an actual feature request, but it will likely require work in both CoreFx as well Mono (Xamarin Forms). Potentially even desktop.

@dotMorten

How do you envision this type being used? It sounds like you're proposing adding a new type and then rely on the UI frameworks to probe for it. I can see this working in WPF and Xamarin Forms but I'm not sure we can do this in WinRT without requiring projections.

[dotMorten]

@terrajobst In WinRT I believe this all done today at compile-time, so no need for reflection.
But yes since they are all in different namespaces, and none of them would work for the standard, it would have to be a new type.

[terrajobst]

Makes sense. I've started a discussion with the WinRT folks to ascertain whether that's technically viable -- we recently did a feature to allow code spit at design time to eliminate the need for projections for types that WinRT Xaml needs to QI for at runtime. Potentially we could plug-in to that code generation. Will report back with their findings.

[terrajobst]

We should consider this for 2.1

[dotMorten]

@terrajobst Working on prepping our stuff for .NET 5, and expect our .NET 5 classes to be used with Xamarin.Forms, UWP, WinUI and WPF, this gets more important as we don't know in the base classes which UI framework we're going to be declaring those classes.
Could this get considered for .NET 5?

CC Various UI platform owners: @davidortinau @pureween @jevansaks @SavoySchuler @ryandemopoulos @stevenbrix @jamesmontemagno

[stevenbrix]

I would love to see something like this, although I'm not entirely sure what it is you want to see? I'd also love to see other XAML attributes follow suite. We've been getting asks to make System.Xaml target netstandard and ship separately from the WindowsDesktop SDK. It feels like if we did that, this would be a natural place to put it. Although at this point we're all targeting .net5, so maybe just a standalone Nuget is all we need now.

@terrajobst what were your findings? :) I think something like this can be doable with the new projection system we plan on having for .NET5 with WinRT.

[dotMorten]

I'm actually thinking something like all the stuff we have in System.ComponentModel (which would probably be a good place to put it). A lot of that is used to drive XAML (INotifyPropertyChanged for instance).

I'd rather not have it in System.Xaml, as that makes it XAML specific, but a content property could be useful for any markup type of language. Also it would be weird to take a dependency on System.Xaml if I'm targeting Xamarin.Forms or WinUI.

[dotMorten]

Here's my problem:

Historically I've been able to get away with this based on TFM (and forms just looks for any attribute with the content attribute name including custom ones), but now that I assume WinUI will also be on .NET 5, that approach won't work any more.

[stevenbrix]

Thank you for the diagram! Pictures do say a 1,000 words :)

System.Xaml is not supposed to be WPF specific. But I understand that the reality of where things are today may be a bit different.

While System.ComponentModel does drive many patterns in XAML frameworks, putting ContentProperty in System.ComponentModel because of this seems backwards. INotifyPropertyChanged and DataAnnotations are all useful outside of XAML. ContentProperty, while it may be general to any markup language, doesn't have use in say, WinForms.

[rrelyea]

@stevenbrix - are you debating where to put it, or arguing about having a common definition?

[stevenbrix]

Debating about where to put it. Totally for having a common definition.

[rrelyea]

do you have a list of options?
is namespace the problem or assembly?

[stevenbrix]

I guess I'd say that both are 😏

Namespace is important for logically understanding the API. Assembly is important so that we don't pull in unnecessary dependencies.

I don't have a list of options yet, mostly because I'm still a bit confused by the scenario and requirements.

Without different TFMs for WPF and WinUI, I'm not really sure how you can have a common library that depends on WPF controls and WinUI controls independent of one another. @dotMorten do you have examples of the code you're trying to write, and what you are not able to accomplish?

[dotMorten]

This for declaring non-ui objects in markup (think resources etc). To simplify the markup declaration the content property is quite useful. So the common library has no UI dependency, but it might be used in one or more UI frameworks.
Put another way: I should be able to declare a class defined in a .NET Standard library in XAML (which I can), and I should be able to simplify that markup by declaring a default content property.
We've done this for years, but now I'm being forced to not have a WPF dependency on the common library (sure that wasn't a .net standard lib, but we used bait'n'switch so the .net core one had a wpf dependency).
As mentioned having to make this new much cleaner split, means being forced to remove a content property that customers have come to rely on. That's basically a no-go, since it's a breaking change.

[stevenbrix]

Thanks @dotMorten, that makes sense now :)

System.Xaml still feels like the appropriate place for this. We use System.Xaml for the WinUI markup compiler, so it's definitely not tied to WPF.

I would like to know what @davidortinau and @jamesmontemagno think w.r.t. Xamarin.

Adding @mikehillberg for input on the WinUI side

[dotMorten]

Forms might get it for free, because they just search for ANY attribute in any assembly and namespace called ContentPropertyAttribute.

[dotMorten]

...I would find it a little weird that a .NET Standard package takes a dependency on System.Xaml

[rrelyea]

Wouldn't it be net5.0, not netstandardX.X?
Would it be crazy for system.xaml to move into the core from net5.0-windows would it?

[dotMorten]

@rrelyea I'd be ok with that.