信息
您所需的主题如下所示。但此主题未包含在此库中。

应用包和部署(Windows 运行时应用)

Applies to Windows and Windows Phone

作为开发人员,你不用通过编写例程来安装或卸载 Windows 运行时应用。只需将你的应用打包并提交到应用商店。用户从应用商店以应用包的形式获取你的应用。 操作系统使用应用包中的信息基于每个用户来安装应用,并确保安装该应用的所有用户在卸载该应用之后,从设备中消除该应用的所有痕迹。

应用包是一种基于开放式打包约定 (OPC) 标准的容器。OPC 定义一种结构化方式来使用标准 ZIP 文件存储应用的数据和资源。有关如何使用 Microsoft Visual Studio 部署应用包的信息,请参阅从 Visual Studio 部署 Windows 运行时应用

自 Windows 8.1 和 Windows Phone 8.1 开始,全新的应用捆绑包将有助于优化应用的打包和分发过程。通过使用资源包,你可以为用户提供他们所需的额外内容(例如本地化内容,或者用于高分辨率显示器的资产),这不会影响磁盘空间、带宽或他们不需要的应用购买体验。同样,硬链接可通过不多次下载相同的文件来避免重复数据,从而优化应用的安装。

Windows 运行时应用部署

Windows 运行时应用模型是一个受状态驱使的声明性过程,它在单个包中为应用提供所有的安装和更新数据与说明。在此声明性模型中,部署操作是可靠的。 包中提供的文件是不可变的,这意味着它们在交付到设备之后未进行过修改。 由于包所有者不必编写自定义的操作和代码,因此失败点数会减少。

在更新过程中,在从设备中删除旧版本之后,新版本的应用会立即下载和安装到用户的配置文件。与 Windows Installer 相比,不存在如下概念:修补程序文件或任何其他用于部署 Windows 运行时应用的文件。

  • Applies to Windows

注意  

在 Windows 上,由于 Windows 运行时应用安装到用户的配置文件中,因此每个用户都可以完全控制其 Windows 应用商店应用。可以安装、更新和删除应用,而不影响任何其他用户在设备上的应用。

有关部署的详细信息,请参阅 Windows 运行时应用的部署

Windows 运行时应用包 – .appx

用于定义某个 Windows 运行时应用的所有组件都存储在一个 Windows 运行时应用包中。Windows 运行时应用包的文件扩展名为 .appx,此包是 Windows 运行时应用的安装单元。 Windows 运行时应用包是基于 ZIP 的容器文件,这些文件定义为 ISO 和 ECMA 开放式打包约定 (OPC) 标准的子集。 每个 Windows 运行时应用包都包含应用的负载文件以及验证、部署、管理和更新应用所必需的信息。 简要来说,每个 Windows 运行时应用包都包含以下项:

应用负载

应用代码文件和资产

负载文件是在创建 Windows 运行时应用时编写的代码文件和资产。

应用清单

应用部件清单文件 (AppxManifest.xml)

应用部件清单声明应用的标识、应用的功能以及用来进行部署和更新的信息。 有关应用部件清单文件的详细信息,请参阅应用包清单

应用块映射

应用包块映射文件 (AppxBlockMap.xml)

块映射文件列出包中包含的所有应用文件,以及操作系统用来验证文件完整性和优化应用更新的相关加密哈希值。有关块映射文件的详细信息,请参阅应用包块映射

应用签名

应用包数字签名文件 (AppxSignature.p7x)

应用包签名可确保包及其内容在签名之后未进行过更改。 如果签名证书验证为可信根证书颁发机构的证书,则该签名还标识包的签名者。包的签名者通常是应用的发布者或作者。

上面的这些项目包含一个完全自包含格式的 Windows 运行时应用,该应用可以部署到 Windows 8 和更高版本以及 Windows Phone 8.1 和更高版本。 你可以为自己的应用创建应用负载文件和应用部件清单文件。 当 Visual Studio 对你的应用进行打包时,它会自动向程序包中添加该应用的块映射文件和签名文件。但是,如果你希望对你的应用手动打包,则还可以使用独立的 MakeAppxSignTool 实用程序。 以下部分描述如何对 Windows 运行时应用进行打包和部署。

程序包标识

应用包的一个最基本部分就是用来定义包的 5 部分元组。此元组称为包标识,它由以下数据组成:

Name

一个用于应用包的通用名称。例如,"myCompany.mySuite.myApp"。

注意  此名称不必是显示在应用磁贴上的名称。

Publisher

发布者是指 Windows 运行时应用的发布者。在大多数情况下,发布者与用来注册开发人员帐户的帐户相同。

Version

用于为将来的应用版本提供服务的四部分版本描述符(主要版本.次要版本.内部版本.修订版本)。例如,"1.0.0.0"。

注意  你必须使用版本描述符的所有四个部分。

ProcessorArchitecture

应用包的目标体系结构。此值可以是 "x86"、"x64"、"arm" 或 "neutral"。在许多情况下,此字段可以是"中性的",用以代表所有体系结构。

ResourceID

可选。

由发布者指定的、用来指定应用包资源的字符串。如果应用包中具有特定于某个区域的资产(如语言),则主要使用元组的这一部分。

如果手动创建程序包,请参阅 Identity 元素。

包格式

下面我们介绍有关应用包的详细信息(即 .appx 文件格式)。

应用包是只读的

尽管应用包基于 OPC 的子集,但是我们不建议通过用来操作 OPC 或 ZIP 文件的现有 API 来编辑应用包。在创建应用包之后,系统会将其视为只读。 用来创建应用包的 Visual Studio 和 MakeAppx 进程会自动生成 AppxBlockMap.xml 文件并将其添加到程序包中。如果你更改包中的任何内容,则需要更新包的块映射文件以进行匹配。 若要创建新的包文件和块映射文件,则必须使用 Visual Studio、MakeAppx 打包命令或 Windows 8 本机代码 IAppxPackageWriter API 重新生成包。

应用包负载文件名

为了遵循 OPC,存储在应用包中所有文件的文件路径名必须符合统一资源标识符 (URI)。对于不符合 URI 的文件路径,需要在存储到应用包中时进行百分比编码,并在从包中提取时重新解码到原始文件路径中。例如,考虑下面的负载文件,该文件的路径和名称中包含内嵌空格和由 URI 保留的字符“[”和“]”:


\my pictures\kids party[3].jpg

在将该负载文件存储到应用包中时,文件的路径变为:


/my%20pictures/kids%20party%5B3%5D.jpg

Visual Studio、应用包生成工具 (MakeAppx) 和包 API 会自动处理文件路径的百分比编码和解码。如果你尝试使用通用 ZIP 实用程序或 API 直接从应用包中提取文件,则文件路径可能会保持百分比编码。因此,我们建议你使用 MakeAppx 解包命令或 IAppxPackageReader API 来从应用包中提取文件。

应用包容量

应用包对应用的容量进行了如下限制:

包容量最大容量
文件计数100,000 个文件
包大小100 GB

 

应用包保留的路径和文件名。

这些路径和文件名是保留的,因此不应当将它们用于应用负载文件:

保留的路径和文件名使用
/AppxManifest.xml对于由开发人员编写的应用包清单使用保留的文件名
/AppxBlockMap.xml对于应用包块映射使用保留的文件名
/AppxSignature.p7x对于应用包的 Microsoft Authenticode 数字签名使用保留的文件名
/[Content_Types].xml对于应用包的 OPC 所需的内容类型元数据使用保留文件名
/AppxMetadata/对于应用包元数据文件使用保留的文件夹路径
/Microsoft.System.Package.Metadata/对于有关所部署的应用包的 Microsoft 元数据文件使用保留的文件夹路径

 

应用包数字签名

你必须对每个应用包进行签名,用户才能安装它们。尽管应用包签名的一部分是通过 Authenticode 自动完成的,但是,你必须在对应用包进行签名时控制以下功能:

  • 代码签名证书的使用者名称必须与 Publisher 属性相匹配,该属性在应用包中 AppxManifest.xml 文件的 Identity 元素中指定。
  • 用来对应用包进行签名的哈希算法必须与用来生成应用包中 AppxBlockMap.xml 文件的哈希算法相匹配。此哈希算法是在 BlockMap 元素的 HashMethod 属性中指定的。
  • 对于应用包不能独立于签名创建时间戳。如果需要创建时间戳,则必须在签名期间为应用包创建时间戳。
  • 应用包不支持多个封装签名。

