Т.о, сперва необходимо установить Extension VSeWSS 1.1.
Вариант деплоя до выхода экстеншна весьма подробно описан здесь http://msdn2.microsoft.com/en-us/library/cc297200.aspx .
Перейдем ко второму способу деплоя страниц: теперь не нужно копировать файлы в каталоги MOSS, а достаточно грамотно создать проект. В студии после установки Extension for SharePoint version 1.1 появляется вкладка WSP View (View-> Other Windows -> WSP View). Она отражает ту структуру, которая будет выложена в MOSS. Выявлено два способа деплоя aspx страниц при установленном экстеншне: а. в качестве Template’а ; б. в качестве Feature (Module)
Создаем Empty Sharepoint Project, добавляем к нему New Item -> Template
В дальнейшем, создавая папки в темплэйте, нужно учитывать, что они будут ложиться в каталог C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE . Т.е. если мы хотим положить aspx в Layouts, необходимо создать папку Layouts в темплэйте и положить туда aspx. Сравнивая оба варианта деплоя (а и б) нужно отметить, что когда в проект добавляется в качестве Module, т.е. aspx страница, которая кладется в модуль выступает в роли фичи (feature), тогда страница кладется в сборку MOSS, собственно как и code behind. В случае, когда aspx кладется в MOSS как Tempate, она просто физически кладется в папку Layouts.
Итак, мы создали Template. ascx файлы в SharePoint обычно хранятся в папке ControlTemplates. Для того чтобы отдеить наши контролы, которые лягут в ControlTemplates после деплоя имеет смысл создать отдельную папку для проекта, в нашем случае – это Sample, там и хранится Wizard.asсx. Code behind имеет смысл складывать в отдельную папку в проекте и все что хранится в нем будет в дальнейшем находится в сборке и браться оттуда. (в нашем примере это - Controls\Wizard.ascx.cs).
Добавление Template’а:
Затем добавляем Reference на:
Microsoft.Sharepoint и
Microsoft.Sharepoint.Security
Теперь добавляем aspx страницу в проект: как уже говорил, она должна добавляться как feature, т.е. в проект добавляется Module, далее в Module.xml указывается виртуальный путь к странице.
Добавление Feature:
В конечном счете сама страница физически ложится в папку Features, но подтягивается из самой сборки.
Содержимое Module.xml имеет следующий вид:
Параметр Url содержит виртуальный путь, по которому мы можем обратиться к странице, т.е. к Wiz.aspx после deploy solution можно получить доступ по пути http://win2003moss/SAMP/_sample/Wiz.aspx
Т.о. solution имеет следующий вид:
Содержимое проекта в том виде как он будет выложен в MOSS выглядит так:
При добавлении новой feature плагин к MSVC Extension for Shrepoint Services v 1.1 автоматически обновляет файлы управляющие деплоем проекта в MOSS, такие как manifest.xml и feature.xml, однако их можно отредактировать самим вручную, открыв из WSP View.
Примечание:
При деплое могут вознкнуть ошибки, такие как: подобная feature уже существует (SAMP), в этом случае имеет смысл в Pre-build event command line добавить следующее:
echo Deactivating feature PSStuffSchedule ...
set SPAdminTool=%CommonProgramFiles%\Microsoft Shared\web server
extensions\12\BIN\stsadm.exe
set TargetUrl=http://win2003moss
"%SPAdminTool%" -o deactivatefeature -name SAMP -url %TargetUrl%
echo Uninstalling feature PSStuffSchedule ...
"%SPAdminTool%" -o uninstallfeature -name SAMP –force
Тем самым происходит деактивация feature и ее удаление. По идее при деплое проекта это должно происходить автоматически, но мне приходилось не раз сталкиваться с подобной проблемой. (альтернативой Pre-build event command line может быть запуск bat-файла с этим же содержимым перед деплоем проекта).
Если возникают другие ошибки на подобии «Закрыт доступ к папке» и пр. – необходимо перегружать сервис World Wide Web Publishing, такова уж специфика MOSS.
