Размещение общего Sharepoint-кода
Часто бывает удобно выделить общий для нескольких проектов код в отдельную сборку и подключать её к проектам. Собственно, так же, как и чей-то чужой код в виде готовой сборки (с codeplex.com и подобных ресурсов).
При этом сразу же встаёт во весь рост проблема размещения такого общего кода. Очевидное, простое и поэтому неправильное решение, быстро приходящее в голову – поместить общие сборки в пакет каждого использующего их проекта – отметается после удаления одного из таких пакетов. Общие сборки тоже удаляются и остальные решения перестают работать. 
Попытки использовать имеющиеся под рукой установщики (Установщик Visual Studio 2010, Wix Toolset 3.5, InstallShield LE, установщик 7-zip и т.п.) оказались плачевными – либо пользоваться неудобно, либо не имеет нужной функциональности, либо не умеет обновлять ранее установленные сборки. Мрак какой-то… 
Лучшим вариантом оказался собранный вручную wsp-пакет в сопровождении двух cmd-файлов для установки и обновления.
Описание пакета в файле makecab.ddf:
.OPTION EXPLICIT ; Generate errors on variable typos
.Set CabinetNameTemplate=SP.Shared.Assemblies.wsp ; The name of the WSP file
.set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
.Set CompressionType=MSZIP
.Set Cabinet=on
.Set Compress=on
.Set DiskDirectory1=.
.Set CabinetFileCountThreshold=0
.Set FolderFileCountThreshold=0
.Set FolderSizeThreshold=0
.Set MaxCabinetSize=0
.Set MaxDiskFileCount=0
.Set MaxDiskSize=0
SharedAssembly.dll
SharedAssembly2.dll
...
manifest.xml
Файл manifest.xml:
<?xml version="1.0" encoding="utf-8"?> <Solution xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" SolutionId="guid..." xmlns="http://schemas.microsoft.com/sharepoint/"> <Assemblies> <Assembly Location="SharedAssembly.dll" DeploymentTarget="GlobalAssemblyCache"/> <Assembly Location="SharedAssembly2.dll" DeploymentTarget="GlobalAssemblyCache"/> </Assemblies> </Solution>
Собирается пакет командой makecab /v1 /f makecab.ddf, устанавливается файлом _install.cmd :
@set prompt=$g
@set spver=14
@set wsp=SP.Shared.Assemblies.wsp
@set admpgm="%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\%spver%\BIN\STSADM.EXE"
@time /t
%admpgm% -o addsolution -filename %wsp%
%admpgm% -o deploysolution -name %wsp% -allowCasPolicies -allowGacDeployment -immediate -force
@pause
%admpgm% -o execadmsvcjobs
Для обновления используем файл _upgrade.cmd :
@set prompt=$g
@set spver=14
@set wsp=SP.Shared.Assemblies.wsp
@time /t
@set admpgm="%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\%spver%\BIN\STSADM.EXE"
%admpgm% -o upgradesolution -name %wsp% -filename %wsp% -immediate -allowCasPolicies -allowGacDeployment
pause
%admpgm% -o execadmsvcjobs
Конечно, в соответствии с новомодными тенденциями можно применить PowerShell, но некоторым так привычней 
Sharepoint, виртуальный домен и инструменты
После запуска домена с различными Шарепойнтами со всей прямотой встала задача оптимизировать усилия при разработке чего-либо под эти Шарепойнты. Как минимум, уменьшить число используемых инструментов, желательно, до одного-двух.
Кандидаты на эти инструменты – Visual Studio и Sharepoint Designer. При помощи второго обычно делаю рабочие процессы “на скорую руку” (когда они несложные и надо быстро и в одном экземпляре) и разные эксперименты. Студия же служит для всего остального. Сюрпризы начались (или, скорее, наоборот, сюрприза не случилось…) уже с Дизайнера – для разных версий платформы необходимо использовать свои специальные версии инструмента. Понятно, когда требуется заставить покупать новую версию, но здесь-то продукт бесплатный… Или только до поры бесплатный? В общем, получается замусоривание дисков и Сети дистрибутивом нехилых размеров.
Со Студией ещё печальней – кроме использования разных её версий для разных версий Шарепойнта существует и необходимость установки Студии на том же компьютере, на котором установлен Шарепойнт. Только в такой комбинации существует возможность использовать (создавать, редактировать и отлаживать) типы проектов, относящиеся к Шарепойнту. Конечно, при необходимости можно приложить некоторые усилия (не очень, впрочем, маленькие) и обойти какие-то ограничения. Например, можно сделать собственные шаблоны проектов, которые не требуют установки Шарепойнта и Студии на одном компьютере (наподобие этого и этого). Однако отладку рабочего процесса только на сервере подобные способы никак не отменяют. Новые версии Шарепойнта и Студии для исправления такого положения добавляют крайне мало (нужно долго присматриваться, чтоб изменения заметить). Даже .NET 4.0 использовать нельзя…
В итоге, собственно, всё остаётся по-прежнему – на каждый сервер с установкой Шарепойнта ставим свою версию Студии (для WSS 2007 – VS 2008 ENU + VSeWSS v.1.3, для SPF 2010 – VS 2010 любой локализации).
Вообще, чем больше присматриваешься к новым версиям платформы и инструментов, тем меньше видишь в них что-либо по-настоящему новое и полезное, чего нельзя было бы сделать простым усовершенствованием WSS 2007 и Visual Studio 2008. При этом, конечно, сильно не пошумишь и всяких “Запусков” с Launchами не поустраиваешь. Какая-то маскировка получается при помощи бантиков, песен и плясок.
Шаблон проекта рабочего процесса
Выложил шаблон проекта по разработке на C# рабочего процесса для Шарепойнта. Включены средства работы с файлом конфигурации, с почтой (в т.ч. внешней типа gmail.com), средства установки, обновления и др.
Поведение метода Lists.GetListItems
Заинтересовали результаты поисков по теме, поднятой на GDN – получается, что метод какой-то совсем кривой и некоторые параметры обрабатывать не умеет. С учётом того, что в некоторых своих разработках метод использую, провёл небольшое исследование поведения метода Lists.GetListItems (обработка параметров viewFields и queryOptions).
Краткие результаты:
- Поведение метода зависит от типа ссылки на сервис (WCF или WS) и от типа программы, в которой метод используется (веб-часть/консольное приложение).
- В веб-части параметры обрабатываются правильно при использовании WS-ссылки.
- В консольном приложении – при использовании WCF-ссылки.
- Элемент IncludeMandatoryColumns не обрабатывается во всех вариантах.
При исследовании использовалась Visual Studio 2008. При использовании Студии 2010 RC(консольное приложение, переработанное с учётом сюрприза) WCF-ссылка не принимает во внимание все параметры, WS-ссылка правильно обрабатывает только viewFields.
Сюрприз-2010
На этот раз сюрприз преподнесла новейшая и крутейшая Visual Studio 2010 RC. Наблюдается сюрприз при генерации ссылки на сервис (Service Reference) для работы со списками Шарепойнта /_vti_bin/Lists.asmx. Результаты такой генерации заметно отличаются от таковых, выполненных Студией 2008 и описанных в SDK. Например, метод клиента GetListItems отличается как по типам параметров, так и по типу результата (сверху – описание из VS 2010, внизу – из VS 2008):
При этом результат не зависит от целевой версии .NET. Кроме того, при конвертации Студией 2010 проекта с правильным прокси типы тоже конвертируются и проект перестаёт собираться. В общем, при переходе на новую Студию скучно не будет…
8 comments