WPF - Is <?Mapping > used anymore?

Basically, I remember that there was a time when you could use the following: <?Mapping ... > (It doesn't seem to work anymore -- Deprecated perhaps?)

I know I can map my XML namespaces like so...

xmlns:xyzcon="clr-namespace:XYZ.Wpf.Controls"
xmlns:xyzcom="clr-namespace:XYZ.Wpf.Commands"

But, I also know that I can map my XML namespaces like so (much cleaner)

[assembly: XmlnsPrefix("http://schemas.mycompany.com/netfx/xaml/presentation", "xyz")]
[assembly: XmlnsDefinition("http://schemas.mycompany.com/netfx/xaml/presentation", "XYZ.Wpf.Controls")]
[assembly: XmlnsDefinition("http://schemas.mycompany.com/netfx/xaml/presentation", "XYZ.Wpf.Commands")]

which makes it very easy to use because instead having the l, lv, etc. prefix I can have all my CLR-Namespaces point to the same XML namespace...

xmlns:xyz="http://schemas.mycompany.com/netfx/xaml/presentation"

That line gives me access to XYZ.Wpf.Controls and XYZ.Wpf.Commands. The problem is that this only works if the assembly is already compiled. I can't use this trick when working within the same assembly.

Basically, from within the same app or assembly, I want to map different CLR namespaces to the SAME XML namespace on a global scale (that way throughout my app I simply have to include that one开发者_运维问答 XML namespace). Any way to do that?

---

It appears that there is still no way to map local namespaces within a WPF project. The book Programming WPF: Building Windows UI with Windows Presentation Foundation (published in 2007) states:

WPF projects in Visual Studio cannot use namespaces introduced by XmlnsDefinitionAttribute from XAML that live in the same assembly. If you want to refer to locally defined types, you must use the alternative mechanism...

The "alternative mechanism" being the dreaded xmlns:local="..." for each namespace.

My understanding is that the executing assembly (in this case the local WPF assembly) searches all referenced assemblies for both XmlnsPrefixAttribute and XmlnsDefinitionAttribute but does not search itself. It makes no sense that 4 years later this behavior has not changed, but that appears to be the case.