Spazi dei nomi XAML e mapping dello spazio dei nomi per XAML WPF

2025-05-07

Questo argomento illustra ulteriormente la presenza e lo scopo dei due mapping dello spazio dei nomi XAML, come spesso si trova nel tag radice di un file XAML WPF. Viene inoltre descritto come produrre mapping simili per l'uso di elementi definiti nel codice e/o all'interno di assembly separati.

Che cos'è uno spazio dei nomi XAML

Uno spazio dei nomi XAML è davvero un'estensione del concetto di spazio dei nomi XML. Le tecniche di specificare uno spazio dei nomi XAML si basano sulla sintassi dello spazio dei nomi XML, sulla convenzione di usare gli URI come identificatori dello spazio dei nomi, usando prefissi per fornire un modo per fare riferimento a più spazi dei nomi dalla stessa origine di markup e così via. Il concetto principale che viene aggiunto alla definizione XAML dello spazio dei nomi XML è che uno spazio dei nomi XAML implica sia un ambito di univocità per gli utilizzi del markup, sia il modo in cui le entità di markup sono potenzialmente supportate da spazi dei nomi CLR specifici e assembly a cui si fa riferimento. Questa seconda considerazione è influenzata anche dal concetto di contesto dello schema XAML. Tuttavia, ai fini del funzionamento di WPF con gli spazi dei nomi XAML, è in genere possibile considerare gli spazi dei nomi XAML in termini di spazio dei nomi XAML predefinito, lo spazio dei nomi del linguaggio XAML e qualsiasi altro spazio dei nomi XAML mappato direttamente dal markup XAML a specifici spazi dei nomi CLR e assembly a cui si fa riferimento.

Dichiarazioni dello spazio dei nomi WPF e XAML

All'interno delle dichiarazioni dello spazio dei nomi nel tag radice di molti file XAML, noterai che solitamente sono presenti due dichiarazioni dello spazio dei nomi XML. La prima dichiarazione esegue il mapping dello spazio dei nomi XAML client/framework WPF complessivo come predefinito:

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

La seconda dichiarazione esegue il mapping di uno spazio dei nomi XAML separato, associandolo (in genere) al x: prefisso.

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

La relazione tra queste dichiarazioni è che il x: mapping dei prefissi supporta gli intrinseci che fanno parte della definizione del linguaggio XAML e WPF è un'implementazione che usa XAML come linguaggio e definisce un vocabolario dei relativi oggetti per XAML. Poiché gli utilizzi del vocabolario WPF saranno molto più comuni rispetto agli utilizzi intrinseci XAML, il vocabolario WPF viene mappato come predefinito.

La x: convenzione di prefisso per il mapping del supporto intrinseco del linguaggio XAML è seguita dai modelli di progetto, dal codice di esempio e dalla documentazione delle funzionalità del linguaggio in questo SDK. Lo spazio dei nomi XAML definisce molte funzionalità di uso comune necessarie anche per le applicazioni WPF di base. Ad esempio, per unire qualsiasi code-behind a un file XAML tramite una classe parziale, devi denominare tale classe come attributo nell'elemento x:Class radice del file XAML pertinente. In alternativa, qualsiasi elemento come definito in una pagina XAML a cui vuoi accedere come risorsa con chiave deve avere l'attributo x:Key impostato sull'elemento in questione. Per altre informazioni su questi e altri aspetti di XAML, vedi XAML in WPF o sintassi XAML in dettaglio.

Mapping verso classi personalizzate e assembly

È possibile eseguire il mapping degli spazi dei nomi XML agli assembly usando una serie di token all'interno di una dichiarazione di prefisso xmlns, in modo analogo a come gli spazi dei nomi standard di WPF e XAML-intrinsics vengono mappati ai prefissi.

La sintassi accetta i token denominati seguenti e i valori seguenti:

clr-namespace: Spazio dei nomi CLR dichiarato all'interno dell'assembly che contiene i tipi pubblici da esporre come elementi.

assembly= Assembly che contiene alcuni o tutti gli spazi dei nomi CLR a cui si fa riferimento. Questo valore è in genere solo il nome dell'assembly, non il percorso e non include l'estensione , ad esempio .dll o .exe. Il percorso di tale assembly deve essere stabilito come riferimento al progetto nel file di progetto che contiene il codice XAML di cui si sta tentando di eseguire il mapping. Per incorporare il controllo delle versioni e la firma con nome sicuro, il assembly valore può essere una stringa definita da AssemblyName, anziché dal nome della stringa semplice.

Si noti che il carattere che separa il clr-namespace token dal valore è costituito da due punti (:) mentre il carattere che separa il assembly token dal relativo valore è un segno di uguale (=). Il carattere da usare tra questi due token è un punto e virgola. Inoltre, non includere spazi vuoti in nessun punto della dichiarazione.

Esempio di mapping personalizzato di base

Il codice seguente definisce una classe personalizzata di esempio:

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

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

Questa classe personalizzata viene quindi compilata in una libreria, che in base alle impostazioni del progetto (non visualizzate) è denominata SDKSampleLibrary.

Per fare riferimento a questa classe personalizzata, è necessario includerla anche come riferimento nel progetto corrente, cosa che in genere si fa utilizzando l'interfaccia utente di Esplora Soluzioni in Visual Studio.

