Решения / функции для редакций коммерческого продукта SharePoint

Предположим на мгновение, что вы создаете коммерческий продукт для SharePoint. Этот продукт будет предлагаться как в версии Community (бесплатная), так и в версии Enterprise (платная).

База кода для версии Community - это подмножество с небольшими дельтами, которые обрабатываются с помощью операторов (C #) #define. Фактически это единая кодовая база. В процессе сборки создаются два решения (каждое из которых содержит две функции), по одному для каждого выпуска.

Невозможно установить оба выпуска в ферме одновременно. Текущая бизнес-модель предлагает версию сообщества / бесплатную только для ферм SharePoint с одним сервером. Это предназначено для поддержки отдельных лиц и сценариев развития.

Решения включают в себя множество функциональных элементов, но в настоящее время не содержат веб-частей. Возможно, что одна или несколько веб-частей могут быть включены в будущий выпуск. Любой подход, ограничивающий содержание решения / функции, вероятно, не лучшая идея в долгосрочной перспективе.

В какой степени вы бы повторно использовали идентификаторы решений и / или функций в разных редакциях? Почему?


sharepoint wsp
person Jason Weber    schedule 02.11.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Я бы хотел, чтобы люди могли легко обновиться с бесплатной до полной, если они захотят это сделать.

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

Я думаю, вам нужно оставить значение solutionId таким же, чтобы это сработало.

Вам также необходимо, чтобы полное имя сборки было таким же (версия файла может быть другой) или настроить перенаправления привязки.

О, и, конечно, никаких критических изменений в вашем коде.

person Ryan    schedule 02.11.2009
comment
Спасибо за ваш ответ. Ваша логика относительно желаемого поведения при обновлении имеет смысл. Способ разработки решения. Описанное вами поведение при обновлении может быть выполнено с помощью обоих подходов. Есть ли другие причины пойти в ту или иную сторону? - person Jason Weber; 02.11.2009
comment
Вы уверены, что при изменении SolutionId SharePoint загрузит новую веб-часть вместо старой, которую пользователи уже настроили? Я догадывался, что этого не произойдет, и вы получите ошибку «Отсутствует сборка», но не успел проверить. - person Ryan; 02.11.2009
comment
Это интересный момент. Веб-части привязаны к сборке со строгим именем. Как вы предлагаете, мне нужно будет проверить, есть ли дополнительная привязка на уровне функции или решения. - person Jason Weber; 03.11.2009

arrow_upward
1
arrow_downward

Я бы использовал те же идентификаторы и предоставил дополнительную функцию для разблокировки корпоративных функций. Эта функция содержит дополнительные библиотеки DLL, веб-части, лицензионные ключи ..., необходимые для разблокировки Enterprise Edition.

Я бы позаботился о том, чтобы пользователи могли продолжать использовать ваш продукт после обновления, не изменяя свои настройки.

person Wout    schedule 02.11.2009
comment
Ключевым моментом является упрощение обновления без «потери» чего-либо. Модель обновления с помощью дополнительных функций может быть очень убедительной. Это очень хорошо работает, например, для стандартных элементов управления поиском уровня предприятия в SharePoint 2007. В других случаях, таких как приемник событий, это может потребовать значительно больше усилий. Спасибо за ваш ответ. - person Jason Weber; 03.11.2009