Typy migrowane z WPF do System.Xaml

W .NET Framework 3.5 i .NET Framework 3.0, zarówno w programie Windows Presentation Foundation (WPF), jak i w programie Windows Workflow Foundation uwzględniono implementację języka XAML. Wiele typów publicznych, które zapewniały rozszerzalność implementacji WPF XAML, istniało w zestawach WindowsBase, PresentationCore i PresentationFramework. Podobnie typy publiczne, które zapewniały rozszerzalność Windows Workflow Foundation XAML istniały w zestawie System.Workflow.ComponentModel. W .NET Framework 4 niektóre typy związane z XAML zostały zmigrowane do zestawu System.Xaml. Wspólna implementacja .NET Framework języka XAML umożliwia wiele scenariuszy rozszerzalności XAML, które zostały pierwotnie zdefiniowane przez implementację XAML określonej struktury, ale są teraz częścią ogólnej obsługi języka XAML .NET Framework 4. W tym artykule wymieniono typy, które zostały zmigrowane, oraz omówiono problemy związane z migracją.

Zestawy i przestrzenie nazw

W .NET Framework 3.5 i .NET Framework 3.0 typy implementowane przez WPF do obsługi języka XAML zazwyczaj były w przestrzeni System.Windows.Markup nazw . Większość tych typów była w zestawie WindowsBase.

W .NET Framework 4 istnieje nowa System.Xaml przestrzeń nazw i nowy zestaw System.Xaml. Wiele typów, które były pierwotnie implementowane dla języka WPF XAML, jest teraz dostarczanych jako punkty rozszerzalności lub usługi dla dowolnej implementacji języka XAML. W ramach ich tworzenia dla bardziej ogólnych scenariuszy typy są przekazywane z oryginalnego zestawu WPF do zestawu System.Xaml. Umożliwia to scenariusze rozszerzalności XAML bez konieczności dołączania zestawów innych platform (takich jak WPF i Windows Workflow Foundation).

W przypadku migrowanych typów większość typów pozostaje w przestrzeni System.Windows.Markup nazw . Było to częściowo w celu uniknięcia przerywania mapowania przestrzeni nazw CLR w istniejących implementacjach na podstawie pliku. W związku System.Windows.Markup z tym przestrzeń nazw w programie .NET Framework 4 zawiera połączenie ogólnych typów obsługi języka XAML (z zestawu System.Xaml) i typów specyficznych dla implementacji WPF XAML (z bazy danych WindowsBase i innych zestawów WPF). Każdy typ, który został zmigrowany do system.xaml, ale istniał wcześniej w zestawie WPF, ma obsługę przekazywania dalej typu w wersji 4 zestawu WPF.

Typy obsługi języka XAML przepływu pracy

Windows Workflow Foundation również zapewniała typy obsługi języka XAML i w wielu przypadkach miały one identyczne krótkie nazwy co odpowiednik WPF. Poniżej znajduje się lista typów obsługi języka XAML Windows Workflow Foundation:

Te typy obsługi nadal istnieją w zestawach programu Windows Workflow Foundation dla programu .NET Framework 4 i mogą być nadal używane dla określonych aplikacji programu Windows Workflow Foundation. Jednak nie powinny się do nich odwoływać aplikacje ani struktury, które nie korzystają z programu Windows Workflow Foundation.

MarkupExtension

W wersji .NET Framework 3.5 i .NET Framework 3.0 klasa MarkupExtension dla platformy WPF była w zestawie WindowsBase. Klasa równoległa dla Windows Workflow Foundation, MarkupExtension, istniała w zestawie System.Workflow.ComponentModel. W .NET Framework 4 klasa MarkupExtension jest migrowana do zestawu System.Xaml. W programie .NET Framework 4 MarkupExtension program jest przeznaczony dla każdego scenariusza rozszerzalności XAML, który korzysta z usług XAML .NET, a nie tylko dla tych, które są kompilowane na określonych platformach. Jeśli to możliwe, określone struktury lub kod użytkownika w tej platformie również powinny być kompilowane na klasie MarkupExtension rozszerzenia XAML.

Klasy usług obsługi MarkupExtension

.NET Framework 3.5 i .NET Framework 3.0 dla WPF MarkupExtension zapewniały kilka usług, które były dostępne dla implementatorów TypeConverter i implementacji do obsługi użycia typu/właściwości w języku XAML. Są to następujące usługi:

Uwaga

Inną usługą z .NET Framework 3.5, która jest powiązana z rozszerzeniami znaczników, jest IReceiveMarkupExtension interfejs . IReceiveMarkupExtensionnie został zmigrowany i został oznaczony [Obsolete] do .NET Framework 4. Scenariusze, które były wcześniej używane IReceiveMarkupExtension , powinny zamiast tego używać wywołań XamlSetMarkupExtensionAttribute zwrotnych z przypisanymi wynikami. AcceptedMarkupExtensionExpressionTypeAttribute Jest również oznaczony jako [Obsolete].

