XAML-namnområden och namnområdesmappning för WPF XAML

2025-05-07

I det här avsnittet beskrivs ytterligare förekomsten och syftet med de två XAML-namnområdesmappningarna som ofta finns i rottaggen för en WPF XAML-fil. Den beskriver också hur du skapar liknande mappningar för att använda element som definieras i din egen kod och/eller inom separata sammansättningar.

Vad är ett XAML-namnområde

Ett XAML-namnområde är verkligen ett tillägg till begreppet XML-namnområde. Metoderna för att ange ett XAML-namnområde förlitar sig på syntaxen för XML-namnområdet, konventionen om att använda URI:er som namnområdesidentifierare, med hjälp av prefix för att ge ett sätt att referera till flera namnområden från samma markeringskälla och så vidare. Det primära konceptet som läggs till i XAML-definitionen för XML-namnområdet är att ett XAML-namnområde innebär både ett omfång av unikhet för markeringsanvändningarna och även påverkar hur påläggsentiteter potentiellt backas upp av specifika CLR-namnområden och refererade sammansättningar. Detta senare övervägande påverkas också av begreppet XAML-schemakontext. Men för hur WPF fungerar med XAML-namnområden kan du vanligtvis tänka på XAML-namnområden i termer av ett XAML-standardnamnområde, XAML-språknamnområdet och eventuella ytterligare XAML-namnområden som mappas av din XAML-markering direkt till specifika stöd-CLR-namnområden och refererade sammansättningar.

WPF- och XAML-namnområdesdeklarationerna

I namnområdesdeklarationerna i rottaggen för många XAML-filer ser du att det vanligtvis finns två XML-namnområdesdeklarationer. Den första deklarationen mappar den övergripande WPF-klienten/ramverkets XAML-namnområde som standard:

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

Den andra deklarationen mappar ett separat XAML-namnområde som mappar det (vanligtvis) till x: prefixet.

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

Relationen mellan dessa deklarationer är att x: prefixmappningen stöder de inbyggda objekt som ingår i XAML-språkdefinitionen, och WPF är en implementering som använder XAML som språk och definierar ett ordförråd för dess objekt för XAML. Eftersom WPF-vokabulärens användning är mycket vanligare än XAML-inbyggda användningar mappas WPF-vokabulären som standard.

Prefixkonventionen x: för mappning av stöd för XAML-språkets inbyggda språk följs av projektmallar, exempelkod och dokumentationen av språkfunktioner i denna SDK. XAML-namnområdet definierar många vanliga funktioner som är nödvändiga även för grundläggande WPF-program. Om du till exempel vill koppla kod bakom till en XAML-fil via en partiell klass, måste du namnge den klassen som x:Class attributet i rotelementet i den relevanta XAML-filen. Eller så bör alla element som definierats på en XAML-sida som du vill komma åt som en nyckelad resurs ha x:Key attributet inställt på det aktuella elementet. Mer information om dessa och andra aspekter av XAML finns i XAML i WPF - eller XAML-syntax i detalj.

Mappa till anpassade klasser och sammansättningar

Du kan mappa XML-namnområden till sammansättningar med hjälp av en serie token i en xmlns prefixdeklaration, liknande hur standard-WPF- och XAML-inbyggda XAML-namnområden mappas till prefix.

Syntaxen tar följande möjliga namngivna token och följande värden:

clr-namespace: CLR-namnområdet som deklareras i sammansättningen som innehåller de offentliga typer som ska exponeras som element.

assembly= Sammansättningen som innehåller en del av eller hela det refererade CLR-namnområdet. Det här värdet är vanligtvis bara namnet på sammansättningen, inte sökvägen, och inkluderar inte tillägget (till exempel .dll eller .exe). Sökvägen till den sammansättningen måste upprättas som en projektreferens i projektfilen som innehåller den XAML som du försöker mappa. För att kunna införliva versionshantering och signering assembly med starka namn kan värdet vara en sträng som definieras av AssemblyName, i stället för det enkla strängnamnet.

Observera att tecknet som skiljer clr-namespace token från dess värde är ett kolon (:) medan tecknet som assembly skiljer token från dess värde är ett likhetstecken (=). Tecknet som ska användas mellan dessa två token är ett semikolon. Ta heller inte med något tomt utrymme någonstans i deklarationen.

Ett exempel på grundläggande anpassad mappning

Följande kod definierar ett exempel på en anpassad klass:

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

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

Den här anpassade klassen kompileras sedan till ett bibliotek som enligt projektinställningarna (visas inte) heter SDKSampleLibrary.

För att kunna referera till den här anpassade klassen måste du även inkludera den som en referens för ditt aktuella projekt, vilket du vanligtvis gör med hjälp av Solution Explorer-användargränssnittet i Visual Studio.

Nu när du har ett bibliotek som innehåller en klass och en referens till den i projektinställningarna kan du lägga till följande prefixmappning som en del av rotelementet i XAML:

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

