search

dotnet / wpf

WPF is a .NET Core UI framework for building Windows desktop applications.
MIT License
7.03k stars 1.16k forks source link

Allow registering xmlns prefixes for foreign assemblies #96

Open taori opened 5 years ago

taori commented 5 years ago

As pointed out in https://github.com/dotnet/wpf/issues/45, using

[assembly: XmlnsPrefix("http://schemas.dotMorten.com/2018", "custom")]
[assembly: XmlnsDefinition("http://schemas.dotMorten.com/2018", "MyClassNamespace")]

only works for assemblies you own.

It would be nice if you could declare those attributes at application level, to provide controls of an assembly with custom namespaces, if they lack those attributes, or even override them.

While the later one isn't essential, i think the first one could be useful, if people share their controls on nuget and don't know about custom namespace prefixes.

At least i've had situations where i was annoyed with the awfully verbose prefixes others chose, or the lack of them alltogether.

Another scenario would be that you are supplied with a viewmodels assembly and are going to use those in your views. Being able to group those namespaces would be neat.

mstrobel commented 5 years ago

The prefixes are only suggestions, and you can always substitute your own at the import site. Being able to add XmlnsDefinition mappings for external assemblies is the far more interesting part of this proposal.

Interestingly, XmlnsDefinitionAttribute already has an AssemblyName property, but as far as I can tell, System.Xaml simply ignores it. Perhaps this is a capability that Microsoft intended to implement, but simply didn’t.

rrelyea commented 5 years ago

From: Rob Relyea Sent: Tuesday, January 19, 2010 8:50 AM To: Mark;Michael Cc: David Subject: RE: Is the AssemblyName property on XmlnsDefinitionAttribute supposed to have any effect?

Yes, that property is kindof a noop…that we discovered late in the game. The idea was to let WindowsFormsIntegration.dll provide an XmlnsDefinitionAttribute for v2 windorms in v3.

No scenarios have been blocked with the noop.

dotMorten commented 4 years ago

Looking at the work I need to do for WinUI to support it's future availability for .NET Core, I need to pull out all WPF specific bits from my .NET Core assembly (as part of separating UI code from non-UI code). However this assembly has these attributes in it, so it would be a breaking change for me to remove them.

If I could declare the attributes in a different assembly (ie the WPF specific extension), I could avoid introducing a breaking change, as I would merely have moved where they are defined.

dotMorten commented 4 years ago

It appears the attribute is only used here, and indeed the assembly property isn't used and a different assembly is just being used: https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/System.Xaml/System/Xaml/MS/Impl/XmlNsInfo.cs#L176-L178

But it looks slightly more involved than just getting the right assembly here, but also forward the name to the method being called.

dotMorten commented 4 years ago

Took a stab at it in PR 3066 linked above. Can't really test the build tasks though (no documentation on how you do that)

taori commented 4 years ago

Pretty cool. I hope this gets merged.

YBAZAN commented 3 years ago

Any news on it ? Is this pr planned to be merged ?

DaveInCaz commented 3 years ago

I think this issue was part of the same thing being talked about here: https://stackoverflow.com/a/33877804/3195477