Funkcje języka XAML

Kilka funkcji i składników języka XAML dla platformy WPF istniało wcześniej w zestawie PresentationFramework. Zostały one zaimplementowane jako podklasa MarkupExtension w celu uwidocznić użycie rozszerzeń znaczników w znacznikach XAML. W .NET Framework 4 istnieją one w zestawie System.Xaml, dzięki czemu projekty, które nie zawierają zestawów WPF, mogą używać tych funkcji na poziomie języka XAML. WPF używa tych samych implementacji dla .NET Framework 4 aplikacji. Podobnie jak w przypadku innych przypadków wymienionych w tym temacie, System.Windows.Markup typy obsługi nadal istnieją w przestrzeni nazw, aby uniknąć przerywania wcześniejszych odwołań.

W poniższej tabeli przedstawiono listę klas obsługi funkcji JĘZYKA XAML zdefiniowanych w pliku System.Xaml.

Funkcja języka XAML Użycie
ArrayExtension <x:Array ...>
NullExtension {x:Null}
StaticExtension {x:Static ...}
TypeExtension {x:Type ...}

Mimo że System.Xaml może nie mieć określonych klas obsługi, ogólna logika przetwarzania funkcji języka dla języka XAML znajduje się teraz w pliku System.Xaml i jego zaimplementowanych czytnikach XAML i autorzy kodu XAML. x:TypeArguments Na przykład to atrybut, który jest przetwarzany przez czytniki XAML i autorzy XAML z implementacji System.Xaml; można go zauważyć w strumieniu węzła XAML, ma obsługę w domyślnym kontekście schematu XAML (oparty na clr), ma reprezentację systemu typu XAML i tak dalej. Aby uzyskać więcej informacji na temat dokumentacji referencyjnej dla języka XAML, zobacz Usługi XAML.

Klasy ValueSerializer i supporting

Klasa ValueSerializer obsługuje konwersję typu na ciąg, szczególnie w przypadku przypadków serializacji XAML, w których serializacja może wymagać wielu trybów lub węzłów w danych wyjściowych. W .NET Framework 3.5 i .NET Framework 3.0 ValueSerializer dla platformy WPF był w zestawie WindowsBase. W .NET Framework 4 ValueSerializer klasa znajduje się w pliku System.Xaml i jest przeznaczona dla każdego scenariusza rozszerzalności XAML, a nie tylko dla tych, które są kompilowane w WPF. IValueSerializerContext Elementy (usługa obsługująca) i DateTimeValueSerializer (konkcyjna podklasa) są również migrowane do pliku System.Xaml.

WPF XAML zawiera kilka atrybutów, które można zastosować do typów CLR, aby wskazać coś o ich zachowaniu XAML. Poniżej znajduje się lista atrybutów, które istniały w zestawach WPF w .NET Framework 3.5 i .NET Framework 3.0. Te atrybuty są migrowane do system.xaml w .NET Framework 4.

Różne klasy

Interfejs IComponentConnector istniał w bazie WindowsBase w wersjach .NET Framework 3.5 i .NET Framework 3.0, ale istnieje w pliku System.Xaml w wersji .NET Framework 4. IComponentConnector Jest przeznaczony głównie do obsługi narzędzi i kompilatorów znaczników XAML.

Interfejs INameScope istniał w bazie WindowsBase w wersjach .NET Framework 3.5 i .NET Framework 3.0, ale istnieje w pliku System.Xaml w wersji .NET Framework 4. INameScope Definiuje podstawowe operacje dla zakresów nazw XAML.

Następujące klasy istnieją zarówno w zestawach WPF, jak i w zestawie System.Xaml w .NET Framework 4:

XamlReader

XamlWriter

XamlParseException

Implementacja WPF znajduje się w przestrzeni nazw System.Windows.Markup i zestawie PresentationFramework. Implementacja System.Xaml znajduje się w przestrzeni System.Xaml nazw . Jeśli używasz typów WPF lub wyprowadzasz typy WPF, zazwyczaj należy używać implementacji WPF XamlReaderXamlWriter elementów i zamiast implementacji System.Xaml. Aby uzyskać więcej informacji, zobacz uwagi w i System.Windows.Markup.XamlReaderSystem.Windows.Markup.XamlWriter.

Jeśli dodajesz odwołania do zestawów WPF i System.Xaml, includeSystem.Windows.Markup a także używasz instrukcji dla przestrzeni nazw i System.Xaml , może być konieczne pełne kwalifikowanie wywołań do tych interfejsów API w celu rozpoznawania typów bez niejednoznaczności.