Загальна схема
- WSP пакет спочатку попадає в конфігураційну базу
- При розгортанні файли з пакету потрапляють на комп'ютери ферми, це стосується фич, збірок і файлів програми.
- При активації фич на основі маніфесту в тематичній базі створюються записи, які посилаються на файли на диску.
Така схема була винайдена в ранніх версіях SharePoint, щоб економити місце в базі, якщо одна і та ж функціональність використовується на багатьох сайтах. Крім того так дуже зручно оновлювати, досить розгорнути нову версію пакету і всі сайти отримають зміни.
На практиці така схема працює погано.
Проблеми починаються тоді, коли файли \ поля \ типи \ списки змінюються. Коли це відбувається в базу записується схема (XML визначення) або сам оновлений файл, а зв'язок з файлом на диску втрачається. Цей стан називається unghosted або customized. Подальше оновлення шляхом оновлення файлів на диску вже перестає працювати.
Ситуація ускладнюється тим, що деактивація фич не видаляти списки і файли і не видаляє типи контенту і поля, на які посилаються списки. Повторна активація фич, при наявності артефактів в тематичній базі, працює абсолютно непередбачувано.
Можна, звичайно, все артефакти створювати за допомогою XML, уникаючи коду, який викликає кастомізацію. Але далеко не всі рішення можна робити таким чином. Багато речей, на кшталт таксономії, audience targeting і metadata mavigation в XML описати дуже складно. Але найголовніше, що кастомизация може бути викликана користувачем. А якщо можливість кастомізації заблокувати, то втрачається гнучкість, яку дає SharePoint.
Ще одна проблема пов'язана зі списками і шаблонами (визначеннями) списків. Якщо список створений за шаблоном і не кастомизировать, але шаблон відсутній на диску, то з'являється безліч незрозумілих помилок при використанні API і деяких стандартних функцій.
Через ці проблем багато повністю відмовилися від розгортання артефактів за допомогою XML визначень і почали робити створення артефактів за допомогою коду. Цей підхід набагато більш багатослівний і підвищує ймовірність помилок, але при цьому дає контрольованість процесу при створенні, і найважливіше, при оновленні артефактів.
Перша зміна - додавання прапорів Overwrite в визначеннях полів і типів контенту. З цим прапором поля і типи при активації фичи записуються в контентную базу, без створення прив'язки до файлів на диску. Крім того стала можлива повторна активація фич при наявності артефактів в тематичній базі даних. Це частково вирішує проблему, але тільки частково, так як проблема зі списками, створеними з шаблонів, не наважується.
Друга зміна - додавання можливості апгрейда фич. Тепер можна не видаляти рішення і не переактівіровать фичи для отримання нової функціональності.
Третя зміна - поява Sandbox рішень, які не використовують файли в файлової системі і створюють всі артефакти відразу в тематичній базі. При цьому відкат Sandbox рішення викликає деактивацію всіх фіч, а для FullTrust такого не відбувається.
Здавалося б тепер можна зробити те що потрібно, використовуючи правильні можливості. Але вийшла ще одна промашка - все зміни майже ніяк не задокументовані і процес розгортання став ще більш непередбачуваний і взагалі склалася ситуація коли ніхто не знає як робити правильно.
Що ж робити
Варіант перший - робити все кодом. На жаль коду виходить дуже багато і писати його дуже клопітно. Деякі речі зробити кодом складно, деякі взагалі неможливо.
Варіант другий - робити розгортання в XML, що не деактивувати фичи (особливо якщо веде до втрат даних або до порушення працездатності), які не відкочувати рішення, використовувати feature upgrade. Це теж вимагає написання коду, але в набагато меншому обсязі.
До речі використовувати активацію фич для поставки функціоналу користувачеві - теж не кращий варіант. Набагато краще:
- Створення сайтів за шаблоном.
- Створення списків за шаблоном.
- Додатковими пунктами в меню адміністрування (для сайтів, списків, типів контенту).
- Розширенням існуючого функціоналу.
Сам фичи найкраще робити прихованими, активувати їх автоматично при розгортанні рішення або скриптом установки.
Якщо ж робите фичу видимої, то потрібно завжди тестувати можливість її багаторазового активації \ деактивації, в тому числі на різних сайтах і колекціях сайтів.
висновок
Якщо ви працюєте з SharePoint, то вам в будь-якому випадку необхідно знати як працює розгортання артефактів. Дізнатися це можна типовим для SharePoint способом - копирсання збірок в ILSpy або Reflector. Більшу частину з того, що я описав в цьому пості я дізнався саме з збірки Microsoft.SharePoint.
Наступного разу розповім як користуватися працює feature upgrade і як швидко створювати рішення в SharePoint.
