XAML 命名空间和命名空间映射
本主题介绍在大多数 XAML 文件的根元素中找到的 XML/XAML 命名空间 （xmlns） 映射。 它还介绍如何为自定义类型和程序集生成类似的映射。
XAML 命名空间与代码定义和类型库的关系
XAML 在常规用途和应用程序Windows 运行时应用编程时，都用于声明对象、这些对象的属性以及表示为层次结构的对象属性。 在 XAML 中声明的对象由类型库或其他由其他编程技术和语言定义的表示形式提供支持。 这些库可能是：
- Windows 运行时的内置对象集。 这是一组固定的对象，从 XAML 访问这些对象将使用内部类型映射和激活逻辑。
- 由Microsoft或第三方提供的分布式库。
- 表示应用合并的第三方控件的定义和包重新分发的库。
- 你自己的库是项目的一部分，其中包含部分或全部用户代码定义。
支持类型信息与特定的 XAML 命名空间定义相关联。 XAML 框架（如Windows 运行时）可以聚合多个程序集和多个代码命名空间，以映射到单个 XAML 命名空间。 这使 XAML 词汇的概念涵盖更大的编程框架或技术。 XAML 词汇量可能相当广泛，例如，本参考中为Windows 运行时应用记录的大多数 XAML 构成单个 XAML 词汇。 XAML 词汇也是可扩展的：通过将类型添加到后盾代码定义来扩展它，确保将类型包含在已用作 XAML 词汇的映射命名空间源的代码命名空间中。
XAML 处理器可以在创建运行时对象表示形式时从与该 XAML 命名空间关联的后盾程序集中查找类型和成员。 这就是为什么 XAML 作为一种形式化和交换对象构造行为的定义的方法，以及为什么 XAML 用作 UWP 应用的 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 命名空间标识符相同，Microsoft技术也使用 XAML 作为 UI 定义标记格式。 使用同一标识符是故意的，在使用 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 语言 XAML 命名空间的“x：”映射约定后跟项目模板、示例代码和语言功能文档。 XAML 语言命名空间定义了几个常用的功能，即使使用 C++、C# 或 Visual Basic 的基本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 命名空间适用于设计器支持，特别是 visual Studio Microsoft 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 提供设计时数据资源。 我们不会在此处全面记录如何使用设计时数据资源。 有关详细信息，请参阅 设计时属性。 有关一些用法示例，请参阅 设计图面上的示例数据，以及用于原型制作。
mc: (http://schemas.openxmlformats.org/markup-compatibility/2006)
“mc：”指示并支持用于读取 XAML 的标记兼容性模式。 通常，“d：”前缀与属性 mc：Ignorable 相关联。 此技术使运行时 XAML 分析程序能够忽略“d：”中的设计属性。
local： and common：
“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 前缀进行的。 例如，定义一个新的 XAML 命名空间， xmlns:myTypes 该命名空间通过为令牌的所有用法 myTypes:添加前缀来访问。
xmlns 定义包括一个值以及前缀命名。 该值是一个字符串，它位于引号内，后跟等号。 常见的 XML 约定是将 XML 命名空间与统一资源标识符（URI）相关联，以便存在唯一性和标识约定。 此外，还会看到默认 XAML 命名空间和 XAML 语言 XAML 命名空间以及Windows 运行时 XAML 使用的一些不太使用的 XAML 命名空间的约定。 但是，对于映射自定义类型的 XAML 命名空间，而不是指定 URI，请使用标记“using：”开始前缀定义。 按照“using：”令牌命名代码命名空间。
例如，要映射一个允许你引用“CustomClasses”命名空间的“custom1”前缀，并使用来自该命名空间或程序集的类作为 XAML 中的前缀，你的 XAML 页面应在根元素上包含以下映射：xmlns:custom1="using:CustomClasses"
不需要映射同一页范围的分部类。 例如，不需要前缀来引用为处理页面的 XAML UI 定义中的事件而定义的任何事件处理程序。 此外，Visual Studio 中的许多起始 XAML 页面使用 C++、C# 或 Visual Basic 为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 命名空间中或前缀。 很少将属性与其元素分开添加前缀，但这种情况有时是必需的，尤其是自定义附加属性。 有关详细信息，请参阅 自定义附加属性。