包的签名确定 Windows 运行时应用的许可方式。应用的许可方式影响它的安装和运行方式,因此,在安装期间,即便两个应用包的包标识相同,也不能将它们视为相同。例如,你不能安装与另一个已经安装的应用具有相同包标识却有不同签名的应用包。

声明性安装

Windows 运行时应用部署是一个依赖应用包清单的完全声明性过程。你可以使用应用包清单来捕获与操作系统的所需集成。例如,使用应用包清单来声明需要在操作系统上使用文件类型关联(如 .jpg)。

这样,操作系统可以完全管理 Windows 运行时应用的开发过程,以便大量设备上的每个用户都获得一致的可靠体验。而且,通过拥有 Windows 运行时应用的声明性安装,应用的卸载也会变得具有确定性和可重复性。

在应用包清单内部,可以将大量技术声明为 Windows 运行时应用安装的一部分。

应用的先决条件

若要成功部署应用,则操作系统必须满足应用包清单中所引用的全部应用的先决条件。例如,如果一个版本的操作系统公开一个由 Windows 运行时应用调用的新 API,则该应用会在特定的最低版本操作系统上声明一个先决条件。在这种情况下,目标设备上必须存在正确的操作系统,才能安装应用。在 Windows 8 及更高版本和 Windows Phone 8.1 及更高版本中,可以在应用包清单中声明以下关键类型的先决条件:

OSMinVersion

指定可以运行此应用的操作系统和应用模型平台的最低版本。

OSMaxVersionTested

指定由开发人员在其中对此应用进行测试而且已知处于工作状态的操作系统的最高版本。这个先决条件字段由操作系统用来确定在使用应用期间是否可能会出现任何应用兼容性问题。例如,如果此应用从 Windows 8 SDK 调用 API,而且该 API 以后在后续版本的操作系统中发生过更改,则该应用的行为可能不正确。这个先决条件字段帮助确保操作系统能够标识和更正此行为,以便此应用在所有后续版本的操作系统中继续正常工作。

功能

如果 Windows 运行时应用需要以程序方式对用户资源(例如“图片”)或连接的设备(例如摄像头)进行访问,则必须声明相应的功能。应用可以通过在其应用包清单中声明相应的功能来请求访问。你可以使用 Visual Studio 中的清单设计器来声明功能,或者,你可以按照如何在包清单中指定功能中的说明,向包清单中手动添加这些功能。有关功能的详细信息,请参阅应用功能声明

依存关系

应用商店承载一组唯一的应用包,这些包中包含独立于操作系统提供服务的操作系统组件。Windows 运行时应用可以通过在这些应用包的应用包清单中声明依存关系来使用这些应用包。应用商店承载的应用包中所包含的组件称为操作系统组件库。应用商店管理如下过程:确保在将应用安装到设备上时,存在正确版本的组件库。 这些库(包括 Windows JavaScript 库、C++ 运行时库 (CRT) 和 PlayReady DRM)是创建 Windows 运行时应用所必需的。在从应用商店部署应用时,操作系统通过下载和安装适用于正从应用商店下载的应用的组件库。

  • Applies to Windows

注意  如果需要对要进行测试或企业部署的 Windows 应用商店应用进行旁加载,则必须在部署应用包期间提供和指定 Windows 组件库应用包。

应用捆绑包

自 Windows 8.1 和 Windows Phone 8.1 开始,你可以使用应用捆绑包(或 .appxbundle 包),从而优化 Windows 运行时应用和资源包打包及向全世界用户分发的过程。

注意  为所有体系结构创建一个应用捆绑包,而不是分别为每个体系结构创建捆绑包。

你可以为你的应用创建应用捆绑包负载文件。 Visual Studio 将创建和添加捆绑包清单。在 Visual Studio 捆绑你的应用时,会自动将资源拆分为单独的程序包并向捆绑包添加应用块映射和签名文件。这些项目构成一个完全自包含格式的 Windows 运行时应用,该应用可以部署到 Windows 8.1 和 Windows Phone 8.1 以及更高版本的系统中。

