Инструментарий разработчика решений под SharePoint 2010

СДЦ > Статьи > Инструментарий разработчика решений под SharePoint 2010

Введение. Версия SharePoint 2010 уже прочно заняла свою нишу на рынке портальных решений, уверенно продолжая успех предыдущей версии SharePoint 2007. Список изменений достаточно большой, были переработаны и подход к организации сервисных служб (отказ от Shared Services Provider) и интерфейс стал более прост, сохранив свою функциональность. В то же время по статистике Microsoft на уровне API было сохранено 95 % свойств и методов. Только вдумайтесь в это число. Практически весь внутренний мир SharePoint’а, доступный разработчику решений, остался прежним. Кроме облегчения переноса приложений под новую версию SharePoint это служит отличным стимулом разработчикам инструментов для создания приложений адаптировать свои инструменты для поддержки SharePoint 2010. Очевидно, что в данных обстоятельствах начинать рассказ об инструментарии разработчика 2010 версии с нуля, не оглядываясь на предыдущую версию SharePoint, просто нелогично. Так давайте же разберемся, как эволюционировал инструментарий разработчика решений под SharePoint 2010.

Инструментарий разработчика 2007. В рамках данной статьи необходимо, по крайней мере, в ознакомительном порядке пройтись по инструментам разработки под SharePoint 2007. Итак, разработчик решений мог использовать следующие основные инструменты:

1. Visual Studio 2008 + VseWss 1.2 / 1.3 beta (нестабильно)

Предыдущая версия Visual Studio не обладала даже минимальным встроенным функционалом для разработки решений под SharePoint, что послужило толчком для воздания различных вспомогательных сторонних утилит, упрощающих в каком-то смысле создание решений, а прежде всего, утомительный сбор пакетов решений (файлов wsp). Позже Microsoft все же предоставила специальный плагин Visual Studio Extentions for WSS, основной версией которого стала версия 1.2. Данная версия обладала рядом недостатков, основным из которых была невозможность сборки пакета решения без установки оного, что было чрезвычайно неудобно в случае использования сервера разработки несколькими разработчиками. Кроме того, не было никакой возможности собрать такое решение из командной строки, что делало невозможным использование сервера непрерывной сборки. Форумы пестрили просьбами решить две вышеперечисленные проблемы и в ответ на это была выпущена следующая версия плагина 1.3. Данная версия так и не получила статус стабильной, остановившись на статусе CTP, однако ей все же возможно было пользоваться и, самое главное, была предоставлена, наконец, возможность собирать пакет без установки решения, а также можно было заставить Visual Studio сгенерировать установочный пакет из командной строки, хотя работал этот механизм крайне нестабильно и на практике был неприменим.

2. SharePoint Designer 2007

Позиционируемый как инструмент разработчика, администратора и даже продвинутого пользователя, SharePoint Designer пришел на смену FrontPage. Безусловно, без него разработка решений под SharePoint была бы много более утомительной: весь интерфейс SharePoint построен на шаблонах достаточно сложной структуры, – но и проблем с его использованием было предостаточно. Чего только стоило настойчивое желание SharePoint Designer дописывать ничего не значащие символы в тело веб-частей, что частенько приводило к страницам размером в несколько мегабайт, да и «падения» приложения были достаточно частыми.

Без сомнения, не имея под рукой инструментов, перечисленных выше, создавать приложения под SharePoint было невозможно, но существовали и другие инструменты более узкого применения, которые иногда могли оказаться крайне полезными:

3. SharePoint Manager 2007

Отличный инструмент, если необходимо что-то посмотреть, используя SharePoint API. Позволял видеть SharePoint в виде дерева, узлы которого соответствовали различным объектам SharePoint: спискам, полям, узлам, обработчикам событий, определениям заданий таймера и др. SharePoint Manager кроме чтения значений свойств позволяет также осуществлять их модификацию, что в некоторых случаях является достаточно опасной процедурой, поэтому его можно порекомендовать только опытным SharePoint-разработчикам.

4. Reflector

Незаменимый инструмент, когда необходимо прояснить разночтения или недосказанности в документации по отношению к реально работающему коду SharePoint. Позволяет дизассемблировать любую библиотеку .NET (не только SharePoint, хотя в данном случае нам интересны именно они) и отобразить содержимое на высокоуровневом языке типа C#.

5. U2U CAML Query Builder 4

Не секрет, что язык CAML являлся, да и до сих пор остается единственным языком запроса данных SharePoint. Запросы в данном случае имеют Xml формат и достаточно сложны для написания с нуля. Для их построения  было удобно использовать U2U CAML Query Builder 4, который позволял получить готовый запрос, не написав при этом ни единой строчки текста.

