2010年8月2日,星期一

功能升级(第4部分)– advanced scenarios

在本系列文章中:

  1. 功能升级(第1部分)– fundamentals
  2. 功能升级(第2部分)–一个样本玩
  3. 功能升级(第3部分)–引入SPFeatureUpgrade套件
  4. 功能升级(第4部分)–高级方案(本文)
  5. 功能升级(第5部分)–使用PowerShell升级功能

如果你’如果已经关注了此系列,至少从概念上讲,您现在应该应该已经熟悉SP2010功能升级。当您开始真正使用此功能时,很快就会发现在某些有趣的场景中’很难确定会发生什么。一世’我会记录一些我的例子’我已经知道了这篇文章中的内容,但是当我遇到它们时,还会再回来添加更多案例– kinda like a ‘Feature upgrade FAQ’ of sorts. I don’目前没有太多,但我想分享我现在知道的内容,而不是等待更长的清单出现–如果您有一个设想,’d喜欢退房,请务必发表评论,我’ll look into it.

这里’到目前为止,我有:

题: What happens if multiple 版本范围 元素与我的功能实例版本匹配?

考虑一下我们有一个Feature实例(N.B. 特定实例 一个特征的 特定 网站,网站或网络应用-取决于功能定义中的范围)在1.0.0.0版中,我们对其应用以下升级说明:

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/" Version="3.0.0.0">
  <UpgradeActions>
    <版本范围 BeginVersion="1.0.0.0" EndVersion="1.9.9.9">
        ...
    </版本范围>
    <版本范围 BeginVersion="1.0.0.0" EndVersion="2.9.9.9">
        ...
    </版本范围>
  </UpgradeActions>
</Feature>

回答: 由于两个 版本范围 元素匹配,会发生什么?答案是 版本范围 元素将按照功能在文件中定义的顺序针对功能进行处理。内的任何说明 版本范围 元素将通过声明或命令进行处理 CustomUpgradeAction。这是 大概 你的行为’d expect, but it’很高兴知道。 [附言特别感谢Gary Yeoman(综合知识 教练)赢得了赌注,并在我设法做到这一点之前将其打底:)]

影响: 这意味着如果您有‘overlapping’ 版本范围 这样的元素,您可能需要计划以下事实:两组升级操作将针对范围捕获的Feature实例执行。这可能与服务器场中的其他Feature实例(例如2.0.0.0)形成对比,因此只能被第二个实例捕获。 版本范围。两组Feature实例都在右边吗‘state’升级成功?我们是否首先删除任何内容 版本范围 (例如,内容类型)用于第二个 版本范围?显然,这取决于您’做,但是值得考虑,如果您确实重叠。


问题:如果在站点/网站上首次激活已多次升级的功能,会发生什么情况?

考虑一下您拥有一个网络范围内的功能的情况,该功能已在当前存在的所有网络上几次升级到(例如)3.0.0.0版。如果此时创建一​​个全新的网站会怎样?在此激活功能后,是否执行了所有升级步骤?

回答: No –因为激活和升级是不同的操作。但是,请注意,由于Visual Studio在Feature manifest.xml文件的两个位置添加了元素清单链接,因此会发生一些声明式的配置。具体来说,如果您在功能升级期间添加了新元素清单(例如,提供了一些新的字段/内容类型/模块等),Visual Studio会将其添加到 UpgradeActions / 版本范围 / ApplyElementManifests 款也成好老式 元素清单 也是–您可以通过查看生成的文件的预览来查看。当然,后一部分是SharePoint功能在功能激活中一直使用的内容,这意味着在初始激活和后续升级时都将配置被引用元素文件中的任何工件。注意,这仅适用于元素文件-其他声明性步骤,例如 AddContentTypeField地图文件 仅特定于升级,并且同样适用于与 CustomUpgradeAction.

影响: 必须精心设计功能部件,以处理功能部件实例具有不同生命周期的事实。由于新功能的版本号为0.0.0.0,因此一个选项可能是使用重叠 版本范围 元素(如上所述)始终从0.0.0.0开始,然后在我们的方案中创建新站点/网站时立即升级功能。否则,如果您要使用 AddContentTypeField 要么 CustomUpgradeAction,则可能有必要确保在激活时也执行相同的步骤–例如,通过确保调用相同的代码 功能升级FeatureActivated。这很好地说明了功能生命周期的某些复杂性。
   

题: 功能激活依赖性是否会影响功能实例的升级顺序?

回答: 是– any 取决于 功能将先于相关功能升级。

影响: 应该可以参考‘parent’在从属功能部件的同一功能部件升级周期中提供的工件。例如,如果功能升级提供了一个字段,则从属功能将能够引用相同的字段,因为在升级执行时该字段将存在。

概要

This post outlines some considerations around Feature upgrade 和 ALM in SharePoint, 和 (probably!) concludes my series on this topic. 如果你’有兴趣了解更多关于这一点,我有一章 真实世界SharePoint 2010 (“SharePoint MVP书”),我将在此讨论相关主题-在其中涵盖了诸如SharePoint 2010开发中的程序集版本管理以及程序集/版本策略建议之类的内容。

附言一世’d喜欢听到任何有趣的功能升级方案,供我测试以添加到列表中!

7条评论:

安德斯·拉斯克(Anders Rask)说过...

很棒的文章。
关于功能激活的依赖关系,我似乎记得当我写DIWUG电子杂志的功能升级文章时,如果我只是迭代QueryFeatures()给出的所有功能,而某个功能依赖于另一个功能,则当我调用upgrade时会抛出异常。它。我必须检查一下...

科尼利厄斯·范·戴克说过...

优秀文章克里斯。我们正在进行主要的内容迁移,并且出现了升级功能的主题。感谢您抽出宝贵的时间将其记录在纸上。

未知说过...

谢谢克里斯!此页面上的第一个主题是我过去3天一直在思考的确切问题! :)

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

@Pallavi,

很酷,很高兴它很有用!如果您还有其他问题,您知道我在哪里:)

克里斯。

伍特·范·沃格特说过...

嗨,杰里米,

请注意,版本范围是endVersion属性的专有范围。例如。不要't指定1.9.9.9,但指定2.0.0.0。这是有道理的,因为1.9.9.9不是一个好的值。 1.9999999.9999999.9999999.99999999就是这样,但事实并非如此'没有道理。幸运的是,最终版本是排他性的,您可以在MS代码中进行验证:

内部静态布尔值InRange(SPVersionRange范围,版本)
{
return((((range == null)||(null ==版本))||((((null == range.BeginVersion)||(range.BeginVersion<= version)) &&((null == range.EndVersion)||(range.EndVersion> version))));
}


希望能帮助到你,

伍特

伍特·范·沃格特说过...

我只是叫你杰里米·克里斯吗?

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

@Wouter,

感谢您的澄清。瓦尔德克(Waldek)不久前就向我提出了这个要求,但我仍然没有'有机会检查一下。我相信你们俩,所以谢谢!

杰里米(和克里斯)。