Feature.xml の変更点

最終更新日: 2015年3月9日

適用対象: SharePoint Foundation 2010

Feature.xml ファイルの新しい <UpgradeActions> セクションでは、指定したフィーチャーに適用できるアップグレード アクションを指定します。

<UpgradeActions> セクションは、Feature.xml ファイルの先頭または末尾で、<Feature> 要素の内部に配置できます。このセクションでは、さまざまなアップグレード範囲に対してアップグレード アクションを指定し、指定した範囲に適用されるアップグレード アクションのリストを追加できます。アップグレード定義は、必ずフィーチャーを <Feature> 要素に宣言されているバージョンにアップグレードします。

次のコードは、Feature.xml ファイルに定義できる <UpgradeActions> セクションのサンプルです。

<UpgradeActions 
  ReceiverAssembly="MyFeatureReceiver, 
  Version=1.0.0.0, 
  Culture=neutral, 
  PublicKeyToken=2f2197d99d6e2871" 
  ReceiverClass="FeatureReceiver.TestFeatureReceiver">
  <CustomUpgradeAction 
    Name="DeleteField">
    <Parameters>
      <Parameter 
        Name="FieldName">Address3
      </Parameter>
    </Parameters>
  </CustomUpgradeAction>
  <VersionRange 
    BeginVersion="2.0.0.0" 
    EndVersion="5.0.0.0">
      <!-- Here you specify other upgrade actions to apply to Feature instances whose versions are within the range 2.0.0.0 to 5.0.0.0 -->
  </VersionRange>
</UpgradeActions>

<UpgradeActions> セクションでは、フィーチャーのインスタンスをアップグレードする方法を指定します。普通のアップグレード シナリオは、Feature.xml ファイルを変更するだけで宣言によって完成しますが、高度なシナリオの場合は、FeatureUpgrading(SPFeatureReceiverProperties, String, IDictionary<String, String>) メソッドを実装して、カスタム フィーチャー アップグレード ロジックを実行する必要がある場合があります。宣言型要素の詳細については、「要素マニフェストの範囲と準備」を参照してください。

<UpgradeActions> 要素には、次のサブ要素を格納できます。

• <CustomUpgradeAction> — フィーチャーのインスタンスをアップグレードするときにカスタム コードを実行できます。アップグレード アクション シーケンスにアクションを指定すると、Microsoft SharePoint Foundation は、他のアップグレード アクションと同期して、宣言順に FeatureUpgrading(SPFeatureReceiverProperties, String, IDictionary<String, String>) メソッドを呼び出します。

• <VersionRange> — 指定したアップグレード アクションが適用されるバージョン範囲を指定します。

• <ApplyElementManifests> — 新しい要素を既存のフィーチャーに追加します。フィーチャーをアップグレードするときは、指定した要素マニフェストで参照されるすべての非宣言的要素を準備します。

• <AddContentTypeField> — 新しいフィールドを既存の準備されたコンテンツ タイプに追加します。変更内容をサイト コンテンツ タイプからサイト内のすべての子リストとコンテンツ タイプに伝達します。以下に例を示します。

  <AddContentTypeField 
    ContentTypeId="0x010100A6F9CE1AFE2A48f0A3E6CB5BB770B0F7" 
    FieldId="{B250DCFD-9310-4e2d-85F2-BE2DA37A57D2}" 
    PushDown="TRUE" />
  

  ほとんどの場合、ContentTypeId 属性と FieldId 属性の値は、Elements.xml ファイルで指定します。このファイルでは、コンテンツ タイプとフィールドを定義します。

• <MapFile> — カスタマイズされていないファイルをフロントエンド Web サーバー上の別の場所にマッピングできます。FromPath 属性と ToPath 属性を使用して、フィーチャーにあるファイルの名前を変更できます (たとえば、<MapFile FromPath=”oldname.gif” ToPath=”newname.gif” />)。ただし、MapFile を使用してファイルを移動することもできます。この場合、FromPath 属性と ToPath 属性には、TEMPLATE ディレクトリを基準にした相対パスを指定します。たとえば、"MyFeature" という名前のフィーチャーに "Gifs"ディレクトリにインストールされている .gif ファイルがあり (たとえば、%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES\MyFeature\Gifs\basketball.gif)、バージョン 2 では、ディレクトリの名前を "Gifs" から "Images" に変更する場合は、<MapFile FromPath=”Gifs\ball.gif” ToPath=”Images\basketball.gif” /> を使用してファイルを移動できます。

バージョン管理されたフィーチャーの依存関係を操作しやすくするために、MinimumVersion 属性が <ActivationDependency> 要素に追加されました。この属性は、あるフィーチャーが、バージョン番号が MinimumVersion 以上である必要がある別のフィーチャーに依存するときに使用します。

要素マニフェストの範囲と準備

次の表では、特定の Feature 要素の有効範囲、その要素が、フィーチャーをアクティブ化したときに準備されるのかどうか、フィーチャーを非アクティブ化したときに準備が解除されるのかどうかを示します。

表からわかるように、<CustomAction> 要素は、Web (Web サイト)、Site (サイト コレクション)、WebApplication、および Farm (サーバー ファーム) というすべての範囲で使用できます。この要素は、準備も準備解除も行われない宣言型要素です。つまり、この要素は、フィーチャー XML 定義からメモリに直接キャッシュされ、フィーチャーのアクティブ化時に準備ロジックが実行されません。このため、フィーチャーをアクティブ化した後にカスタム アクションを含んでいるページに移動すると、カスタム アクションはキャッシュから読み込まれ、そのページに表示されます。Field 要素は、サイト コレクション範囲でのみ有効です。この要素は、アクティブ化時に準備され (サイト内の列が作成される)、非アクティブ化時に準備解除されます (サイト内の列が削除される)。<ListInstance> 要素は、Web とサイト コレクション範囲で有効です。この要素は、アクティブ化時に準備され (リスト インスタンスが作成される)、非アクティブ化時に準備解除されません (リスト インスタンスが削除されない)。