6. Business Data Catalog Definition Editor

Данный инструмент являлся частью SharePoint SDK и предназначался для составления описаний источников бизнес-данных, необходимых для подключения внешних систем к инфраструктуре SharePoint.

В процессе разработки возникает необходимость в использовании многих других инструментов, таких как система контроля версий, сервер непрерывной сборки, однако все они не являются SharePoint-ориентированными, поэтому в рамках данной статьи не рассматриваются.

Инструментарий разработчика 2010. Ну что же, настала пора рассмотреть инструментарий разработчика решений под SharePoint 2010.

1. Visual Studio 2010

Что же, в новой версии Visual Studio появилась встроенная поддержка SharePoint, причем реализованная на очень высоком уровне. Система разработки вобрала в себя функции многих сторонних инструментов, сделав их ненужными (см. рис. 1).

Рисунок 1. Новая версия Visual Studio вобрала в себя функции других инструментов.

Рисунок 1. Новая версия Visual Studio вобрала в себя функции других инструментов.

Да, среда разработки от Microsoft позволяет теперь разрабатывать решения под SharePoint, практически не прибегая к сторонним утилитам. Сборка решений теперь осуществляется на качественно новом уровне, к тому же она наконец-то встроена в систему сборки .NET, что делает возможной сборку пакетов в режиме командной строки и без использования Visual Studio. Появился новый обозреватель объектов SharePoint, которые выполняет схожие с SharePoint Manager функции, хотя его нельзя назвать полноценной заменой последнему. Изменений много, и обо всех из них можно прочитать по ссылке.

2. SharePoint Designer 2010

Инструмент был переработан для поддержки новой версии SharePoint. Следует отметить, что использование его при работе с предыдущей версией SharePoint невозможно. Визуально, работать SharePoint Designer стал гораздо стабильнее и более предсказуемо.

3. stsadm

Инструмент администратора stsadm теперь объявлен устаревшим и заменен специальной консолью управления SharePoint, которая представляет собой стандартную консоль PowerShell, дополненную специальными плагинами поддержки SharePoint. С этой точки зрения инструмент стал гораздо гибче и универсальный, поскольку позволяет писать достаточно сложные сценарии и работать с объектной моделью SharePoint, не прибегая к компиляции какого-либо кода.

4. SharePoint Manager 2010

По сравнению с предыдущей версией изменений практически нет, кроме, собственно, поддержки новой версии SharePoint. В целом удобный инструмент, который в части чтения свойств объектов может быть замещен встроенным в Visual Studio инструментом, однако возможности его намного шире.

5. Reflector

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

6. SPMetal

Написание CAML-запросов вручную было просто неудобно, да и использование инструментов, подобных U2U CAML Query Builder, облегчало работу, но проверить соответствие данных запросов реальной модели данных SharePoint на этапе компиляции не представлялось возможным без специальных ухищрений. Ситуация в корне изменилась с появлением такого инструмента как SPMetal, а именно, промежуточного слоя доступа к данным, который, к тому же, может быть сгенерирован автоматически по существующей структуре списков и библиотек. Еще одним преимуществом данного подхода является возможность построения linq-запросов к данным, что несравненно проще написания тех же CAML-запросов, хотя справедливости ради заметим, что:

  1. в конечном итоге данный запрос все равно будет преобразован в CAML-запрос, соответственно, наследует все ограничения базового протокола;
  2. присутствуют накладные расходы, которые делают невозможным применение данного подхода в критичных к скорости приложениях;
  3. не во всех случаях возможно использование SPMetal, например, работа с файлами-приложениями в данном режиме невозможна.

7. WseWSS upgrade tool

Специальная утилита, предназначенная для переноса решений, разработанных с использованием связки Visual Studio 2008 + VseWss под Visual Studio 2010. Заметим, что единственное, что делает данная утилита – приводит структуру решения к виду, который принят в последней версии Visual Studio, что в случае больших проектов оказывается очень полезно с точки зрения экономии времени.

Заключение. В заключение хочется отметить, что инструменты разработки под SharePoint стремительно развиваются от версии к версии, а это напрямую отражается на качестве разрабатываемых программных продуктов. Следующую версию SharePoint, если придерживаться существующей практики 4-летнего цикла серверных продуктов Microsoft, следует ожидать не ранее 2013-2014 года, поэтому, хочется верить, нас ожидает еще большое количество новых интересных и полезных проектов, разработанных под эту версию платформы.

Ссылки на страницы загрузки инструментов SharePoint: