将沙盒解决方案转换为 SharePoint 外接程序模型

将沙盒解决方案转换为 SharePoint 外接程序模型包括:分析现有扩展、设计和开发 SharePoint 的新外接程序,然后在生产环境中测试并部署你的外接程序。

注意

基于代码的沙盒解决方案在 2014 年被弃用,而 SharePoint Online 开启了完全移除此功能的过程。 基于代码的沙盒解决方案在 SharePoint 2013 和 SharePoint 2016 中也同样被弃用。

SharePoint 中基于代码的沙盒解决方案

沙盒解决方案是自定义数据包,可用于将自定义部署到网站集级别的 SharePoint。 如果沙盒解决方案包含代码,则它已在特殊的独立过程中执行,并具有访问 SharePoint 服务和内容的一组有限的 API。

沙盒解决方案具有两种类型:

  • 程序包中包含自定义程序集的基于代码的沙盒解决方案。
  • 仅包含基于 XML 的配置和相关资产的声明性沙盒解决方案。

基于声明性(基于 XML)沙盒解决方案可根据使用情况可以进一步划分为以下类型。

  • 网站模板 – 使用现有网站中的“将网站保存为模板”功能生成。
  • 设计程序包 – 使用发布网站中的设计管理器生成。
  • 自定义沙盒解决方案 - 在 Visual Studio 中创建(例如用于品牌资产)且不包含程序集。

基于代码的沙盒解决方案可根据使用情况可以进一步划分为以下类型。

  • 具有空程序集的声明性沙盒解决方案
  • 包含具有代码的 InfoPath 表单的沙盒解决方案
  • 具有自定义(诸如 Web 部件、事件接收器和/或功能接收器)的基于代码的沙盒解决方案
  • 具有自定义工作流操作的沙盒解决方案

计划从沙盒解决方案脱离时,应评估特定解决方案的功能和业务要求,并基于以上确定未来的设计方向。

规划转换过程

将沙盒解决方案转换为 SharePoint 外接程序模型时,最好确保对用户产生的影响最低。 仔细分析当前沙盒解决方案,然后设计新的 SharePoint 外接程序以满足组织的需求。 我们建议使用以下过程以确保成功转换。

准备情况

了解以下信息:

解决方案评估

通过以下操作分析功能和业务要求:

  • 在可以使用由 SharePoint PnP 团队作为开放源提供的以下任一工具的当前环境中标识部署的沙盒解决方案:

  • 与用户一起审核要求。 考虑要求用户演示如何使用现有沙盒解决方案来执行其日常工作。

  • Identifying, documenting, and designing new functionality to include in the new SharePoint 外接程序 . Consider reviewing your list of new feature requests from your users for additional ideas.

  • 标识未使用的功能,并允许你的用户在新的 SharePoint 外接程序中忽略此功能。

  • 对于每个解决方案,确定是将其替换为 SharePoint 外接程序,还是使用现成的功能或替代解决方案实现它。

解决方案计划

使用 SharePoint 外接程序模型基于以下内容设计新的应用程序:

  • 解决方案评估步骤中收集的要求。

  • 你对现有代码的分析。 在代码分析过程中,请考虑标识可删除的代码部分(例如不再使用的代码或需求已更改的情况)。

开发和测试应用程序的 SharePoint 外接程序模型版本

这通常是转换过程中最耗时的步骤。

部署新的外接程序

请确保你的部署处于稳定状态,并向用户发送相应的信息。

替代沙盒解决方案自定义

以下是沙盒解决方案中和潜在转换选项中所包括的典型自定义。 我们正计划为每个自定义类型添加更多信息,以使你拥有转换选项的实际示例。

自定义 转换选项
具有空程序集的声明性解决方案

你可以通过 Visual Studio 解决方案项目属性来控制程序集创建。 有关详细信息,请参阅将程序集引用从 Visual Studio 所创建的沙盒解决方案中删除



重要说明:使用 SharePoint 沙盒解决方案扫描程序时,扫描输出会列出包含空程序集的解决方案,并且工具会更新已删除其中程序集的沙盒解决方案包。 然后,只需将现有沙盒解决方案替换为更新后的解决方案。

包含代码的 InfoPath 表单

如果你已经从 InfoPath 客户端发布了包含代码的 InfoPath 表单,则其实际上是作为沙盒解决方案发布到了 SharePoint。 这意味着表单代码实际上是由 SharePoint 中的沙盒引擎执行的。

脱离基于代码的 InfoPath 表单取决于实际业务用例。 具有多个选项可生成自定义 UI 作为外接程序或使用其他表单技术。

有关详细信息,请参阅在沙盒解决方案中修复 InfoPath

Web 部件

通常情况下,Web 部件转换为外接程序部件,或使用 JavaScript 嵌入模式通过完全的客户端技术来实现。

有关更多信息,请参阅:

可视 Web 部件

可视 Web 部件转换的方式与普通的 Web 部件转换的方式类似。 可视 Web 部件中使用的用户控件也必须被替换,因为在沙盒解决方案事例中,它被包括在程序集内。

事件接收器

在很多情况下,都可以通过远程事件接收器实现事件接收器的替换。 但是,远程事件接收器的确需要托管在一些平台中,尤其是特定提供程序托管的外接程序。

有关更多信息,请参阅:

功能接收器

功能接收器通常替换为基于远程 API 的操作,如使用 CSOM 或 REST 在网站级别应用所需的自定义或配置。 如果远程 API (CSOM/REST) 缺少所需的 API,则使用 SharePoint UserVoice(#sharepoint-uservoice) 报告此缺陷。

功能接收器用于在其激活时向网站设置自定义母版页或主题的示例。 这类操作可以轻松地替换为基于远程代码的解决方案或使用 PnP PowerShell,PnP PowerShell 提供了控制网站配置的简单命令。

自定义工作流操作

这些类的自定义的典型代码迁移路径使用 SharePoint 工作流、替代解决方案(如 Microsoft Flow)或第三方解决方案。

从网站移除沙盒代码

从网站停用现有沙盒解决方案时,使用声明性选项部署的任何资产或文件都不会被删除。 如果已使用沙盒解决方案引入了基于代码的新 Web 部件,则这些功能将被网站禁用。 这意味着页面仍正常呈现,因此解决方案被停用时不会对最终用户产生直接影响(除非删除基于代码的功能,如 Web 部件)。

删除对基于代码的沙盒解决方案的支持

通过禁用基于代码的操作(从基于沙盒解决方案的代码执行),将从 SharePoint Online 中删除对基于代码的沙盒解决方案的支持。 这意味着将不会从解决方案存储中显式停用沙盒解决方案,但将不再执行任何基于代码的操作。 在解决方案库中,沙盒解决方案将处于“保持激活”状态。 使用沙盒解决方案部署的功能将不会自动被停用,这意味着将不会运行与功能停用或卸载处理程序关联的代码。

在 SharePoint Online 应用此更改后,沙盒解决方案中的所有声明性定义都将继续有效。

本节内容

另请参阅