Namespaces XAML e mapeamento de namespace para WPF XAML

Este tópico explica melhor a presença e a finalidade dos dois mapeamentos de namespace XAML frequentemente encontrados na marca raiz de um arquivo WPF XAML. Ele também descreve como produzir mapeamentos semelhantes para usar elementos que são definidos no seu próprio código e/ou em assemblies distintas.

O que é um namespace XAML

Um namespace XAML é realmente uma extensão do conceito de um namespace XML. As técnicas de especificação de um namespace XAML dependem da sintaxe do namespace XML, da convenção de usar URIs como identificadores de namespace, do uso de prefixos para fornecer um meio de fazer referência a vários namespaces da mesma fonte de marcação e assim por diante. O conceito principal adicionado à definição de XAML no namespace XML é que um namespace XAML representa tanto um escopo de exclusividade para usos de marcação como influencia a forma como as entidades de marcação podem ser suportadas por namespaces CLR específicos e assemblies referenciados. Esta última consideração também é influenciada pelo conceito de um contexto de esquema XAML. Mas, para fins de como o WPF funciona com namespaces XAML, você geralmente pode pensar em namespaces XAML em termos de um namespace XAML padrão, o namespace de linguagem XAML e quaisquer outros namespaces XAML mapeados por sua marcação XAML diretamente para namespaces CLR de suporte específicos e assemblies referenciados.

As declarações de namespace WPF e XAML

Dentro das declarações de namespace na marca raiz de muitos arquivos XAML, você verá que normalmente há duas declarações de namespace XML. A primeira declaração mapeia o namespace XAML geral do cliente WPF / framework como padrão:

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

A segunda declaração mapeia um namespace XAML separado, mapeando-o (normalmente) para o prefixo x: .

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

A relação entre essas declarações é que o mapeamento de prefixo x: suporta os intrínsecos que fazem parte da definição de linguagem XAML, e WPF é uma implementação que usa XAML como uma linguagem e define um vocabulário de seus objetos para XAML. Como os usos do vocabulário WPF serão muito mais comuns do que os usos intrínsecos do XAML, o vocabulário do WPF é mapeado como padrão.

A x: convenção de prefixo para mapear o suporte intrínseco à linguagem XAML é seguida por modelos de projeto, código de exemplo e a documentação de recursos de linguagem neste SDK. O namespace XAML define muitos recursos comumente usados que são necessários até mesmo para aplicativos WPF básicos. Por exemplo, para unir qualquer code-behind a um ficheiro XAML através de uma classe parcial, deves nomear essa classe como atributo x:Class no elemento raiz do ficheiro XAML relevante. Ou, qualquer elemento conforme definido em uma página XAML que você deseja acessar como um recurso com chave deve ter o x:Key atributo definido no elemento em questão. Para obter mais informações sobre esses e outros aspetos do XAML, consulte XAML em WPF ou Sintaxe XAML em detalhes.

Mapeamento para classes personalizadas e conjuntos personalizados

Você pode mapear namespaces XML para assemblies, utilizando uma série de tokens numa declaração de prefixo xmlns, semelhante a como os namespaces XAML intrínsecos padrão do WPF são mapeados para prefixos.

A sintaxe usa os seguintes possíveis tokens nomeados e os seguintes valores:

clr-namespace: O namespace CLR declarado no assembly que contém os tipos públicos que serão expostos como elementos.

assembly= O assembly que contém parte ou todo o namespace CLR referenciado. Esse valor normalmente é apenas o nome do assembly, não o caminho, e não inclui a extensão (como .dll ou .exe). O caminho para esse assembly deve ser estabelecido como uma referência de projeto no arquivo de projeto que contém o XAML que você está tentando mapear. Para incorporar versionamento e assinatura de nome forte, o valor assembly pode ser uma cadeia de caracteres conforme definido por AssemblyName, em vez do nome simples.

Observe que o caractere que separa o clr-namespace token de seu valor é dois pontos (:) enquanto o caractere que separa o assembly token de seu valor é um sinal de igual (=). O caractere a ser usado entre esses dois tokens é um ponto-e-vírgula. Além disso, não inclua nenhum espaço em branco em nenhum lugar da declaração.

Um exemplo de mapeamento personalizado básico

O código a seguir define um exemplo de classe personalizada:

namespace SDKSample {
    public class ExampleClass : ContentControl {
        public ExampleClass() {
        ...
        }
    }
}

Namespace SDKSample
    Public Class ExampleClass
        Inherits ContentControl
         ...
        Public Sub New()
        End Sub
    End Class
End Namespace

Essa classe personalizada é então compilada em uma biblioteca, que de acordo com as configurações do projeto (não mostradas) é chamada SDKSampleLibrary.

Para fazer referência a essa classe personalizada, você também precisa incluí-la como uma referência para seu projeto atual, o que normalmente faria usando a interface do usuário do Gerenciador de Soluções no Visual Studio.