应用包 (.appx)

只有在每个应用包对应不同的特定体系结构时,应用捆绑包才能包含多个应用包。例如,它可包含 x86.appx 和 amd64.appx 程序包,但不能包含两个 amd64.appx 程序包。

资源包 (.appx)

应用捆绑包包含用于语言、规模和 Microsoft DirectX 功能级别的资源包(.appx 文件)。每个应用捆绑包都包含不同的资源包,以便支持不同的设备配置。当直接引用你的 Windows 运行时应用中的资源包时,建议你充分利用资源管理系统。

注意  资源包中不能包含任何代码。

应用捆绑包清单 (AppxBundleManifest.xml)

应用捆绑包清单 (.appxbundlemanifest file) 包含与其中的程序包相关的所有适用性信息。对于任何特定包,它指定包的类型("应用程序"或"资源")以及版本和资源定位信息。特别是应用包,应用捆绑包清单包括体系结构的相关信息。

通常情况下,应用捆绑包清单可让应用模型了解该应用捆绑包的内容,并确定安装期间要在用户设备上安装哪些应用包和资源包

这里是应用捆绑包清单文件的一个示例。

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Bundle xmlns="http://schemas.microsoft.com/appx/2013/bundle" SchemaVersion="1.0">
  <Identity Name="Example" Publisher="CN=ExamplePublisher" Version="2013.101.312.1053"/>
  <Packages>
    <Package Type="application" Version="1.0.0.5" Architecture="x86" FileName="AppPackage_X86.appx" Offset="49" Size="3207">
      <Resources>
        <Resource Language="en-us"/>
        <Resource Scale="100" />
      </Resources>
    </Package>
    <Package Type="application" Version="1.0.0.4" Architecture="x64" FileName="AppPackage_X64.appx" Offset="3329" Size="3204">
      <Resources>
        <Resource Language="en-us"/>
        <Resource Scale="100" />
      </Resources>
    </Package>
    <Package Type="resource" Version="1.0.0.0" ResourceId="French" FileName="ResourcePackage_French.appx" Offset="6606" Size="1423">
      <Resources>
        <Resource Language="fr"/>
        <Resource Language="fr-fr"/>
        <Resource Language="fr-ca"/>
      </Resources>
    </Package>
    <Package Type="resource" Version="1.0.0.3" ResourceId="HiRes" FileName="ResourcePackage_HiRes.appx" Offset="8111" Size="1584">
      <Resources>
        <Resource Scale="140"/>
      </Resources>
    </Package>
  </Packages>
</Bundle>

应用块映射 (AppxBlockMap.xml)

块映射文件列出捆绑包(应用和资源包除外)中包含的所有应用文件,以及操作系统用来验证文件完整性和优化应用更新的相关加密哈希值。有关块映射文件的详细信息,请参阅应用包块映射

应用签名 (AppxSignature.p7x)

应用捆绑包签名可确保程序包及其内容在签名之后未进行过更改。如果签名证书验证为可信根证书颁发机构的证书,则该签名还标识包的签名者。包的签名者通常是应用的发布者或作者。

资源包

自 Windows 8.1 和 Windows Phone 8.1 开始,你可以使用资源包来容纳核心应用的其他资源(例如,字符串或图像等形式的法语特定资产)。通过使用资源包,可以将核心应用包与其他资源分开。 这样的资源包可用于量身定制应用的整体体验,无需下载并将所有资源包安装到设备。

此资源包是可选的,无法作为应用包的依赖包。这意味着应用包必须至少包含一组默认资源,在设备中未安装任何资源包的情况下始终可以使用这组资源。此举可帮助保持部分关键承诺:

  • 无需资源包即可在任何设备上正确安装和启动该应用包。

  • 如果已安装的资源包不完整,那么应用包能够为其提供帮助资源。

资源包在应用模型中有以下作用:

  • 提供资源管理系统在应用定制其体验的运行过程中能够使用的候选资源。

  • 提供允许资源包确定特定资源限定符(如用户语言、系统规模和 DirectX 功能)的元数据。

资源包对于每个包只能针对一个资源限定符。但你的应用可以有多个资源包。

