Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este tema se explica aún más la presencia y el propósito de las dos asignaciones de espacios de nombres XAML, como se encuentra con frecuencia en la etiqueta raíz de un archivo XAML de WPF. También describe cómo generar asignaciones similares para usar elementos definidos en su propio código o dentro de ensamblados independientes.
¿Qué es un espacio de nombres XAML?
Un espacio de nombres XAML es realmente una extensión del concepto de un espacio de nombres XML. Las técnicas de especificar un espacio de nombres XAML dependen de la sintaxis del espacio de nombres XML, la convención de usar URI como identificadores de espacio de nombres, usando prefijos para proporcionar un medio para hacer referencia a varios espacios de nombres desde el mismo origen de marcado, etc. El concepto principal que se agrega a la definición XAML del espacio de nombres XML es que un espacio de nombres XAML implica tanto un ámbito de unicidad para los usos de marcado, como también influye en cómo las entidades de marcado están potencialmente respaldadas por espacios de nombres CLR específicos y ensamblados a los que se hace referencia. Esta última consideración también está influenciada por el concepto de un contexto de esquema XAML. Sin embargo, para entender cómo funciona WPF con espacios de nombres XAML, generalmente se puede pensar en espacios de nombres XAML en términos de un espacio de nombres XAML predeterminado, el espacio de nombres del lenguaje XAML y cualquier otro espacio de nombres XAML mapeado directamente a espacios de nombres CLR específicos y ensamblajes referenciados.
Declaraciones de espacio de nombres WPF y XAML
En las declaraciones de espacio de nombres dentro de la etiqueta raíz de muchos archivos XAML, podrá observar que normalmente hay dos declaraciones de espacio de nombres XML. La primera declaración asigna el espacio de nombres XAML del cliente o marco de WPF general como valor predeterminado:
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
La segunda declaración asigna un espacio de nombres XAML independiente, asignándolo (normalmente) al x:
prefijo.
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
La relación entre estas declaraciones es que la asignación de prefijo x:
admite los intrínsecos que forman parte de la definición del lenguaje XAML, y WPF es una implementación que usa XAML como lenguaje y define un vocabulario de sus objetos para XAML. Dado que los usos del vocabulario de WPF serán mucho más comunes que los usos intrínsecos de XAML, el vocabulario de WPF se asigna como valor predeterminado.
La convención de prefijo x:
para asignar el soporte de intrínsecos del lenguaje XAML es seguida por plantillas del proyecto, código de ejemplo y documentación de características del lenguaje dentro de este SDK. El espacio de nombres XAML define muchas características usadas habitualmente que son necesarias incluso para aplicaciones básicas de WPF. Por ejemplo, para unir cualquier código subyacente a un archivo XAML a través de una clase parcial, debes asignar un nombre a esa clase como x:Class
atributo en el elemento raíz del archivo XAML correspondiente. O bien, cualquier elemento tal como se define en una página XAML a la que quiera acceder como un recurso con clave debe tener el x:Key
atributo establecido en el elemento en cuestión. Para obtener más información sobre estos y otros aspectos de XAML, consulta XAML en WPF o sintaxis XAML en detalle.
Mapeo a clases y ensamblados personalizados
Puedes asignar espacios de nombres XML a ensamblados mediante una serie de tokens dentro de una xmlns
declaración de prefijo, similar a cómo se asignan los espacios de nombres XAML y WPF estándar intrínsecos a prefijos.
La sintaxis acepta los siguientes posibles tokens nombrados y los siguientes valores.
clr-namespace:
Espacio de nombres CLR declarado en el ensamblado que contiene los tipos públicos que se van a exponer como elementos.
assembly=
Ensamblado que contiene algunos o todos los espacios de nombres CLR a los que se hace referencia. Este valor suele ser solo el nombre del ensamblado, no la ruta de acceso y no incluye la extensión (por ejemplo, .dll o .exe). La ruta de acceso a ese ensamblado debe establecerse como referencia de proyecto en el archivo de proyecto que contiene el XAML que intenta asignar. Para incorporar el control de versiones y la firma de nombres seguros, el assembly
valor puede ser una cadena definida por AssemblyName, en lugar del nombre de cadena simple.
Tenga en cuenta que el carácter que separa el clr-namespace
token de su valor es un signo de dos puntos (:) mientras que el carácter que separa el assembly
token de su valor es un signo igual (=). El carácter que se va a usar entre estos dos tokens es un punto y coma. Además, no incluya ningún espacio en blanco en ninguna parte de la declaración.
Ejemplo básico de asignación personalizada
El código siguiente define una clase personalizada de ejemplo:
namespace SDKSample {
public class ExampleClass : ContentControl {
public ExampleClass() {
...
}
}
}
Namespace SDKSample
Public Class ExampleClass
Inherits ContentControl
...
Public Sub New()
End Sub
End Class
End Namespace
A continuación, esta clase personalizada se compila en una biblioteca, que por la configuración del proyecto (no se muestra) se denomina SDKSampleLibrary
.
Para hacer referencia a esta clase personalizada, también debe incluirla como referencia para el proyecto actual, que normalmente usaría la interfaz de usuario del Explorador de soluciones en Visual Studio.
Ahora que tienes una biblioteca que contiene una clase y una referencia a ella en la configuración del proyecto, puedes agregar la siguiente asignación de prefijo como parte del elemento raíz en XAML:
xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary"
Para integrar los elementos, el siguiente es el código XAML que incluye el mapeo personalizado junto con las asignaciones predeterminadas típicas y x: mapeos en la etiqueta raíz, y luego usa una referencia con prefijo para instanciar ExampleClass
en esa interfaz de usuario.
<Page x:Class="WPFApplication1.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary">
...
<custom:ExampleClass/>
...
</Page>
Mapeo a módulos actuales
assembly
se puede omitir si la clr-namespace
referenciada se está definiendo dentro del mismo ensamblado que el código de la aplicación que referencia las clases personalizadas. O bien, una sintaxis equivalente para este caso es especificar assembly=
, sin ningún token de cadena después del signo igual.
Las clases personalizadas no se pueden usar como elemento raíz de una página si se definen en el mismo ensamblado. No es necesario asignar clases parciales; solo las clases que no son la clase parcial de una página de la aplicación deben asignarse si piensas hacer referencia a ellas como elementos en XAML.
Asignación de espacios de nombres CLR a espacios de nombres XML en un ensamblado
WPF define un atributo CLR que consumen los procesadores XAML para asignar varios espacios de nombres CLR a un único espacio de nombres XAML. Este atributo, XmlnsDefinitionAttribute, se coloca en el nivel de ensamblado en el código fuente que genera el ensamblado. El código fuente del ensamblado WPF usa este atributo para asignar los distintos espacios de nombres comunes, como System.Windows y System.Windows.Controls, al espacio de nombres http://schemas.microsoft.com/winfx/2006/xaml/presentation
.
XmlnsDefinitionAttribute Toma dos parámetros: el nombre del espacio de nombres XML/XAML y el nombre del espacio de nombres CLR. Puede existir más de un XmlnsDefinitionAttribute para asignar varios espacios de nombres CLR al mismo espacio de nombres XML. Una vez asignados, también se puede hacer referencia a los miembros de esos espacios de nombres sin usar el nombre completo si se desea, proporcionando la instrucción adecuada using
en el archivo de código subyacente para la clase parcial. Para obtener más información, vea XmlnsDefinitionAttribute.
Espacios de nombres del diseñador y otros prefijos de plantillas XAML
Si estás trabajando con entornos de desarrollo o herramientas de diseño para XAML de WPF, puedes observar que hay otros espacios de nombres XAML o prefijos definidos dentro del marcado XAML.
WPF Designer para Visual Studio usa un espacio de nombres de diseñador que normalmente se asigna al prefijo d:
. Las plantillas de proyecto más recientes para WPF podrían asignar previamente este espacio de nombres XAML para admitir el intercambio de XAML entre WPF Designer para Visual Studio y otros entornos de diseño. Este espacio de nombres XAML de diseño se utiliza para perpetuar el estado de diseño mientras se intercambia de ida y vuelta la interfaz de usuario basada en XAML en el diseñador. También se usa para características como d:IsDataSource
, que habilitan orígenes de datos en tiempo de ejecución en un diseñador.
Otro prefijo que podrías ver asignado es mc:
.
mc:
es para la compatibilidad de marcado y aprovecha un patrón de compatibilidad de marcado que no es necesariamente específico de XAML. En cierta medida, las características de compatibilidad de marcado se pueden usar para intercambiar XAML entre marcos o a través de otros límites de implementación de respaldo, trabajar entre contextos de esquema XAML, proporcionar compatibilidad con modos limitados en diseñadores, etc. Para obtener más información sobre los conceptos de compatibilidad de marcado y cómo se relacionan con WPF, vea Características de lenguaje de compatibilidad de marcado (mc:).
WPF y carga de ensamblados
El contexto de esquema XAML para WPF se integra con el modelo de aplicación de WPF, que a su vez usa el concepto definido por CLR de AppDomain. En la secuencia siguiente se describe cómo el contexto de esquema XAML interpreta cómo cargar ensamblados o buscar tipos en tiempo de ejecución o tiempo de diseño, en función del uso de WPF y AppDomain otros factores.
Recorre iterativamente el AppDomain, buscando un ensamblado ya cargado que coincida completamente con el nombre, comenzando con el ensamblado más recientemente cargado.
Si el nombre está cualificado, llame a Assembly.Load(String) con el nombre cualificado.
Si el nombre corto + token de clave pública de un nombre calificado coincide con el ensamblado desde el cual fue cargado el marcado, devuelva ese ensamblado.
Utiliza el nombre corto + token de clave pública para llamar a Assembly.Load(String).
Si el nombre no está calificado, llame a Assembly.LoadWithPartialName.
El XAML suelto no utiliza el paso 3; no hay ningún ensamblado cargado desde un origen.
XAML compilado para WPF (generado a través de XamlBuildTask) no usa los ensamblados ya cargados desde AppDomain (paso 1). Además, el nombre nunca debe aparecer sin calificación en la salida de XamlBuildTask, por ello el paso 5 no se aplica.
BAML compilado (generado a través de PresentationBuildTask) usa todos los pasos, aunque BAML tampoco debe contener nombres de ensamblado no completos.
Consulte también
.NET Desktop feedback