Про XSLT и Visual Studio: отладка и intellisense

По результатам публикации статьи SharePoint и XSLT: Hello world!, уже появились недовольные читатели, восклицающие в комментариях, что вот мол, использовать Блокнот/SharePoint Designer это непрофессионально... :) Примерно такие же отзывы я слышал и на RUSUG, где недавно читал доклад "SharePoint и XSLT".

И на самом деле я согласен, что будучи разработчиком, и имея такой мощный и многофункциональный инструмент, как Visual Studio, хотелось бы использовать его богатые возможности для работы с XSLT в SharePoint. Точнее, хотя бы попробовать это сделать :))

Ну вот давайте посмотрим, на что способна (или не способна?) Visual Studio.

Intellisense

Вот вроде как, "Подумаешь, XSLT intellisense в Visual Studio настроить. Легко!". Легко, да не совсем! Во-первых, в редакторе XSLT в студии просто нет интеллисенса для XPath. Во-вторых, нет xsd-схем для SharePoint'овских расширений XSLT. В свое время, потратил целый день, пытаясь найти хоть какие-нибудь XSD - безрезультатно. Те, которые лежат в каталоге 14\TEMPLATE\XML, не подходят.

Так что в плане intellisense, максимум что мы получим в Visual Studio - это автоподстановки и подсказки по стандартной схеме XSLT. Всё. #fail

SharePoint Designer в этом отношении на 5 корпусов впереди: в нем есть довольно продвинутый intellisense для XPath, поддерживается значительная часть тегов расширения, причем никакого ручного подключения файлов входных данных не требуется - они автоматически подхватываются из веб-части, для которой осуществляется редактирование тэга <Xsl>.

Отладка

Ок, но хотя бы отладку XSLT можно запустить из студии!? Уж в этом-то студия не должна подвести!

Но и здесь нас ждет некоторое огорчение. Во-первых, схемы XSLT в SharePoint'е весьма сложные, и требуют огромное количество параметров для нормальной работы. Следовательно, через GUI-редактор уже никакой отладки сразу же не получается.

Впрочем, есть другой вариант: отладка через отдельное консольное приложение, через объект XslCompiledTransform. Если в конструкторе этого объекта указать параметр true, то это будет означать специальный отладочный режим. И тогда при нажатии F11 на строке вызова метода Transform, можно попасть в XSLT-файл, и типа всё будет "чики-поки".

Конечно, перед началом работы придется сдампить параметры преобразования и входной XML (dsQueryResponse), и потом подпихнуть их в XslCompiledTransform. Это немало работы, но она разовая, поэтому того стоит.

НО!

Есть еще ddwrt-функции и всякие ddwrt-атрибуты. Они подключаются через Extension Object. Класс, реализующий этот extension object, расположен в сборке Microsoft.SharePoint и помечен как internal. Как к нему доступиться? Разве что через Reflection..

Но есть еще одна неприятность: существует досадный баг в Visual Studio 2010 (даже с примененным SP1), когда пытаешься заниматься отладкой XSLT в .Net Framework 3.5. Он описан на Microsoft Connect: XSLT debugger doesn't work with in memory transformation.

Итог

В свете вышеописанного, я лично использую Visual Studio в простейшем варианте, практически как текстовый редактор... Хорошо еще, что сложных преобразований почти не бывает: 90% XSLT-кода копируется из стандартных файлов, собственного кода - очень немного. Необходимости в отладке пока практически не возникало.

Комментарии по этой заметке приветствуются. Я буду очень рад, если я не прав - сам разработчик, хорошие intellisense и debug очень ценю.