För att samla allt är följande en XAML som inkluderar den anpassade mappningen tillsammans med de typiska standard- och x:mappningarna i rottaggen, och därefter använder en prefixreferens för att instansiera ExampleClass i detta användargränssnitt.

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

Mappa till aktuella sammansättningar

assembly kan utelämnas om referensen clr-namespace definieras inom samma sammansättning som programkoden som refererar till de anpassade klasserna. Eller så är en motsvarande syntax för det här fallet att specificera assembly=, utan att ha en strängtoken efter likhetstecknet.

Anpassade klasser kan inte användas som rotelement på en sida om de definieras i samma sammansättning. Partiella klasser behöver inte mappas. Endast klasser som inte är delklassen för en sida i ditt program måste mappas om du tänker referera till dem som element i XAML.

Mappa CLR-namnområden till XML-namnområden i en sammansättning

WPF definierar ett CLR-attribut som används av XAML-processorer för att mappa flera CLR-namnområden till ett enda XAML-namnområde. Det här attributet, XmlnsDefinitionAttribute, placeras på sammansättningsnivå i källkoden som skapar sammansättningen. WPF-sammansättningskällan använder det här attributet för att mappa de olika gemensamma namnrymderna, till exempel System.Windows och System.Windows.Controls, till http://schemas.microsoft.com/winfx/2006/xaml/presentation namnområdet.

XmlnsDefinitionAttribute tar två parametrar: namnet på XML/XAML-namnområdet och namnet på CLR-namnområdet. Fler än en XmlnsDefinitionAttribute kan finnas för att mappa flera CLR-namnområden till samma XML-namnområde. När de har mappats kan elementen i dessa namnområden också refereras utan fullständig namnuppgift om så önskas genom att ange korrekt using instruktion på kodbakom-sidan för delvis klass. Mer information finns i XmlnsDefinitionAttribute.

Designernamnområden och andra prefix från XAML-mallar

Om du arbetar med utvecklingsmiljöer och/eller designverktyg för WPF XAML kanske du märker att det finns andra definierade XAML-namnområden/prefix i XAML-markering.

WPF Designer för Visual Studio använder ett designernamnområde som vanligtvis mappas till prefixet d:. Nyare projektmallar för WPF kan förmappa det här XAML-namnområdet för att stödja utbyte av XAML mellan WPF Designer för Visual Studio och andra designmiljöer. Den här designens XAML-namnområde används för att vidmakthålla designtillståndet vid avrundning av XAML-baserat användargränssnitt i designern. Den används också för funktioner som d:IsDataSource, vilka möjliggör körtidsdatakällor i en designer.

Ett annat prefix som du kan se mappat är mc:. mc: är för märkningens kompatibilitet och använder ett kompatibilitetsmönster för märkning som inte nödvändigtvis är XAML-specifikt. I viss utsträckning kan kompatibilitetsfunktionerna för markering användas för att utbyta XAML mellan ramverk eller över andra gränser för att stödja implementering, arbeta mellan XAML-schemakontexter, tillhandahålla kompatibilitet för begränsade lägen i designers och så vidare. Mer information om kompatibilitetsbegrepp för markup och hur de relaterar till WPF finns i Språkfunktioner för markeringskompatibilitet (mc:).

WPF och assembly-laddning

XAML-schemakontexten för WPF integreras med WPF-programmodellen, som i sin tur använder det CLR-definierade begreppet AppDomain. I följande sekvens beskrivs hur XAML-schemakontext tolkar hur man antingen laddar in assemblies (sammansättningar) eller hittar typer vid körtid eller designtid, baserat på WPF-användningen av AppDomain och andra faktorer.

Iterera genom AppDomain, letar efter en redan inläst sammansättning som matchar alla aspekter av namnet, med början från den senast inlästa sammansättningen.
Om namnet är kvalificerat, använd Assembly.Load(String) på det kvalificerade namnet.
Om det korta namnet + den offentliga nyckeltoken för ett kvalificerat namn matchar sammansättningen som markeringen lästes in från returnerar du sammansättningen.
Använd det korta namnet + den offentliga nyckeltoken för att anropa Assembly.Load(String).
Om namnet är okvalificerat anropar du Assembly.LoadWithPartialName.

Lös XAML använder inte steg 3; det finns ingen inläst-från-sammansättning.

Kompilerad XAML för WPF (som genereras via XamlBuildTask) använder inte de redan inlästa sammansättningarna från AppDomain (steg 1). Dessutom bör namnet aldrig vara okvalificerat från XamlBuildTask-utdata, så steg 5 gäller inte.

Kompilerad BAML (genereras via PresentationBuildTask) använder alla steg, även om BAML inte heller bör innehålla okvalificerade sammansättningsnamn.

Se även

Feedback

Var den här sidan till hjälp?