本主题介绍在大多数 XAML 文件的根元素中找到的 XML/XAML 命名空间 （xmlns） 映射。 它还介绍如何为自定义类型和程序集生成类似的映射。
XAML 命名空间与代码定义和类型库的关系
在常规用途中，以及用于 Windows 运行时应用编程的应用程序，XAML 用于声明对象、这些对象的属性以及表示为层次结构的对象属性关系。 在 XAML 中声明的对象由类型库或其他由其他编程技术和语言定义的表示形式提供支持。 这些库可能是：
- Windows 运行时的内置对象集。 这是一组固定的对象，从 XAML 访问这些对象将使用内部类型映射和激活逻辑。
- 由Microsoft或第三方提供的分布式库。
- 表示应用合并的第三方控件的定义和包重新分发的库。
- 你自己的库是项目的一部分，其中包含部分或全部用户代码定义。
后台类型信息与特定的 XAML 命名空间定义相关联。 XAML 框架（如 Windows 运行时）可以聚合多个程序集和多个代码命名空间，以映射到单个 XAML 命名空间。 这使 XAML 词汇的概念涵盖更大的编程框架或技术。 XAML 词汇可能相当广泛，例如，本参考中为 Windows 运行时应用记录的大多数 XAML 构成了单个 XAML 词汇。 XAML 词汇也是可扩展的：通过将类型添加到后盾代码定义来扩展它，确保将类型包含在已用作 XAML 词汇的映射命名空间源的代码命名空间中。
XAML 处理器可以在创建运行时对象表示形式时从与该 XAML 命名空间关联的后盾程序集中查找类型和成员。 这就是为什么 XAML 作为一种形式化和交换对象构造行为的定义的方法，以及 XAML 用作 Windows 运行时应用的 UI 定义技术的原因。
典型 XAML 标记用法中的 XAML 命名空间
XAML 文件几乎总是在其根元素中声明默认 XAML 命名空间。 默认 XAML 命名空间定义可以在不按前缀限定的情况下声明的元素。 例如，如果声明元素 <Balloon />，XAML 分析程序将期望元素 气球 存在并且在默认 XAML 命名空间中有效。 相反，如果气球不在定义的默认 XAML 命名空间中，则必须改为使用前缀限定该元素名称。<party:Balloon /> 前缀指示该元素存在于与默认命名空间不同的 XAML 命名空间中，并且必须先将 XAML 命名空间映射到前缀 方 ，然后才能使用此元素。 XAML 命名空间适用于声明它们的特定元素，也适用于 XAML 结构中该元素包含的任何元素。 因此，XAML 命名空间几乎总是在 XAML 文件的根元素上声明，以利用此继承。
默认 XAML 语言和 XAML 命名空间声明
在大多数 XAML 文件的根元素中，有两个 xmlns 声明。 第一个声明将 XAML 命名空间映射为默认值： xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
这与使用 XAML 作为 UI 定义标记格式的几种前代 Microsoft 技术中使用的 XAML 命名空间标识符相同。 使用同一标识符是故意的，当你使用 C++、C# 或 Visual Basic 将以前定义的 UI 迁移到 Windows 运行时应用时非常有用。
第二个声明将 XAML 定义的语言元素的单独 XAML 命名空间映射到“x：”前缀： xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
此 xmlns 值及其映射到的“x：”前缀也与使用 XAML 的多个前置Microsoft技术中使用的定义相同。
这些声明之间的关系是 XAML 是语言定义，Windows 运行时是一种实现，它使用 XAML 作为语言，并定义在 XAML 中引用其类型的特定词汇。
XAML 语言指定了某些语言元素，这些元素应该能通过针对 XAML 命名空间的 XAML 处理器实现进行访问。 XAML 语言的 XAML 命名空间“x:”映射约定被项目模板、示例代码和语言功能文档遵循。 XAML 语言命名空间定义了几个常用的功能，即使基本 Windows 运行时应用也是必需的。 例如，要通过分部类将任何后台代码链接到 XAML 文件，必须在相关 XAML 文件的根元素中将该类命名为 x:Class 属性。 或者，在 XAML 页面中定义为 ResourceDictionary 和 XAML 资源引用 中的键控资源的任何元素都必须对相关对象元素设置 x：Key 属性 。
映射到默认 XAML 命名空间的代码命名空间
下面是当前映射到默认 XAML 命名空间的代码命名空间的列表。
- Windows.UI
- Windows.UI.Xaml
- Windows.UI.Xaml.Automation
- Windows.UI.Xaml.Automation.Peers
- Windows.UI.Xaml.Automation.Provider
- Windows.UI.Xaml.Automation.Text
- Windows.UI.Xaml.Controls
- Windows.UI.Xaml.Controls.Primitives
- Windows.UI.Xaml.Data
- Windows.UI.Xaml.Documents
- Windows.UI.Xaml.Input
- Windows.UI.Xaml.Interop
- Windows.UI.Xaml.Markup
- Windows.UI.Xaml.Media
- Windows.UI.Xaml.Media.Animation
- Windows.UI.Xaml.Media.Imaging
- Windows.UI.Xaml.Media.Media3D
- Windows.UI.Xaml.Navigation
- Windows.UI.Xaml.Resources
- Windows.UI.Xaml.Shapes
- Windows.UI.Xaml.Threading
- Windows.UI.Text
其他 XAML 命名空间
除了默认命名空间和 XAML 语言 XAML 命名空间“x：”之外，还可以在由 Microsoft Visual Studio 生成的应用的初始默认 XAML 中看到其他映射的 XAML 命名空间。
d： （http://schemas.microsoft.com/expression/blend/2008）
“d:” XAML 命名空间是为设计器支持而设，特别是在 Microsoft Visual Studio 的 XAML 设计界面中提供设计器支持。 “d：”XAML 命名空间在 XAML 元素上启用设计器或设计时属性。 这些设计器属性仅影响 XAML 行为的设计方面。 当运行应用时，Windows 运行时 XAML 分析器加载相同的 XAML 时，将忽略设计器属性。 通常，设计器属性在任何 XAML 元素上都有效，但实际上，只有某些方案可以自行应用设计器属性。 具体而言，许多设计器属性旨在提供更好的体验，以便在开发使用数据绑定的 XAML 和代码时与数据上下文和数据源进行交互。
d：DesignHeight 和 d：DesignWidth 属性： 这些属性有时应用于 Visual Studio 或其他 XAML 设计器图面为你创建的 XAML 文件的根目录。 例如，如果向应用项目添加新 的 UserControl ，则会在 XAML 的 UserControl 根上设置这些属性。 通过这些属性，可以更轻松地设计 XAML 内容的组合，以便你对一旦 XAML 内容用于控件实例或较大 UI 页面的其他部分时可能存在的布局约束有一些预期。
注意 如果要从 Microsoft Silverlight 迁移 XAML，则可能在表示整个 UI 页面的根元素上具有这些属性。 在这种情况下，你可能想要删除这些属性。 XAML 设计器的其他功能（如模拟器）对于设计处理缩放和视图状态的页布局可能更有用，而不是使用 d：DesignHeight 和 d：DesignWidth 的固定大小页面布局。
d：DataContext 属性： 您可以在页面根或控件上设置此属性，以覆盖对象原本拥有的任何显式或继承的DataContext。
d：DesignSource 属性： 为 CollectionViewSource 指定设计时数据源，重写 源。
d：DesignInstance 和 d：DesignData 标记扩展： 这些标记扩展用于为 d：DataContext 或 d：DesignSource 提供设计时数据资源。 我们不会在此处全面记录如何使用设计时数据资源。 有关详细信息，请参阅 Design-Time 属性。 有关一些用法示例，请参阅 设计图面上的示例数据，以及用于原型制作。
mc： （http://schemas.openxmlformats.org/markup-compatibility/2006）
“mc：”指示并支持用于读取 XAML 的标记兼容性模式。 通常，“d：”前缀与属性 mc：Ignorable 相关联。 此技术使运行时 XAML 分析程序能够忽略“d：”中的设计属性。
本地： 和 通用：
“local：”是一个前缀，通常在模板化 UWP 应用项目的 XAML 页面中为你映射。 它被映射以引用同一命名空间，此命名空间是为容纳所有 XAML 文件（包括 app.xaml）的x:Class 属性和代码而创建的。 只要在同一命名空间中定义要在 XAML 中使用的任何自定义类，就可以使用 local： prefix 来引用 XAML 中的自定义类型。 来自模板化 UWP 应用项目的相关前缀很常见： 此前缀是指包含实用工具类（如转换器和命令）的嵌套“Common”命名空间，可以在 解决方案资源管理器 视图中的 Common 文件夹中找到定义。
vsm：
请勿使用。 “vsm：”是一个前缀，有时出现在从其他Microsoft技术导入的旧 XAML 模板中。 命名空间最初解决了旧命名空间工具问题。 应在用于 Windows 运行时的任何 XAML 中删除“vsm：”的 XAML 命名空间定义，并更改 VisualState、VisualStateGroup 和相关对象的任何前缀用法，以改用默认 XAML 命名空间。 有关 XAML 迁移的详细信息，请参阅 将 Silverlight 或 WPF XAML/代码迁移到 Windows 运行时应用。
将自定义类型映射到 XAML 命名空间和前缀
可以映射 XAML 命名空间，以便可以使用 XAML 访问自己的自定义类型。 换句话说，你将映射代码命名空间，因为它存在于定义自定义类型的代码表示形式中，并为其分配 XAML 命名空间以及用于使用的前缀。 可以使用 Microsoft .NET 语言（C# 或 Microsoft Visual Basic）或 C++ 定义 XAML 的自定义类型。 映射是通过定义 xmlns 前缀进行的。 例如，xmlns:myTypes 定义了一个新的 XAML 命名空间，可以通过在所有使用中添加前缀 myTypes: 来访问该命名空间。
xmlns 定义包括一个值以及前缀命名。 该值是一个位于等号后并被引号括起来的字符串。 常见的 XML 约定是将 XML 命名空间与统一资源标识符（URI）相关联，以便存在唯一性和标识约定。 你还会看到默认的 XAML 命名空间和 XAML 语言命名空间的约定，以及 Windows 运行时 XAML 使用的一些较少使用的 XAML 命名空间。 但是，对于映射自定义类型的 XAML 命名空间，不是指定 URI，而是用 "using:" 标记开始前缀定义。 按照“using：”令牌命名代码命名空间。
例如，若要映射一个“custom1”前缀，以便引用“CustomClasses”命名空间，并使用该命名空间或程序集中的类作为 XAML 中的对象元素，XAML 页面应包括根元素上的以下映射： xmlns:custom1="using:CustomClasses"
同一页面范围的部分类不需要映射。 例如，不需要前缀来引用为处理页面的 XAML UI 定义中的事件而定义的任何事件处理程序。 此外，来自 Visual Studio 的许多起始 XAML 页面为 Windows 运行时应用生成的项目已经映射了一个“local：”前缀，该前缀引用项目指定的默认命名空间和分部类定义使用的命名空间。
CLR 语言规则
如果要以 .NET 语言（C# 或 Microsoft Visual Basic）编写后盾代码，则可以使用使用点（“.”）作为命名空间名称的一部分的约定来创建代码命名空间的概念层次结构。 如果命名空间定义包含一个点，则该点应是你在“using：”标记之后指定的值的一部分。
如果代码隐藏文件或代码定义文件是C++文件，则某些约定仍遵循公共语言运行时（CLR）语言形式，因此 XAML 语法没有区别。 在C++中声明嵌套命名空间时，如果要指定“using:”标记后面的值，连续的嵌套命名空间字符串之间的分隔符应为“.”而不是“::”。
定义用于 XAML 的代码时，请勿使用嵌套类型（如在类中嵌套枚举）。 无法评估嵌套类型。 XAML 解析器无法区分一个点是嵌套类型名称的一部分，而非命名空间名称的一部分。
自定义类型和程序集
在映射中未指定定义 XAML 命名空间后盾类型的程序集的名称。 程序集可用的逻辑在应用定义级别进行控制，是基本应用部署和安全原则的一部分。 在项目设置中声明要作为 XAML 的代码定义源包含的任何程序集作为依赖程序集。 有关详细信息，请参阅 在 C# 和 Visual Basic 中创建 Windows 运行时组件。
如果要从主应用的应用程序定义或页面定义引用自定义类型，则这些类型在没有进一步依赖程序集配置的情况下可用，但仍必须映射包含这些类型的代码命名空间。 通常惯例是将任何给定 XAML 页面的默认代码命名空间的前缀命名为“local”。 此约定通常包含在 XAML 项目的启动项目模板中。
附加属性
如果要引用附加属性，则附加属性名称的所有者类型部分必须位于默认 XAML 命名空间中或前缀。 很少将属性与其元素分开添加前缀，但这种情况有时是必需的，尤其是自定义附加属性。 有关详细信息，请参阅 自定义附加属性。
