Как следует управлять проектами SharePoint Visual Studio, которые используют общий код друг друга?

В настоящее время структура решения My SharePoint Visual Studio содержит следующие проекты:

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

Я использую WSPBuilder, поэтому каждый проект (кроме консольных приложений) имеет собственный файл решения SharePoint WSP.

Это хороший способ разделить код SharePoint? Какие подходы вы используете?


visual-studio sharepoint solution projects-and-solutions wspbuilder
person Alex Angas    schedule 13.05.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

Для большинства проектов я предпочитаю иметь единый пакет решения с необходимыми общими библиотеками, которые обычно устанавливаются в GAC.

person Tom Clarkson    schedule 13.05.2009
comment
Хорошие моменты здесь, хотя при планировании обновлений общий пакет здесь должен быть независимым от SharePoint - необходимость поддерживать обратную совместимость столь же велика. - person Greg Hurlman; 13.05.2009

arrow_upward
2
arrow_downward

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

person Kirk Liemohn    schedule 13.05.2009