资源包中不能包含任何代码。

硬链接

从 Windows 8.1 和 Windows Phone 8.1 开始,当 OS 安装你的应用时,它可通过在任何可行情况下避免多次下载相同的文件来优化安装。也就是说,如果 OS 确定你的应用使用之前已在设备上安装的文件,OS 将创建该文件的共享版本,然后使你的应用硬链接到该共享版本。这将减少应用的安装时间和磁盘占用量。这些共享的文件可以是库、运行时等。若要利用硬链接,我们建议你遵循最佳做法。例如,针对每个版本的应用,始终尝试尽可能地重复使用相同的运行时或库二进制文件,除非你不得不更新这些文件。

  • Applies to Windows

Windows 8.1 更新:  对于初始版本的 Windows 8.1,硬链接限制为仅适用于 Windows 应用商店中的应用。对于 Windows 8.1 更新,硬链接可在旁加载企业应用中得到进一步支持。有关旁加载的详细信息,请参阅部署企业应用

按用户部署

  • Applies to Windows

注意  

Windows 运行时应用部署是基于每个用户的,这意味着它们仅影响安装了它们的用户的帐户。而且,在多用户方案中,用户不知道为任何其他用户安装了什么。例如,假定用户 A 安装了“记事本”应用,而用户 B 安装了“计算器”应用。在该方案中,用户 A 和用户 B 不知道同一计算机上安装的其他应用(应用隔离)。

  • Applies to Windows

注意  

操作系统上的应用隔离仅限于 Windows 运行时应用的用户部分。应用中的所有其他数据都存储在一个能够由操作系统访问的位置中。例如,假定用户 A 和用户 B 均安装了“计算器”应用,在该方案中,该应用只有一个副本存储在驱动器 (%ProgramFiles%\WindowsApps) 上,该应用能够由这两个用户访问。用户 A 看不到用户 B 的应用数据,反之亦然。尽管运行时库是共享的,但是应用数据仍是隔离的。

%ProgramFiles%\WindowsApps 目录无法进行更改。其中还包括基础 %ProgramFiles% 目录以及 %ProgramData% 和 %UserProfile% 目录。

  • Applies to Windows

注意  

除了包含针对系统上所有用户的所有 Windows 应用商店应用二进制文件,WindowsApps 目录中还包含同一个 Windows 应用商店应用的多个版本。例如,假设用户 A 和用户 B 均安装了“记事本”应用,而用户 A 将“记事本”应用更新到版本 2,而用户 B 没有进行更新。在该方案中,操作系统上存在两个版本的“记事本”应用。由于针对每个用户仅安装了一个版本,因此多个版本不会发生冲突。

此行为还适用于依存关系包。

Windows 运行时应用的部署

以下部分描述了安装、更新和删除 Windows 运行时应用的流程。

安装 Windows 运行时应用

下图展示了 Windows 运行时应用的安装流程:

Windows 应用商店应用安装流

Windows 运行时应用部署过程发生在多个阶段。首先,OS 获取和验证应用部件清单应用块映射和应用签名。接着,OS 检查应用包的部署条件以确保应用部署将成功。然后,OS 将程序包二进制文件暂存到 WindowsApps 目录。最后,OS 将该包注册到用户的帐户中。

部署检查(验证)

下图显示 OS 执行部署检查的阶段:

安装检查的部署

在用户开始安装 Windows 运行时应用时,OS 必须完成这些检查,部署过程才能开始:

必须满足 OSMinVersion

你可以在应用包清单中指定应用先决条件。先决条件表示需要满足的特定最低操作系统版本要求。有关应用先决条件的详细信息,请参阅应用先决条件

必须满足应用依存关系

Windows 运行时应用可以表示为获得应用所需的附加功能而对其他应用包的依存关系。有关应用依存关系的详细信息,请参阅依存关系

磁盘空间必须足够

每个 Windows 运行时应用都需要存在一定量的磁盘空间才能部署应用。如果设备上的磁盘空间不足以部署应用包,则部署将失败。

应用没有已部署

在安装 Windows 运行时应用的特定用户的上下文中,不能再次安装该应用,因此必须执行用于检查应用是否尚未安装的检查。

应用资产必须通过签名检查

必须使用已经验证的 BlockMap 来检查应用包中每个文件的完整性。

包暂存

下图显示 OS 暂存程序包的阶段:

部署包暂存

在应用模型确定程序包可以在设备上部署之后,OS 将程序包的内容存储到磁盘上 %ProgramFiles%\WindowsApps 目录下以程序包标识命名的新目录中:


<Package Name>_<Version>_<Architecture>_<ResourceID>_<Publisher Hash>

暂存过程是通过部署引擎向包的位置来源发出的一组请求进行的。随后位置来源满足这些请求,并返回到它们所解压缩到的部署引擎,依据 BlockMap 进行验证,然后复制到相应的文件中。

包注册

下图显示 OS 注册程序包的阶段:

部署包注册

包注册是部署过程中的最后一个阶段:在此阶段期间,清单中声明的扩展会向操作系统注册。这使应用能够与操作系统紧密集成。例如,如果你希望你的应用能够打开 .txt 文件,则在应用包清单中将 FileTypeAssociation 扩展声明为 XML,然后将 .txt 指定为文件类型。在部署期间,此 XML 会转换为一组系统更改,这些更改是正确注册应用以处理 .txt 文件所必需的。这些更改随后会由应用模型代表应用来执行。应用模型支持许多不同的扩展。有关这些扩展的详细信息,请参阅应用合约和扩展

更新 Windows 运行时应用

下图显示了更新 Windows 运行时应用的流程:

部署更新

更新工作流与安装 Windows 运行时应用的工作流相似,只是存在下面几个特定于更新的主要区别。

部署更新检查

下图显示 OS 在更新时执行部署检查的阶段:

部署更新检查

如果当前安装的应用包的版本大于或等于用户尝试安装的版本,则部署将失败。

包暂存(增量下载)

下图显示 OS 暂存已更新程序包的阶段:

部署更新暂存

更新期间的暂存过程与安装期间的典型暂存过程相似。但是,二者也有区别,它们之间的关键区别是在更新期间,操作系统上已经安装了预先存在的包版本。在预先存在的包安装完成之后,一组负载文件会下载和复制到设备上。在许多情况下,其中的许多负载文件将不会更改,或者更新后的应用包版本只是稍微有些变化。你可以使用这些负载文件来构造更新的应用包内容和资产。由于应用包的 BlockMap 结构对于每个文件的每个块都包含一系列哈希,因此 OS 可以通过比较先前的和新的应用 BlockMap 文件来精确计算块级别的更改集。下面是可能的比较结果:

文件未更改

该文件硬链接到已更新的包文件夹位置。

文件中的块未更改

未更改的块复制到已更新的包文件夹中。

文件中的块已更改

已更改的块标记为从来源进行下载。

整个文件是新的

整个文件将从来源下载。

文件不再存在

该文件将根本不用于进行更新。

在比较完成之后,可以保留的所有数据都硬链接或复制,而且所有的新数据都从来源下载并用于生成更新文件。

包注册更新

下图显示 OS 注册已更新程序包的阶段:

部署已更新的包注册

当你更新包的注册时,OS 还需要更新先前版本的注册。应用模型自动更新任何现有的扩展注册,删除过时的注册,基于先前版本和新版本应用的清单中存在的声明注册新扩展。

应用的使用情况

从操作系统中注销应用包的过程涉及到删除那些允许 OS 启动 Windows 运行时应用的内部内容。在某些特定情况下,可以在更新过程中运行应用。在这种情况下,部署引擎请求挂起并随后终止应用。根据该请求的结果,更新过程会成功或失败。如果操作成功,则系统还会禁止应用在一个较短的时间段内启动,在这段时间内,系统会注册新应用包和注销先前的应用包。在此阶段完成之后,系统会重新允许启动应用。

应用数据

应用数据是一个实体,它的版本与实际 Windows 运行时应用的版本不同。照这样,如果 ApplicationData.Version 没有随 Windows 运行时应用一起更新,则应用的状态不会受到 Windows 运行时应用更新的影响。

包取消暂存

下图显示 OS 对已更新的程序包取消暂存的阶段:

已更新的部署包取消暂存

在注册操作成功完成之后,如果预先存在版本的程序包未由操作系统上的任何其他用户使用,则会将程序包标记为要从操作系统中删除。最初,OS 将预先存在版本的应用包文件夹复制到 %ProgramFiles%\WindowsApps\Deleted 目录中。如果当前没有其他部署操作正在运行,则 OS 会删除预先存在版本的应用包文件夹。

  • Applies to Windows

注意  在多用户方案中,面向另一个用户的应用包可能仍安装在操作系统上。在这种情况下,除非所有的用户均将程序包内容删除,否则程序包内容不会从操作系统取消暂存。

删除 Windows 运行时应用

下图展示了删除 Windows 运行时应用的流程:

部署删除

  • Applies to Windows

注意  与在计算机上基于每个用户安装包的方式类似,包的删除也是基于每个用户的。如果为多个用户安装了 Windows 应用商店应用,则它将只针对当前的用户注销。例如,如果用户 A 和 用户 B 都安装了“计算器”应用,而用户 A 卸载该应用,则将只删除面向用户 A 的应用,而不删除面向用户 B 的应用。删除过程与更新过程包含的基本阶段相同。

包注销

下图显示 OS 对已删除的程序包取消注册的阶段:

部署已删除的包注销

注销过程是指删除 Windows 运行时应用与用户帐户的集成。任何已安装到用户帐户的关联数据(如应用状态)也将删除。与更新过程相似,部署引擎必须通过进程生命期管理器 (PLM) 暂停和终止应用,以便可以从用户的帐户注销应用。

注意  在 PLM 返回之后,删除操作会继续从用户的帐户注销 Windows 运行时应用。即使 PLM 不成功,删除操作也会继续。

包取消暂存

下图显示 OS 对已删除的程序包取消暂存的阶段:

部署已删除的包取消暂存

在注销操作成功完成之后,未由操作系统上的任何其他用户使用的程序包会标记为要从操作系统中删除。最初,OS 将程序包的应用包文件夹复制到 %ProgramFiles%\WindowsApps\Deleted 目录中。如果当前没有其他部署操作正在运行,则 OS 会删除该包的应用包文件夹。

  • Applies to Windows

注意  

在多用户方案中,面向另一个用户的应用包可能仍安装在操作系统上。在这种情况下,除非所有的用户均将程序包内容删除,否则程序包内容不会从操作系统取消暂存。

应用捆绑包部署

自 Windows 8.1 和 Windows Phone 8.1 开始,你可以通过部署应用捆绑包来优化应用的打包和分发过程。

通过应用商店的应用捆绑包的部署遵循此工作流。

应用打包流

Windows 运行时应用部署过程发生在多个阶段。首先,OS 获取和验证应用捆绑包清单、捆绑包块映射和捆绑包签名。然后,OS 检查捆绑包清单,确保有应用能够在当前体系结构上进行部署。找到合适的应用包之后,OS 将检查该应用包的部署条件以确保应用成功部署。

接着,OS 确定适用于部署的资源包的子集,并将这些资源包二进制文件暂存到 \WindowsApps\ 目录。最后,OS 将应用包和资源包注册至用户帐户。

验证

在用户开始安装 Windows 运行时应用时,OS 必须完成这些检查,部署才能开始。

测试条件

体系结构支持

捆绑包最多可包含三个体系结构特定的应用包,全部在应用捆绑包清单中指定。

最低操作系统版本

你可以在应用包清单中指定应用先决条件。它们表示特定最低操作系统版本的要求。例如对于 Windows 8.1,恰当的版本号是 6.3。 有关应用先决条件的详细信息,请参阅应用打包先决条件

应用依存关系

Windows 运行时应用可以表示为获得应用所需的附加功能而对其他组件包的依存关系。有关应用依存关系的详细信息,请参阅应用打包依存关系

磁盘空间

每个 Windows 运行时应用都需要特定的磁盘空间量才能部署。如果磁盘空间不足以部署应用包,则部署将失败。

签名检查

必须根据已经验证的 BlockMap,对应用包中的每个文件进行完整性检查。

 

程序包适用性

OS 验证应用捆绑包能够在系统上进行部署以后,便会确定要与应用包一同部署的资源包,从而改善用户的体验。根据以下三个特定资源限定符来检查适用性。

