Должен ли я держать решения и функции в соотношении 1: 1?

Question

У меня сложное развертывание sharepoint с несколькими EventReceivers и рабочими процессами.

У меня также есть изменения схемы в существующих списках, добавление новых столбцов метаданных и изменение существующих столбцов.

Должен ли я упаковать одну функцию, приемник событий или рабочий процесс в одно решение или я должен поместить несколько функций в одно решение, поскольку все они работают вместе?

Одна из основных причин, по которой я спрашиваю, - это будущие обновления кода. Если функции разделены, то обновление одной части кода не потребует повторного развертывания всех функций в решении. Это то, о чем я должен беспокоиться, или «stsadmin -o upgradedesolution» решает любые проблемы с обновлением решения с множеством функций?

Дайте мне знать, имеет ли это смысл для любого гуру SharePoint.

Спасибо,
Keith

Обновление: Глядя на сайт drax , на который я ссылаюсь, я нашел этот справочный сайт: http://msdn.microsoft.com/en-us/library/aa543659.aspx

Это утверждение, по-видимому, сильно затрудняет обновление функций в решениях:

Обновление решения может использоваться только для заменить файлы. Вы можете добавить новые файлы в решении обновить и удалить старые версии файлов, но вы не можете установить функции или использовать событие функции обработчики для запуска кода для Feature установка и активация. следующие операции не поддерживаются в обновлении решения.

• Удаление старых функций в новом версия решения.

• Добавление новых функций в решение обновить.

• Обновление или замена приемника сборка для существующих функций в новая версия решения.

• Добавление или изменение элементов Feature (Файлы Element.xml) в новой версии решения.

• Добавление или изменение функции свойства в новой версии решение.

• Изменение идентификатора или объема старых Особенности в новой версии решение.

• Удаление элементов элемента (Файлы Element.xml) в новой версии раствора.

• Удаление свойств объекта в новом версия решения.

Итак ... Что вы можете сделать с обновлением решения?

Answer 1

Я бы посоветовал против , разбив все на несколько решений. Поддержание, которое может быстро стать кошмаром. Попробуйте структурировать ваш проект, который должен использоваться для создания WSP, таким же образом, как 12 папок на sharepoint. Тогда вы можете использовать WSP builder , последняя стабильная версия приносит много полезных вещей.

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

РЕДАКТИРОВАНИЕ:

Итак, я провел небольшое исследование по теме обновления MOSS. По мнению MS, существует два способа обновления решений:

1. Обновление на месте
2. Инкрементное обновление

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

Инкрементное обновление (так его называет, вероятно, MS) не использует встроенные решения. Это означает, что каждый может реализовать это самостоятельно :(. Что еще лучше, я не смог найти какие-либо рекомендации для этого подхода. Я полагаю, что этот подход вы бы хотели использовать как пример постепенного обновления (разделение проекта на много независимых решений).

Также обратите внимание, что инкрементное обновление официально не поддерживается MS.

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

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

Answer 2

UpgradeSolution действительно удобен, если вы просто обновляете сборку и оставляете предоставленные файлы без изменений.

Если вы не укажете -local, то upgradedesolution выполнит полный iisreset для всей вашей инфраструктуры. Это действительно стоит отметить, когда вы планируете подходящее время для выполнения обновлений.

Answer 3

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