http://schemas.microsoft.com/winfx/2006/xaml/presentation definition

Cuando creas un nuevo proyecto WpfApplication en Visual Studio, obtienes el siguiente XAML. Al copiar y pegar la URL http://schemas.microsoft.com/winfx/2006/xaml/presentation en el navegador, esperaba ver la definición del archivo XSD, pero aparece un error. ¿Por qué?

Gracias.

    

El problema es que la mayoría de los desarrolladores de wpf saben cómo funciona, pero cuando lo explicarás, será mucho más difícil … a continuación, es mi bash … debido a la simplificación, se vuelve grande, pero espero que si lees hasta el final, lo entenderás. Cómo funciona la definición …

Guión:

Soy un desarrollador principiante de wpf y busco un girador de wpf en goggle. Tengo un enlace de font.awesome.wpf .. así que empecé a intentarlo. El código a continuación está escrito en el documento para agregar el hilandero.

      

Wow genial …. ¡Está funcionando bien! …

¡¡Repentinamente!! descubro que agregué una línea allí

  xmlns:fa="http://schemas.fontawesome.io/icons/" 

No algo como

  xmlns:fa="clr-namespace:FontAwesome.WPF;assembly=FontAwesome.WPF" 

Entonces, ¡cómo Visual Studio supo qué dll contiene la clase ImageAwesome! … FontAwesome.WPF.dll solo FontAwesome.WPF.dll través de nuget. Nada más hice. No hay ningún archivo xsd o xml adicional allí. El enlace del esquema ( http://schemas.fontawesome.io/icons/ ) no está disponible … entonces, ¿cómo? …¡¡Extraño!!

Sin embargo después de 1 horas terminé con el siguiente código …

           

La parte notable es fa:ImageAwesome y fa:CssClassNameConverter clases … Son de different namespace (usando el código detrás ya lo he comprobado) .. y no especifiqué una línea adicional para especificar FontAwesome.WPF o FontAwesome.WPF.Converters espacio de nombres .. entonces como la magia esta pasando !! ..

Solución:

Así que descargué el código fuente de font.awesome.wpf .. y comencé a buscar el texto http://schemas.fontawesome.io/icons/ allí … y finalmente encontré las siguientes líneas en assembly.cs de la fuente. proyecto awesome.wpf ..

 [assembly: AssemblyVersion("4.5.0.*")] [assembly: AssemblyFileVersion("4.5.0.7")] [assembly: XmlnsPrefix("http://schemas.fontawesome.io/icons/", "fa")] [assembly: XmlnsDefinition("http://schemas.fontawesome.io/icons/", "FontAwesome.WPF")] [assembly: XmlnsDefinition("http://schemas.fontawesome.io/icons/", "FontAwesome.WPF.Converters")] 

Y todo el asunto (¡¡el truco de magia !!) me fue revelado.

En el archivo assembly.cs , el componente definió el http://schemas.fontawesome.io/icons/ namespace … así que cuando agrego fontawesome.wpf dll … visual studio tiene su definición de espacio de nombres usando refection … y así, ¿cómo sabe VS vs? donde la fa tag refers to … Así que así es como me resolvió … 🙂

Alguna teoria

El nombre del espacio de nombres XML no coincide con ningún espacio de nombres .NET en particular. Hay un par de razones por las cuales los creadores de XAML eligieron este diseño. Por convención, los espacios de nombres XML suelen ser identificadores de recursos uniformes (URI) como están aquí. Estos URI parecen apuntar a una ubicación en la Web, pero no lo hacen. El formato URI se usa porque hace que sea poco probable que diferentes organizaciones creen inadvertidamente diferentes idiomas basados ​​en XML con el mismo espacio de nombres. Debido a que el dominio schemas.microsoft.com es propiedad de Microsoft, solo Microsoft lo usará en un nombre de espacio de nombres XML.

La otra razón por la que no existe una asignación uno a uno entre los espacios de nombres XML utilizados en los espacios de nombres XAML y .NET es porque complicaría significativamente sus documentos XAML. El problema aquí es que WPF abarca más de una docena de espacios de nombres (todos los cuales comienzan con System.Windows). Si cada espacio de nombres .NET tuviera un espacio de nombres XML diferente, necesitaría especificar el espacio de nombres correcto para cada uno de los controles que usa, lo que rápidamente se complica. En su lugar, los creadores de WPF eligieron combinar todos estos espacios de nombres .NET en un solo espacio de nombres XML. Esto funciona porque dentro de los diferentes espacios de nombres .NET que forman parte de WPF, no hay clases que tengan el mismo nombre. La información del espacio de nombres permite al analizador XAML encontrar la clase correcta. Por ejemplo, cuando observa los elementos de Ventana y Cuadrícula, ve que están ubicados en el espacio de nombres WPF predeterminado. A continuación, busca los espacios de nombres .NET correspondientes hasta que encuentra System.Windows.Window y System. Windows.Controls.Grid

Un espacio de nombres es un URI (un URN o una URL), pero un URI no siempre es una URL. El URI utilizado para los espacios de nombres tiene la intención de identificar de forma única los nombres para evitar conflictos. El Grupo de trabajo de espacios de nombres XML en ese momento decidió utilizar una técnica ya conocida para identificar de manera única las cosas: URI.

Como resultado, muchas personas piensan que en realidad debería apuntar a algo real. Ocasionalmente eso es cierto, pero más a menudo no lo es, y no está destinado a serlo . Es un identificador , no una ubicación .

En el caso de los esquemas, se puede usar para denotar el espacio de nombres de destino, que es el espacio de nombres que se debe usar en los documentos que deben validarse con respecto al esquema. Para obtener el esquema, tendrá que preguntar al vendedor. En este caso, el esquema se puede encontrar en una ubicación similar o igual a C:\Program Files (x86)\Microsoft Visual Studio 10.0\Xml\Schemas , busque wpfe.xsd (sin embargo, para confundir las cosas más, Microsoft ha decidido para crear un alias para el espacio de nombres de destino, por lo que no verá el mismo espacio de nombres que mencionó).