# Types migrated from WPF to System.Xaml

In .NET Framework 3.5 and .NET Framework 3.0, both Windows Presentation Foundation (WPF) and Windows Workflow Foundation included a XAML language implementation. Many of the public types that provided extensibility for the WPF XAML implementation existed in the WindowsBase, PresentationCore, and PresentationFramework assemblies. Likewise, public types that provided extensibility for Windows Workflow Foundation XAML existed in the System.Workflow.ComponentModel assembly. In the .NET Framework 4, some of the XAML-related types are migrated to the System.Xaml assembly. A common .NET Framework implementation of XAML language services enables many XAML extensibility scenarios that were originally defined by a specific framework's XAML implementation but are now part of overall .NET Framework 4 XAML language support. This topic lists the types that are migrated and discusses issues related to the migration.

## Assemblies and Namespaces

In .NET Framework 3.5 and .NET Framework 3.0, the types that WPF implemented to support XAML were generally in the System.Windows.Markup namespace. Most of these types were in the WindowsBase assembly.

In .NET Framework 4, there is a new System.Xaml namespace and a new System.Xaml assembly. Many of the types that were originally implemented for WPF XAML are now provided as extensibility points or services for any implementation of XAML. As part of making them available for more general scenarios, the types are type-forwarded from their original WPF assembly to the System.Xaml assembly. This enables XAML extensibility scenarios without having to include the assemblies of other frameworks (such as WPF and Windows Workflow Foundation).

For migrated types, most of the types remain in the System.Windows.Markup namespace. This was partially to avoid breaking CLR namespace mappings in existing implementations on a per-file basis. As a result, the System.Windows.Markup namespace in .NET Framework 4 contains a mixture of general XAML language support types (from the System.Xaml assembly) and types that are specific to the WPF XAML implementation (from WindowsBase and other WPF assemblies). Any type that was migrated to System.Xaml, but existed previously in a WPF assembly, has type-forwarding support in version 4 of the WPF assembly.

### Workflow XAML Support Types

Windows Workflow Foundation also provided XAML support types, and in many cases these had identical short names to a WPF equivalent. The following is a list of Windows Workflow Foundation XAML support types:

These support types still exist in the Windows Workflow Foundation assemblies for .NET Framework 4 and can still be used for specific Windows Workflow Foundation applications; however, they should not be referenced by applications or frameworks that do not use Windows Workflow Foundation.

## MarkupExtension

In the .NET Framework 3.5 and .NET Framework 3.0, the MarkupExtension class for WPF was in the WindowsBase assembly. A parallel class for Windows Workflow Foundation, MarkupExtension, existed in the System.Workflow.ComponentModel assembly. In the .NET Framework 4, the MarkupExtension class is migrated to the System.Xaml assembly. In the .NET Framework 4, MarkupExtension is intended for any XAML extensibility scenario that uses .NET Framework XAML Services, not just for those that build on specific frameworks. When possible, specific frameworks or user code in the framework should also build on the MarkupExtension class for XAML extension.

## MarkupExtension Supporting Service Classes

.NET Framework 3.5 and .NET Framework 3.0 for WPF provided several services that were available to MarkupExtension implementers and TypeConverter implementations to support type/property usage in XAML. These services are the following:

Note

Another service from .NET Framework 3.5 that is related to markup extensions is the IReceiveMarkupExtension interface. IReceiveMarkupExtension was not migrated and is marked [Obsolete] for .NET Framework 4. Scenarios that previously used IReceiveMarkupExtension should instead use XamlSetMarkupExtensionAttribute attributed callbacks. AcceptedMarkupExtensionExpressionTypeAttribute is also marked [Obsolete].

## XAML Language Features

Several XAML language features and components for WPF previously existed in the PresentationFramework assembly. These were implemented as a MarkupExtension subclass to expose markup extension usages in XAML markup. In .NET Framework 4, these exist in the System.Xaml assembly so that projects that do not include WPF assemblies can use these XAML language-level features. WPF uses these same implementations for .NET Framework 4 applications. As with the other cases that are listed in this topic, the supporting types continue to exist in the System.Windows.Markup namespace to avoid breaking previous references.

The following table contains a list of the XAML feature-support classes that are defined in System.Xaml.

XAML Language Feature Usage
ArrayExtension <x:Array ...>
NullExtension {x:Null}
StaticExtension {x:Static ...}
TypeExtension {x:Type ...}

Although System.Xaml may not have specific support classes, the general logic for processing language features for the XAML language now resides in System.Xaml and its implemented XAML readers and XAML writers. For example, x:TypeArguments is an attribute that is processed by XAML readers and XAML writers from System.Xaml implementations; it can be noted in the XAML node stream, has handling in the default (CLR-based) XAML schema context, has a XAML type-system representation, and so on. As a result, the reference documentation for all XAML language-level features is a subtopic for XAML Services and that general area of the .NET Framework documentation set, instead of being part of the WPF documentation set as a subtopic of Advanced (Windows Presentation Foundation) (as is still the case in 3.5 documentation sets).

## ValueSerializer and Supporting Classes

The ValueSerializer class supports type conversion to a string, particularly for XAML serialization cases where serialization may require multiple modes or nodes in the output. In .NET Framework 3.5 and .NET Framework 3.0, the ValueSerializer for WPF was in the WindowsBase assembly. In the .NET Framework 4, the ValueSerializer class is in System.Xaml and is intended for any XAML extensibility scenario, not just for those that build on WPF. IValueSerializerContext (a supporting service) and DateTimeValueSerializer (a specific subclass) are also migrated to System.Xaml.

WPF XAML included several attributes that can be applied to CLR types to indicate something about their XAML behavior. The following is a list of the attributes that existed in WPF assemblies in .NET Framework 3.5 and .NET Framework 3.0. These attributes are migrated to System.Xaml in .NET Framework 4.

## Miscellaneous Classes

The IComponentConnector interface existed in WindowsBase in .NET Framework 3.5 and .NET Framework 3.0, but exists in System.Xaml in .NET Framework 4. IComponentConnector is primarily intended for tooling support and XAML markup compilers.

The INameScope interface existed in WindowsBase in .NET Framework 3.5 and .NET Framework 3.0, but exists in System.Xaml in .NET Framework 4. INameScope defines basic operations for a XAML namescope.

The following classes exist in both the WPF assemblies and the System.Xaml assembly in .NET Framework 4:

XamlReader

XamlWriter

XamlParseException

The WPF implementation is found in the System.Windows.Markup namespace, and PresentationFramework assembly. The System.Xaml implementation is found in the System.Xaml namespace. If you are using WPF types or are deriving from WPF types, you should typically use the WPF implementations of XamlReader and XamlWriter instead of the System.Xaml implementations. For more information, see Remarks in System.Windows.Markup.XamlReader and System.Windows.Markup.XamlWriter.

If you are including references to both WPF assemblies and System.Xaml, and you also are using include statements for both the System.Windows.Markup and System.Xaml namespaces, you may need to fully qualify the calls to these APIs in order to resolve the types without ambiguity.