Agora que você tem uma biblioteca contendo uma classe e uma referência a ela nas configurações do projeto, você pode adicionar o seguinte mapeamento de prefixo como parte do seu elemento raiz em XAML:

xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary"

Para integrar tudo, aqui está o XAML que inclui o mapeamento personalizado juntamente com os mapeamentos padrão típicos e x: no elemento raiz, e depois usa uma referência prefixada para instanciar ExampleClass nessa interface do utilizador.

<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>

Mapeando para assemblies atuais

assembly pode ser omitida se o clr-namespace referenciado estiver sendo definido dentro do mesmo assembly que o código do aplicativo que está fazendo referência às classes personalizadas. Ou, uma sintaxe equivalente para este caso é especificar assembly=, sem nenhuma cadeia de caracteres após o sinal de igual.

As classes personalizadas não podem ser usadas como o elemento raiz de uma página se definidas no mesmo assembly. As classes parciais não precisam ser mapeadas; somente as classes que não são a classe parcial de uma página em seu aplicativo precisam ser mapeadas se você pretende fazer referência a elas como elementos em XAML.

Mapeando namespaces CLR para namespaces XML em um assembly

O WPF define um atributo CLR que é consumido por processadores XAML para mapear vários namespaces CLR para um único namespace XAML. Esse atributo, XmlnsDefinitionAttribute, é colocado no nível do assembly no código-fonte que produz o assembly. O código-fonte do assembly WPF usa esse atributo para mapear os vários namespaces comuns, como System.Windows e System.Windows.Controls, para o http://schemas.microsoft.com/winfx/2006/xaml/presentation namespace.

O XmlnsDefinitionAttribute usa dois parâmetros: o nome do namespace XML/XAML e o nome do namespace CLR. Mais de um XmlnsDefinitionAttribute pode existir para mapear vários namespaces CLR para o mesmo namespace XML. Uma vez mapeados, os membros desses namespaces também podem ser referenciados sem qualificação completa, se desejado, fornecendo a instrução apropriada using na página code-behind de classe parcial. Para obter mais detalhes, veja XmlnsDefinitionAttribute.

Namespaces de Designer e outros prefixos de templates XAML

Se você estiver trabalhando com ambientes de desenvolvimento e/ou ferramentas de design para WPF XAML, poderá notar que há outros namespaces/prefixos XAML definidos dentro da marcação XAML.

WPF Designer para Visual Studio usa um namespace de designer que normalmente é mapeado para o prefixo d:. Modelos de projeto mais recentes para WPF podem pré-mapear esse namespace XAML para dar suporte ao intercâmbio do XAML entre o WPF Designer for Visual Studio e outros ambientes de design. Este namespace XAML de design é utilizado para preservar o estado de design enquanto mantém a integridade da interface de utilizador baseada em XAML no designer. Também é usado para funcionalidades como d:IsDataSource, que permitem fontes de dados de tempo de execução num designer.

Outro prefixo que você pode ver mapeado é mc:. mc: é para compatibilidade de marcação e está aproveitando um padrão de compatibilidade de marcação que não é necessariamente específico de XAML. Até certo ponto, as funcionalidades de compatibilidade de marcação podem ser usadas para trocar XAML entre frameworks ou através de outras fronteiras de implementação de suporte, trabalhar entre contextos de esquema XAML, fornecer compatibilidade para modos restritos em designers e assim por diante. Para obter mais informações sobre conceitos de compatibilidade de marcação e como eles se relacionam com o WPF, consulte Recursos de linguagem de compatibilidade de marcação (mc:).

WPF e carregamento de assemblies

O contexto de esquema XAML para WPF integra-se com o modelo de aplicação WPF, que, por sua vez, usa o conceito definido pelo CLR de AppDomain. A sequência a seguir descreve como o contexto do esquema XAML interpreta como carregar assemblies ou localizar tipos em tempo de execução ou tempo de design, com base no uso do AppDomain WPF e em outros fatores.

Itere através do AppDomain, procurando um assembly já carregado que corresponda a todos os aspetos do nome, começando pelo assembly carregado mais recentemente.
Se o nome for qualificado, chame Assembly.Load(String) no nome qualificado.
Se o nome curto + token de chave pública de um nome qualificado corresponder ao assembly do qual a marcação foi carregada, retorne esse assembly.
Use o nome curto + token de chave pública para chamar Assembly.Load(String).
Se o nome não estiver qualificado, chame Assembly.LoadWithPartialName.

XAML solto não usa a Etapa 3; não há montagem carregada.

O XAML compilado para WPF (gerado via XamlBuildTask) não usa os assemblies já carregados de AppDomain (Etapa 1). Além disso, o nome nunca deve ser desqualificado da saída XamlBuildTask, portanto, a Etapa 5 não se aplica.

O BAML compilado (gerado via PresentationBuildTask) usa todas as etapas, embora o BAML também não deva conter nomes de assembly não qualificados.

Ver também

Feedback

Esta página foi útil?

Last updated on 2025-05-07