2010年6月3日,星期四

升级沙盒解决方案

I’最近,我非常关注应用程序生命周期管理和SharePoint 2010,涵盖诸如解决方案和功能框架的更改之类的内容,尤其是为了‘upgrading’ Features. I’尚未在此处发布太多信息(但),但在最近的SharePoint Evolutions会议上分两期进行了介绍(你可以在这里拿我的滑板),并在‘真实世界SharePoint 2010’(又称MVP书)。今天我想简要介绍一下我做过的一些信息’设法在会议上谈论– specifically ALM和沙箱。就像服务器场解决方案一样,大多数沙盒解决方案很可能会在其生命周期中不断发展,增加新功能并完善现有功能-将对代码和工件(例如内容类型,列表定义等)进行更改。供应商将发布其产品的新版本,客户将要求对他们使用的其他解决方案进行增强,这些解决方案以沙盒解决方案的形式提供。重要的是,场解决方案和沙盒解决方案对现有应用进行此类更改的过程有所不同–这篇文章探讨了这些差异。

旁注:此信息的最佳起点是了解SP2010 ALM概念,例如功能升级,更好地支持组件版本控制等。-前面链接的滑盖涵盖了这些内容,但我’我会尽力为每个观点提供一些背景知识。

差异1– 升级 Solution packages

Most devs 和 admins are familiar with 升级 WSPs using STSADM–o upgradesolution 或者‘retract/dedeploy’周期。在SharePoint 2010中,除了添加PowerShell命令(例如, 更新SP解决方案. The key difference when 升级 sandboxed solutions is that 每次升级时都必须提供WSP的新文件名– 然后在内部使用解决方案ID将事物捆绑在一起。一世’m假定这是因为沙盒解决方案的所有版本都存储在解决方案库中(与服务器场解决方案不同,场解决方案仅在部署/升级完成后才存储最新版本),当然,解决方案库从根本上来说就是SharePoint列表–像其他任何东西一样’t允许多个具有相同标题的项目。 

毫无疑问,Microsoft可以选择其他选项,例如使用列表项版本控制或使用单独的字段作为名称和标题,但是显然这些方法不是首选,因此重命名WSP。逻辑方法可能是将版本号添加到沙盒解决方案的WSP文件名中。

差异2–功能升级和QueryFeatures()

功能升级框架通常是更改现有SP2010站点的好方法–简而言之,它通常与新的 QueryFeatures() API中的方法,可帮助您找到功能 实例 在 different scopes which need 升级. A Feature instance needs 升级 when the corresponding Feature.xml file in the SharePoint root has an incremented version number (e.g. 2.0.0.0) but SPFeature.Upgrade() 该实例尚未被调用。发生的是您在跑步 QueryFeatures() 在适当的对象上(例如,SPSite查找站点或Web范围内的Feature实例),然后调用 SPFeature.Upgrade() 对于所有退回的物品, 假设您想在任何地方升级功能. As an example, if you had a site collection with 50 网and called SPSite.QueryFeatures(SPFeatureScope.Site,true), 然后,您将在Web范围内获得50个Feature实例的集合并调用 SPFeature.Upgrade() 每一个。或者,您可以选择仅升级 已选 网–例如当只有某些网站应该接收更新的功能时。

沙箱的主要区别在于 无法有选择地升级功能实例 – 升级 the WSP has the effect of calling SPFeature.Upgrade() 自动地 对于所有实例。这意味着该领域的灵活性可能较低,这在某些情况下可能很重要。

差异3–沙箱中的程序集版本控制问题

SharePoint 2010中ALM的一项关键改进是增加了对版本管理程序集的支持。 WSP软件包现在可以添加 绑定重定向 元素到web.config,这意味着对1.0.0.0程序集的引用可以重定向到(例如)2.0.0.0。在某些情况下,这在沙盒解决方案和服务器场解决方案中同样有效,但是我的测试显示了包含Web部件或其他控件的沙盒程序集存在问题。除了主要问题外,目前还存在一些小问题,包括沙盒解决方案和服务器场解决方案,以及 安全控制 条目-WSP部署删除1.0.0.0条目和2.0.0.0 安全控制 单独进入不是’t sufficient so a “类型未注册为安全的”发生错误。但是请注意,这可以通过以下方法缓解 手动地 编辑解决方案清单以添加1.0.0.0条目,该条目将与自动生成的2.0.0.0条目合并。似乎更严重的是 在使用沙箱中的Web部件对装配进行版本控制时,甚至执行此缓解步骤以确保所有 绑定重定向安全控制 条目是正确的结果,导致Web部件损坏 (错误“部分信任应用程序域中的沙盒代码包装器的Execute方法引发了未处理的异常:发生意外错误”).

由于预计将有许多Web部件供应商使用沙箱(除了我们其余的人),这意味着许多供应商将无法利用沙箱中的版本控制和版本管理改进(至少对于Web部件而言)。其他策略,例如使用 FileAssemblyVersion 而是可能需要版本控制(dosn’t affect binding/安全控制)。产品小组中的一些人正在与我在沙箱中实施版本控制的团队进行交流,因此我’希望能找到更多信息并更新这篇文章。现在我’我希望我的(许多)测试中存在缺陷-如果没有,我’m hoping it’我们可能很快就会看到一些问题。一世’ll keep you posted.

2条评论:

碧玉说过...

克里斯,你好

I was wondering what you found out about 升级 when talking to the product team. I'我在SharePoint Online中遇到了同样的事情'升级的选项更少(没有powershell)。

我需要的是即使在开发场景中也可以使用可升级解决方案的好方法's。例如,是否有一种方法可以使Visual Studio在部署WSP之前对其进行重命名?我想知道你的工作清单's 和 dont's is. Thanks.

克里斯·奥'Brien说过...

@碧玉,

不幸的是我没有'与产品团队进行的沙盒/版本讨论不那么深入。 IIRC,我们开始了电子邮件对话,但不幸的是,我停止了回复,因为有人继续前进。

I'我还没有意识到将WSP重命名作为Visual Studio开发工作流一部分的自动方法-我认为这需要手动完成。我没有'我没有为SharePoint Online做过很多开发,但是我认为我的方法是针对最初运行沙盒服务的本地SharePoint实例进行开发,然后在准备好时才部署到SPO。这样,大部分迭代是在您拥有更多控制权的环境中完成的。

祝好运。

克里斯。