WPF - ¿Ya se usa <?Mapping >?

Question

Básicamente, recuerdo que hubo un tiempo en que usted podría utilizar lo siguiente: <?Mapping ... > (? No parece que trabajar más - quizá en desuso)

Sé que puedo asignar mis espacios de nombres XML como tal .. .

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

Pero, también sé que puedo asignar mis espacios de nombres XML como tal (mucho más limpio)

[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")] 

que hace que sea muy fácil de usar ya que en vez teniendo la L, LV, etc. prefijo Puedo tener todos mis espacios de nombres CLR apuntan al mismo espacio de nombres XML ...

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

Esa línea me da acceso a XYZ.Wpf.Controls y XYZ.Wpf.Commands. El problema es que esto solo funciona si el ensamblado ya está compilado. No puedo usar este truco cuando trabajo dentro del mismo conjunto.

Básicamente, desde la misma aplicación o ensamblado, quiero asignar diferentes espacios de nombres CLR al MISMO espacio de nombres XML en una escala global (de esa manera en mi aplicación simplemente tengo que incluir ese espacio de nombres XML). ¿Alguna forma de hacer esto?

Answer 1

Parece que todavía no hay forma de asignar espacios de nombres locales dentro de un proyecto de WPF. El libro Programming WPF: Building Windows UI with Windows Presentation Foundation (publicado en 2007) afirma:

proyectos WPF en Visual Studio no se pueden utilizar espacios de nombres introducidos por XmlnsDefinitionAttribute de XAML que viven en el mismo conjunto. Si desea consultar tipos definidos localmente, debe usar el mecanismo alternativo ...

El "mecanismo alternativo" es el temido xmlns:local="..." para cada espacio de nombres.

Mi entendimiento es que el conjunto de la ejecución (en este caso la asamblea local WPF) busca en todos los que se hace referencia montajes tanto para XmlnsPrefixAttribute y XmlnsDefinitionAttribute pero no busca en sí mismo. No tiene sentido que 4 años después este comportamiento no haya cambiado, pero ese parece ser el caso.