Ora che hai una libreria contenente una classe e un riferimento ad essa nelle impostazioni del progetto, puoi aggiungere il mapping del prefisso seguente come parte dell'elemento radice in XAML:

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

Per riunire tutto, il codice XAML seguente include il mapping personalizzato insieme al mapping predefinito e x: mapping nella radice del tag, quindi utilizza un riferimento con prefisso per creare l'istanza ExampleClass nell'interfaccia utente.

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

Mapping agli assembly correnti

assembly può essere omesso se il clr-namespace riferimento viene definito all'interno dello stesso assembly del codice dell'applicazione che fa riferimento alle classi personalizzate. In alternativa, una sintassi equivalente per questo caso consiste nell'specificare assembly=, senza token stringa dopo il segno di uguale.

Le classi personalizzate non possono essere utilizzate come elemento radice di una pagina se definite nello stesso assembly. Non è necessario eseguire il mapping delle classi parziali; solo le classi che non sono la classe parziale di una pagina nell'applicazione devono essere mappate se si intende farvi riferimento come elementi in XAML.

Mapping degli spazi dei nomi CLR agli spazi dei nomi XML in un assembly

WPF definisce un attributo CLR utilizzato dai processori XAML per eseguire il mapping di più spazi dei nomi CLR a un singolo spazio dei nomi XAML. Questo attributo, XmlnsDefinitionAttribute, viene inserito a livello di assembly nel codice sorgente che produce l'assembly. Il codice sorgente dell'assembly WPF utilizza questo attributo per mappare i vari spazi dei nomi comuni, come System.Windows e System.Windows.Controls, allo spazio dei nomi http://schemas.microsoft.com/winfx/2006/xaml/presentation.

XmlnsDefinitionAttribute accetta due parametri: il nome dello spazio dei nomi XML/XAML e il nome dello spazio dei nomi CLR. Più di un XmlnsDefinitionAttribute può esistere per eseguire il mapping di più spazi dei nomi CLR allo stesso spazio dei nomi XML. Dopo il mapping, i membri di tali namespace possono anche essere referenziati senza qualificazione completa, se desiderato, fornendo l'istruzione appropriata using nella pagina code-behind della classe parzialmente. Per altri dettagli, vedere XmlnsDefinitionAttribute.

Namespace del progettista e altri prefissi dai modelli XAML

Se si usano ambienti di sviluppo e/o strumenti di progettazione per XAML WPF, è possibile notare che nel markup XAML sono presenti altri spazi dei nomi/prefissi XAML definiti.

Designer WPF per Visual Studio usa uno spazio dei nomi del designer di cui viene in genere eseguito il mapping al prefisso d:. I modelli di progetto più recenti per WPF potrebbero pre-mappare questo spazio dei nomi XAML per supportare l'interscambio del codice XAML tra WPF Designer per Visual Studio e altri ambienti di progettazione. Questo spazio dei nomi XAML di progettazione viene utilizzato per perpetuare lo stato di progettazione durante il roundtripping dell'interfaccia utente basata su XAML nell'ambiente di progettazione. Viene anche usato per funzionalità come d:IsDataSource, che abilitano le origini dati di runtime in un designer.

Un altro prefisso che potrebbe essere visualizzato è mc:. mc: è per la compatibilità del markup e sfrutta un modello di compatibilità di markup che non è necessariamente specifico di XAML. In alcuni casi, le funzionalità di compatibilità del markup possono essere usate per scambiare XAML tra framework o superare altri confini di implementazione di supporto, lavorare tra contesti di schema XAML, garantire la compatibilità per le modalità limitate negli strumenti di progettazione e così via. Per altre informazioni sui concetti relativi alla compatibilità dei markup e sulla relativa correlazione con WPF, vedere Funzionalità del linguaggio mc:.

Caricamento di WPF e assembly

Il contesto dello schema XAML per WPF si integra con il modello di applicazione WPF, che a sua volta usa il concetto definito da CLR di AppDomain. La sequenza seguente descrive il modo in cui il contesto dello schema XAML interpreta come caricare assembly o trovare tipi in fase di esecuzione o in fase di progettazione, in base all'uso wpf di AppDomain e ad altri fattori.

Iterare attraverso il AppDomain, cercando un assembly già caricato che corrisponda a tutti gli aspetti del nome, a partire dall'assembly caricato più di recente.
Se il nome è qualificato, invocare Assembly.Load(String) sul nome qualificato.
Se il nome breve + token di chiave pubblica di un nome qualificato corrisponde all'assembly da cui è stato caricato il markup, restituire tale assembly.
Usare il nome breve e il token di chiave pubblica per chiamare Assembly.Load(String).
Se il nome non è qualificato, chiamare Assembly.LoadWithPartialName.

XAML disconnesso non fa uso del passaggio 3; non esiste alcun assembly da cui viene caricato.

XAML compilato per WPF (generato tramite XamlBuildTask) non usa gli assembly già caricati da AppDomain (passaggio 1). Inoltre, il nome non deve mai essere omesso dall'output di XamlBuildTask, quindi il passaggio 5 non si applica.

BAML compilato (generato tramite PresentationBuildTask) usa tutti i passaggi, anche se BAML non deve contenere nomi di assembly non qualificati.