Структура решения SharePoint в Visual Studio

Одним из способов успешного создания решения SharePoint является разбиение решения на отдельные зависимые проекты:

• Branding
  В данном проекте находятся все файлы, относящиеся к UI - пользовательскому интерфейсу, в первую очередь изображения и стили css. С этим проектом в основном имеет дело разработчик UI/UX. Как правило в проекте не должно содержаться ни одной строчки кода .NET, что означает отсутствие сборок для развертывания.
• Presentation
  В этом проекте должны находиться веб-части, мастер-страницы, страницы приложения (application pages), элементы управления, и т.п. Это в первую очередь компоненты, которые могут быть исплозованы в разных частях решения. Проект не должен явно зависеть от проекта Branding.
• Definition
  Этот проект содержит типы, столбцы сайта, типы полей, определения списков (list definitions) и сайтов (site definitions), а также шаблоны web. Проект имеет зависимость от проектов Presentation и Branding
• Core
  Этот проект содержит, как правило, единственную сборку, которая представляет главную функциональность, используемую другими проектами. Это можно воспринимать, как бибилиотеку утилит или класс бизнес-логики. В большинстве случаев, проект не должен содержать никаких артефактов SharePoint. Исключение могут составлять файлы JavaScript, которые выступают как утилиты.
• Resources
  Здесь содержатся все файлы языковых ресурсов, используемых остальными проектами. Оформив их в виде отдельного проекта, вы упростите перевод и организацию ресурсов для всего решения.
• Others
  Прочие проекты, в зависимости от типа решения. Предположим, проект для рабочих процессов (workflows).

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

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

Создание нескольких WSP для одного решения также потребует некоторой стандартизации развертывания, позволяющей проконтролировать пререквизиты при установке решения. Имеется множество скриптов для развертывания, доступных на CodePlex. Если вам интересно, гляньте проект "SharePoint Solution Deployer" по ссылке http://spsd.codeplex.com