Identifies a recommended prefix to associate with a XAML namespace for XAML usage, when writing elements and attributes in a XAML file (serialization) or when interacting with a design environment that has XAML editing features.
Assembly: System.Xaml (in System.Xaml.dll)
Thetype exposes the following members.
|Equals||Infrastructure. Returns a value that indicates whether this instance is equal to a specified object. (Inherited from Attribute.)|
|GetHashCode||Returns the hash code for this instance. (Inherited from Attribute.)|
|GetType||Gets the Type of the current instance. (Inherited from Object.)|
|IsDefaultAttribute||When overridden in a derived class, indicates whether the value of this instance is the default value for the derived class. (Inherited from Attribute.)|
|Match||When overridden in a derived class, returns a value that indicates whether this instance equals a specified object. (Inherited from Attribute.)|
|ToString||Returns a string that represents the current object. (Inherited from Object.)|
|_Attribute.GetIDsOfNames||Maps a set of names to a corresponding set of dispatch identifiers. (Inherited from Attribute.)|
|_Attribute.GetTypeInfo||Retrieves the type information for an object, which can be used to get the type information for an interface. (Inherited from Attribute.)|
|_Attribute.GetTypeInfoCount||Retrieves the number of type information interfaces that an object provides (either 0 or 1). (Inherited from Attribute.)|
|_Attribute.Invoke||Provides access to properties and methods exposed by an object. (Inherited from Attribute.)|
XAML processors or frameworks that incorporate XAML, or any process that performs XAML serialization, should generally honor the recommended prefix. The prefix might be necessary in any case where prefixes from specific mappings in the original XAML source are not somehow preserved in the runtime object graph or otherwise stored by a framework or technology. A framework might have specific preferences for how to serialize its own types that ignore the recommended prefix from its own assemblies; this might be done to consistently promote a default XAML namespace. However, such a framework should still provide recommended prefixes for possible third-party and tool usages of its XAML types. See "Best Practice for XAML Designer Support or General Serialization" section below.
A general recommendation for prefixes is to use short strings, because the prefix is typically applied to all serialized elements that come from the XAML namespace. The prefix string length can have a noticeable effect on the size of serialized XAML output.
If a prefix being requested is already in use by another previously encountered/serialized XAML namespace identifier, the behavior is unspecified (behavior is up to each individual XAML processor implementation).
In most cases, you apply only if you have also applied at least one XmlnsDefinitionAttribute in the assembly for that same XAML namespace.
In previous versions of the .NET Framework, this class existed in the WPF-specific assembly WindowsBase. In .NET Framework 4, is in the System.Xaml assembly. For more information, see Types Migrated from WPF to System.Xaml.
Best Practice for XAML Designer Support or General Serialization
Even if you intend the associated XAML namespace to be the default XAML namespace in most usage cases for your framework or library, you should still specify a non-empty string as the recommended prefix for a XAML namespace. Default XAML namespace information is carried in individual XAML files and XAML node streams. The default XAML namespace and how it is defined in a given XAML source can easily be perpetuated for per-case serialization without using . However, the is useful for cases where the XAML author has chosen to map the default XAML namespace to something else. In this scenario a XAML text editor embedded in a design environment can use as a hint for an initial XAML namespace xmlns mapping. Or a design environment can add just-in-time mappings to the backing XAML for design metaphors such as dragging objects out of a toolbox and into a visual design surface. Also, it is conceivable that a designer could simultaneously support multiple XAML-enabling frameworks, and has a common XAML serializer that relies on .NET Framework XAML Services rather than framework-specific serialization. Specifying a for these scenarios helps make the XAML usage for your types more portable and robust if the XAML is exchanged between design tools, or undergoes a round trip between XAML editors and other consumers such as markup compilers or other serialization.