Runtime: WPF on .NET Core needs TypeDescriptor on System.Xml.Linq.XElement

[rladuca]

WPF has extension libraries for various types. One of them is for System.Xml.Linq.XElement.

It expects that the TypeDescriptor for XElement contains the following property descriptors:

• Elements
• Descendants
• Attribute
• Element

This was previously provided by XTypeDescriptor.GetProperties with a special case for XElement. These seem to not exist in .NET Core and neither does the association of the TypeDescriptor with XElement (see here).

WPF requires this in SystemXmlLinqExtension (the implementation of this is not on the external reference source so I cannot link it here).

cc: @vatsan-madhavan, @ericstj

[rladuca]

Just to be clear, there is no reproduction of this at this point as this is an exposed bug during feature work in WPF on .NET Core 3. Reproducing this requires some changes that are currently in progress in the framework.

[ericstj]

@onovotny has a repro of this

[ericstj]

Looks like we need to push TypeDescriptionProviderAttribute and TypeDescriptionProvider down to System.ObjectModel along with the others, add these attributes back to S.P.XML and the types which they point at.

Essentially:

[System.ComponentModel.TypeDescriptionProvider(typeof(MS.Internal.Xml.Linq.ComponentModel.XTypeDescriptionProvider<XElement>))]
public class XElement : XContainer, IXmlSerializable

[System.ComponentModel.TypeDescriptionProvider(typeof(MS.Internal.Xml.Linq.ComponentModel.XTypeDescriptionProvider<XAttribute>))]
public class XAttribute : XObject

And everything in the closure of those provider types.

[ericstj]

Actually pushing that down will result in a ton of the typeconverter code moving down. We may instead want to see about moving these TypeDescriptionProviders upstack into TypeConverter.

[ericstj]

One thing we could do that is minimal is push down only the attributes and use the string constructor on these to refer to the provider type, then put the provider type in the TypeConverter assembly. Since that's an internal type, we'd either need to use the .NETCore identity (System.ComponentModel.TypeConverter assembly) or manually add the type forwards to the internal types into the System.Xml.Linq facade.

[rladuca]

We have a fairly straightforward internal repro in our currently ported tests. If anyone needs access to this, please let me know and I can direct them to the tests.

[ericstj]

Here's the simple repro (using Microsoft.DesktopUI.App\3.0.0-alpha-27017-4, later versions will have @rladuca's workaround)

dotnet new wpf
add the following to MainWindow.xaml.cs: this.Content = new System.Xml.Linq.XElement("testElement");

xlinq.zip

I've also confirmed the workaround of removing PresentationFramework-SystemXmlLinq.dll and removing the entry from the deps.json.

I am working on adding back this functionality and have a fix to CoreFx that I expect to put up in PR by end of week.