Изменения в файле Feature.xml

Дата последнего изменения: 9 марта 2015 г.

Применимо к: SharePoint Foundation 2010

Новый раздел <UpgradeActions> в файле Feature.xml определяет действия обновления, которые можно применить к указанному компоненту.

Раздел <UpgradeActions>можно поместить в начало или в конец файла Feature.xml, в содержимом элемента <Feature>. Этот раздел позволяет определить действия обновления для различных видов обновления и включить список действий, применяемых к конкретному виду. Определения обновлений всегда обновляют компонент до версии, объявленной в элементе <Feature>.

Следующий код содержит пример раздела <UpgradeActions>, который может быть определен в файле Feature.xml.

<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>. Позволяет сопоставить ненастраиваемый файл другому местоположению на интерфейсном веб-сервере. Чтобы переименовать файл в компоненте, можно использовать атрибуты FromPath и ToPath (например, <MapFile FromPath="oldname.gif" ToPath="newname.gif" />, но для перемещения файла также можно использовать MapFile. В этом случае атрибуты FromPath и ToPath определяют пути относительно каталога TEMPLATE. Например, если компонент, названный "MyFeature", использует GIF-файлы, установленные в каталоге "Gifs" (например %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" />.

Чтобы помочь работать с зависимостями версий компонентов, в элемент <ActivationDependency> был добавлен атрибут MinimumVersion, используемый, когда компонент зависит от другого компонента, номер версии которого должен быть больше или равен MinimumVersion.

Область действия и подготовка манифестов элементов

В следующей таблице показаны области, в которых конкретный элемент компонента действителен, а также показано, подготавливается ли элемент при активации компонента и удаляется ли он при деактивации компонента.

Примечание
В приведенной таблице не представлены следующие новые типы элементов: Cmdlet, UserMigrator, WebPartAdderExtension, WebTemplate и WorkflowAssociation.

Как показано в таблице, элемент <CustomAction> доступен во всех областях: Web (веб-сайт), Site (семейство веб-сайтов), WebApplication (веб-приложение) и Farm (ферма серверов). Это декларативный элемент, который не подготавливается и не удаляется, то есть он кэшируется из XML-определения прямо в память, без какой либо логики подготовки, реализуемой при активации компонента. По этой причине после активации компонента и перехода на страницы, содержащие настраиваемое действие, это настраиваемое действие загружается из кэша, а затем отображается на соответствующей странице. Элемент Field действителен только в области семейства веб-сайтов. Он подготавливается при активации (создание столбца веб-сайта) и удаляется при деактивации (удалении столбца веб-сайта). Элемент <ListInstance> действителен в областях веб-сайта и семейства веб-сайтов. Он подготавливается при активации (создается экземпляр списка), но не удаляется при деактивации (экземпляр списка не удаляется).

Примечание

Декларативные элементы, указанные в разделе <ElementManifests>, подготавливаются во время активации компонента, но игнорируются при обновлении компонента. Следовательно, для добавления декларативных элементов при обновлении нужно поместить их внутрь раздела <ApplyElementManifests>. Перед вызовом обновления необходимо выполнить iisreset в командной строке, чтобы обновить кэш, либо необходимо использовать обновление развертывания решения.