XamlMember Class

Provides the XAML type system identifier for members of XAML types. The identifier is used by XAML readers and XAML writers during processing of member nodes (when the XAML reader is positioned on a StartMember) and also for general XAML type system logic.

Initializes a new instance of the XamlMember class using a string name and declaring XamlType information. A XamlMember that is constructed with this signature has significant limitations; see Remarks.

XamlMember can use three methodologies for returning information about a XAML member: standard common language runtime (CLR) reflection; a reference-only reflection technique calling internal APIs that use optimized bit flags; or calling into virtual overrides of the Lookup* API that is provided by possible XamlMember subclasses. For most uses of .NET Framework XAML Services APIs and the XamlMember API, you use the default XAML schema context. The default XAML schema context for .NET Framework XAML Services uses CLR backing for the type system. This enables the XAML readers and XAML writers to work with any type or member that is defined in, or otherwise available to, the CLR and its reflection techniques.

Lookup* APIs and XamlMember Derived Classes

XamlMember defines several virtual members that derived classes might override. These members have names that always start with the string Lookup. The remainder of the API name then references the property that the virtual method influences. For example, a XamlMember derived class might override LookupTargetType to influence what the base-defined property TargetType returns in a derived class. You can predict return values for such properties in XamlMember or existing derived classes by reading the documentation for the relevant Lookup* methods.

The purpose of the Lookup* methods is to provide a XAML type system extension technique that incorporates the XamlMember base class. By deriving from XamlMember and overriding the Lookup virtual members, you can define the concept of a XAML member for a XAML schema in a XAML type system without being tied to the specifics of a backing type system or technology. You can also use a provided XAML schema context under this scheme and still return the results you want.

As an example, consider the XamlMember property IsWritePublic. This property informs callers that operations such as using a XamlWriter for serialization can write a value for this member on a target object. In the default implementation, the determination of whether the member is writable is made by using reflection techniques against the backing CLR Type and its members (the MemberInfo). Therefore, by default, the XAML type system depends on the CLR type system. However, you can remove this dependency for your XAML type system reporting of IsWritePublic by overriding the API LookupIsWritePublic. Within your override, you can use other determinations, such as metadata that is specific to your technology, a master lookup table that is optimized for a fixed XAML vocabulary, or a variety of other strategies for determining whether a XAML member is writable in your XAML vocabulary.

Constructing XamlMember Without XAML Schema Context

Most constructors of XamlMember require a XamlSchemaContext as part of their initialization. The XamlSchemaContext is also necessary for many internal XamlSchemaContext operations, such as obtaining information that is being forwarded from the backing type. When you are working with the XamlMember API, you typically have a XamlSchemaContext that is available from a surrounding construct such as a XamlWriter. In this case, you can pass the XamlSchemaContext reference through to all XAML type system calls that require a XAML schema context.

You should not construct a XamlMember that has a value of true for IsUnknown unless your implementation can handle the exceptions from XamlObjectWriter, or you have other ways to adjust the XamlObjectWriter behavior. For example, one or more of the following might be true of your implementation: