创建修补程序以简化解决方案更新

项目
03/04/2017

发布日期： 2017年1月

适用于： Dynamics 365 (online),Dynamics 365 (on-premises),Dynamics CRM 2016,Dynamics CRM Online

如果您将实体添加到解决方案中并导出该解决方案，则会导出该解决方案中的实体及其所有相关资产。这些资产包括属性、窗体、视图、关系和可视化项以及与实体一起打包的任何其他资产。导出所有对象意味着，您可能无意中在目标部署上修改对象，或者转移意外的依赖项。

若要解决此问题，您可以创建并发布包含实体子组件的解决方案修补程序，而不是发布整个实体及其所有资产。原始解决方案和一个或多个相关修补程序稍后可汇总（合并）到解决方案的更新版本中，然后可在目标 Microsoft Dynamics 365 组织中替换原始解决方案。

修补程序

您还可以将修补程序应用到托管或非托管解决方案并且仅包括对实体和相关实体资产的更改。修补程序不包含它所依赖的任何非自定义系统组件或关系，因为这些组件已存在于部署到的组织中。在开发周期的某一时刻，可以将所有修补程序汇总到新解决方案版本中以替换从中创建修补程序的原始解决方案。

修补程序作为 Solution 实体记录存储在 Dynamics 365 数据库中。非空 ParentSolutionId 属性表示解决方案是修补程序。修补程序可以通过管理组织或 Web API 创建和管理，这些 API 可用于开发自动化，例如产品安装脚本。但是，Dynamics 365 Web 应用程序提供多种 Web 窗体，可让您以交互方式创建和管理修补程序。

修补程序只能使用 CloneAsPatchRequest 或 CloneAsPatch Action 从父解决方案中创建。
修补程序的父级不能是修补程序。
修补程序只能有一个父解决方案。
修补程序依据其解决方案创建依赖项（在解决方案级别）。
只有在存在父解决方案时，您才能安装修补程序。
您不能安装修补程序，除非父解决方案的唯一名称和主要/次要版本号（由 ParentSolutionId 确定）不与在目标组织中安装的父解决方案的唯一名称和主要/次要版本号匹配。
修补程序版本必须具有和父解决方案相同的主要和次要版本号，但比父解决方案版本号更高的内部版本号和发布号。显示名称可能会有所不同。
如果解决方案具有修补程序，则后续的修补程序必须具有比该解决方案的任何现有修补程序在数字上都更高的版本号。
修补程序支持和解决方案相同的操作，如添加式更新，但不支持移除。您不能从修补程序的解决方案中移除使用组件。若要从解决方案中移除组件，请执行升级。
作为托管解决方案导出的修补程序必须在托管父解决方案之上导入。规则是修补程序保护（托管或非托管）必须与其父级匹配。
请勿将非托管修补程序用于生产目的。
修补程序只在 8.0 版或更高版本的 Dynamics 365 组织中受支持。

此版本中的 SolutionPackager 和 PackageDeployer 工具支持解决方案修补程序。请参考工具的联机帮助，以了解与修补程序相关的任何命令行选项。

创建修补程序

可使用 CloneAsPatchRequest 消息或 CloneAsPatch Action，或使用 Web 应用程序，从组织中的非托管解决方案创建修补程序。创建修补程序后，原始解决方案将被锁定，您无法更改或导出它，只要组织中有依赖的解决方案将解决方案确定为父解决方案。修补程序版本控制类似解决方案版本控制，是按以下格式指定的：major.minor.build.release。在创建修补程序时，不能对现有的主要或次要解决方案版本进行更改。

导出和导入修补程序

您可以使用组织服务或 Web API、Web 应用程序或包部署程序工具导出和导入修补程序。相关的组织服务消息请求是 ImportSolutionRequest 和 ExportSolutionRequest。 Web API 的相关操作是 ImportSolution Action 和 ExportSolution Action。

修补示例

下表列出修补示例的详细信息。请注意，在此示例中，解决方案和修补程序是按数字顺序导入的，可以累加，这一般来说与解决方案导入一致。

修补程序名称	说明
SolutionA，版本 1.0（非托管）	包含具有 6 个字段的 entityA。
SolutionA，版本 1.0.1.0（非托管）	包含具有 6 个字段（3 个已更新）的 entityA，并添加具有 10 个字段的 entityB。
SolutionA，版本 1.0.2.0（非托管）	包含具有 10 个字段的 entityC。

导入过程如下所示。

开发人员或定制员先将基本解决方案 (SolutionA 1.0) 导入到组织中。结果是组织中具有 6 个字段的 entityA。
接下来，导入 SolutionA 修补程序 1.0.1.0。组织现在包含具有 6 个字段（3 个已更新）的 entityA 以及具有 10 个字段的 entityB。
最后，导入 SolutionA 修补程序 1.0.2.0。组织现在包含具有 6 个字段（3 个已更新）的 entityA，具有 10 个字段的 entityB，以及具有 10 个字段的 entityC。

另一个修补示例

让我们看一下另一个修补示例，其详细信息在下表中列出。

修补程序名称	说明
SolutionA，版本 1.0（非托管，基本解决方案）	包含 Account 实体，其中客户编号字段的长度从 20 个字符调整到 30 个字符。
SolutionB，版本 2.0（非托管，不同供应商）	包含 Account 实体，其中客户编号字段的长度调整到 50 个字符。
SolutionA，版本 1.0.1.0（非托管，修补程序）	包含 Account 实体的更新，其中客户编号字段的长度调整到 35 个字符。

导入过程如下所示：

开发人员或定制员先将基本解决方案 (SolutionA 1.0) 导入到组织中。结果是一个具有 30 个字符的客户编号字段的 Account 实体。
导入 SolutionB。组织现在包含一个具有 50 个字符的客户编号字段的 Account 实体。
导入 SolutionA 修补程序 1.0.1.0。组织仍包含一个具有 50 个字符的客户编号字段的 Account 实体（由 SolutionB 应用）。
卸载 SolutionB。组织现在包含一个具有 35 个字符的客户编号字段的 Account 实体（由 SolutionA 1.0.1.0 修补程序应用）。

删除修补程序

您可以使用 DeleteRequest（对于 Web API，使用 HTTP DELETE 方法）删除修补程序或基本（父）解决方案。删除过程对于在组织中现有一个或多个修补程序的托管或非托管解决方案会有所不同。

对于非托管解决方案，您必须在卸载基本解决方案之前，先按照与创建相反的版本顺序卸载基本解决方案的所有修补程序。

对于托管解决方案，则仅需卸载基本解决方案。在卸载基本解决方案之前，Dynamics 365 系统会自动按反向版本顺序卸载修补程序。还可以卸载单个修补程序。

更新解决方案

更新解决方案会将该解决方案的所有修补程序汇总（合并）到解决方案的新版本中。之后，该解决方案会被解锁，可以再次被修改（仅限非托管解决方案）或导出。对于托管解决方案，不允许进一步修改解决方案，除非是从最近更新的解决方案创建修补程序。若要将修补程序汇总到非托管解决方案中，请使用 CloneAsSolutionRequest 或 CloneAsSolution Action。克隆解决方案会创建非托管解决方案的新版本，合并它的所有修补程序，而且使用较高的 major.minor 版本号、相同唯一名称和显示名称。

对于托管解决方案，处理方式略微不同。首先克隆非托管解决方案 (A)，合并它的所有修补程序，然后将其导出为托管解决方案 (B)。在包含 (A) 解决方案及其修补程序的托管版本的目标组织中，您导入托管解决方案 (B)，然后执行 DeleteAndPromoteRequest 或 DeleteAndPromote Action 以将托管解决方案 (A) 及其修补程序替换为具有更高版本号的已升级托管解决方案 (B)。

另请参阅

TechNet：使用细分的解决方案和修补程序简化解决方案更新
 解决方案开发的规划
 使用解决方案打包和分发扩展
 解决方案实体消息和方法
 维护托管解决方案
 在 AppSource 中注册应用

Microsoft Dynamics 365