限定符说明

用户语言

用户已添加到首选语言列表中的所有语言都将计入要部署的最终适用语言资源包组中。Windows 8.1 及更高版本和 Windows Phone 8.1 及更高版本支持资源包的许多区域设置和语言

系统规模

所有监视器的规模值都将用于确定要部署的最终适用规模资源包组。对于 Windows 8.1 及更高版本和 Windows Phone 8.1 及更高版本,我们推荐这些比例系数用于资源数据包:

Windows 8.1 及更高版本:  scale-100scale-140scale-180

Windows Phone 8.1 及更高版本:  scale-100scale-140scale-240

DirectX 功能级别

系统上所有可用的 DirectX 功能级别都将用于确定要部署的最终适用 DirectX 资源包组。Windows 8.1 及更高版本和 Windows Phone 8.1 及更高版本支持三个资源包 DirectX 功能级别:DXFL-DX9DXFL-DX10DXFL-DX11

 

包暂存

在 OS 确定可在系统上部署的应用捆绑包以及要部署的程序包后,包内容下载到 \WindowsApps\ 目录。为下载的每个包创建一个新目录并使用包身份名称值命名,如下所示。

<Package Name>_<Version>_<Architecture>_<ResourceID>_<Publisher Hash>

暂存过程是通过部署引擎向包的位置来源发出的一组请求进行的。随后位置来源满足这些请求,并返回到它们所解压缩到的部署引擎,依据 BlockMap 进行验证,然后复制到相应的文件中。

包注册

包注册是部署过程中的最后一个阶段:在这个阶段中,需要执行两项关键操作:

  • 应用包清单中声明的扩展会向操作系统注册。这使应用能够与操作系统紧密集成。例如,如果你希望你的应用能够打开文本 (.txt) 文件,则在应用包清单中将 FileTypeAssociation 扩展声明为 XML,然后将 ".txt" 指定为文件类型。

    在部署期间,此 XML 会转换为一组系统更改,这些更改是正确注册应用以处理 .txt 文件所必需的。应用模型随后代表应用执行这些更改。应用模型支持多种不同扩展。有关这些扩展的详细信息,请参阅应用合约和扩展

  • 所有资源包都在资源管理系统中进行注册。然后可使用它们在应用运行时优化用户的体验。

包清单

在安装、更新和删除 Windows 运行时应用时,给定的用户可以随时查看安装或预先暂存了哪些应用包。

  • Applies to Windows

注意  具有管理员权限的用户还可以确定为系统上的所有用户安装哪些应用包。有关如何列举操作系统上各个包的详细信息,请参阅工具和 PowerShell cmdlet

常见问题

如何同时安装多个包?

你可以通过多次调用打包 API 来安装多个包,也可以针对要安装的整组包调用打包 API 来一次安装多个包。应用模型的基础实现允许有任意多个应用包等待部署。但是,每个用户最多允许有 3 个并发的暂存操作(每个操作系统总共最多允许有 7 个并发的暂存操作),每个操作系统最多允许有 1 个注册操作。

如果包已经安装,会发生什么情况?

如果某个包已经安装,则说明已经存在一个其包标识已经针对当前用户帐户注册的同一个包。在这种情况下,不会安装相同的包。

是否可以将某个更新设置为强制性的?

你不能通过应用模型将更新设置为强制更新。严格来说,更新模型是可选的。在极少数情况下,应用商店会认为更新适用于作为较高优先级的更新(如安全修复)进行分发。在这种情况下,更新会被强制部署到客户端。

  • Applies to Windows

注意  

在 Enterprise 中,可以通过组策略强制进行更新。

如何将更新回滚到早期版本?

你不能将 Windows 运行时应用回滚到它的早期版本。由于应用包数据会在应用包卸载之后不久从操作系统中删除,因此无法对应用包数据进行还原。

是否可以移动 %ProgramFiles%、%ProgramData% 或 %UserProfile% 目录?

这是 Windows 运行时应用不支持的方案,而且将导致在使用应用时出现错误。

打包和部署编程接口

Windows 运行时

Win32/COM

 

 

显示:
© 2014 Microsoft