public override SPBasePermissions GetUserEffectivePermissions( string userName )
public bool DoesUserHavePermissions( string login, SPBasePermissions permissionMask )
Очередная мина на Шарепойнт-поле: при наличии в списке полей с типом, наследующим SPFieldLookup, метод items.GetDataTable() возвращает таблицу с неверными данными. Можно было бы и смириться, когда для полей, содержащий единственное значение выдаётся только его наименование без индекса, но для случая нескольких значений индексы и наименования перепутаны местами, для последнего значения индекс вовсе не выводится…
В итоге не придумалось ничего лучше, чем вызывать метод корректировки таблицы и для таких полей заменять корявое значение правильным - item[field.Title].ToString()…
После запуска домена с различными Шарепойнтами со всей прямотой встала задача оптимизировать усилия при разработке чего-либо под эти Шарепойнты. Как минимум, уменьшить число используемых инструментов, желательно, до одного-двух.
Кандидаты на эти инструменты – 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ами не поустраиваешь. Какая-то маскировка получается при помощи бантиков, песен и плясок.
Стояла задача с минимальными затратами (денег и умственных/физических усилий) организовать рабочую среду для разработки/тестирования решений для Шарепойнта. Собственно, среда эта давно имелась (PC c двухядерным процессором, ОЗУ 4 Гб, Windows 7 x64 Ultimate, SQL Server 2008 x64 Developer Edition, Visual Studio 2008, WSS 2007 x64) и вполне позволяла решать возникающие проблемы. Если не хватало WSS 2007, использовался Server 2003 x86 с OSS 2007 x86 в виртуальной машине с 1,5 Гб памяти. C приходом (или с наступлением на всех нас) новой версии Шарепойнта (его рекламная кампания была ничуть не слабее рекламы “Клинского”, хорошо бы, чтоб и рекламируемые продукты не были сильно похожи…) стало понятно, что имеющаяся конфигурация явно недостаточна.
Выходов было всего 2 – купить новый крутой компьютер или модернизирвать имеющийся и оптимизировать использование ресурсов. Ладно, с новым крутым пока подождём, поэтому по-простому куплено 8 Гб памяти (больше матплата не принимает) и воткнута флешка в режиме ReadyBoost – вот, собственно, и вся модернизация, которую возможно было сделать… Осталось заняться оптимизацией, при этом надо было сохранить имеющиеся возможности и параллельно добавить возможность работы с новой версией Шарепойнта.
Первым делом выяснилось, что имеющаяся в Windows 7 Virtual PC не подозревает о существовании 64-разрядных операционных систем (а Шарепойнт (SPF) 2010 – о 32-разрядных). Спасибо, компания Sun оставила в наследство народу замечательный продукт VirtualBox… Второй сюрпризик – SPF желает устанавливаться на отдельном сервере только со своей СУБД. WSS умел и с моими… (Правда, выяснилось, что если instance моего SQL Server назвать SHAREPOINT, то SPF своего сервера не устанавливает). Но в любом случае СУБД должна быть на этом же отдельном сервере. Это сколько же SQL Serverов будет в системе? И всем ресурсы подавай, всех обслуживай… Б-р-р.
А, собственно, кто мешает оставить всего один экземпляр, а остальные виртуальщики пускай пользуются. Мешала одна мелочь – в таких ситуациях требуется доменный пользователь. Что ж, пускай будет – имеется замечательное изобретение Windows Server Core Installation. Вот эта статья и эта разработка позволили достаточно легко организовать контроллер домена на базе Windows Server 2008 R2 в небольшой (память 456 Мб, диск ок. 4 Гб) VM на базе VirtualBox. Машинка запускается при старте основного компьютера из ком.строки, висит себе тихонько в уголочке и каши почти не просит (несколько первых часов работал оптимизатор .NET, потом успокоился):
Одного не удалось – поставить русскую версию сервера: не работает конфигуратор с codeplex из-за “перевода” названий различных системных объектов (собственно, даже PowerShell не запускается…). Ну и ладно, не сильно и хотелось…
В результате удалось заметно уменьшить требования к ресурсам для виртуальной машины с Шарепойнтом – и OSS 2007, и SPF 2010 вполне пристойно работают в машинах с памятью 1500 Мб (можно даже их одновременно запускать – неизвестно, правда, зачем…).
Выложил шаблон проекта по разработке на C# рабочего процесса для Шарепойнта. Включены средства работы с файлом конфигурации, с почтой (в т.ч. внешней типа gmail.com), средства установки, обновления и др.
Выложил шаблон проекта по разработке на C# веб-части для Шарепойнта. Включены средства локализации, установки, обновления и др.
Теперь – от поля SPFieldUser. Оказалось, что поведение поля существенно зависит от значения свойства AllowMultipleValues. Например, при значении true обращение к данным элемента списка с таким полем (item[fieldName]) приводит к получению объекта типа SPFieldUserValueCollection (как, собственно, и можно ожидать). Однако при значении AllowMultipleValues == false тип полученного объекта – вовсе не SPFieldUserValue, а String.
Похоже, кто-то где-то лишний раз ToString() присобачил…
Задался целью выяснить, можно ли обойтись одной Студией (желательно, 2010-й) для разработок (хотя бы, для модификаций имеющихся) – веб-частей, утилит, рабочих процессов и т.д. для текущей версии Sharepoint (до использования новой версии и разработок для неё когда ещё дело дойдёт…). Выяснилось, что новая Студия вполне спокойно относится к проектам, сделанным в Студии 2008 без использования VSeWss – их можно редактировать, компилировать и делать другие необходимые действия. Даже можно включить использование .NET 4.0, правда, исполняться полученный код не станет 
. При отладке нужно переключить версию отлаживаемого управляемого кода на 2.0 (по умолчанию используется 4.0, а они вместе отлаживаться не могут).
Для разработок же под Silverlight новая Студия намного удобней – в неё включили часть функциональности Expression и отпала необходимость прыгать между приложениями.
В общем, можно потихоньку переползать на Студию 2010 – по крайней мере, выглядит она “красивше”. Правда, новый Help 3.0 не нравится совсем: с запуском дополнительного web-сервера примириться ещё можно, но вот демонстрация материала в окне браузера раздражает очень сильно - вызывается не новый экземпляр браузера, а тот, который был запущен последним (правда, на собственное окно браузера почем-то внимания не обращается). [А я для удобства работы использую несколько рабочих столов и появление браузера с другого стола генерирует не очень печатные слова…]. Спишем пока что на бету.
После некоторого времени эксплуатации LiveID Authentication на сайте Российского сообщества Sharepoint начали выявляться недостатки этого способа.
Никакие программы, включая недавно выпущенную Windows Live Writer, не подозревают о существовании такого способа аутентификации. В результате на узлах/страницах невозможно использовать клиентские программы (а основном, это программы MS Office – Word, Excel), даже при включении в “админке” интеграции клиентов (в этом случае при помощи клиента забрать, например, документ из библиотеки на редактирование можно, но вернуть отредактированный документ – только через сохранение на локальном диске и загрузку оттуда в библиотеку). Невозможно также подключать списки к Outlook, редактировать узлы и страницы при помощи Sharepoint Designer и постить в блоги при помощи Live Writer.
Для обеспечения “пропавших” возможностей приходится делать доступным внешним пользователям вход на сайт, на котором настроен метод Windows-аутентификации (или работать в консоли сервера через RDP). 
Частично проблемы решаются (например, с Outlook и Sharepoint Designer) связыванием на IIS сервера сайта с Windows-аутентификацией с протоколом https.
Такая несогласованность продуктов не мешает, однако, важной функции рассылки оповещений. Для этого необходимо только правильно указать e-mail пользователя в анкете "Мои настройки LiveID". 
Всем почти хорошая штука LiveID authentication, но вот не желают с ней работать разные программы – ни документы из библиотеки не открываются, ни страницы при помощи Sharepoint Designer не поредактировать .
Дело с открытием документов решается включением “интеграции клиентов” на странице “Изменение параметров проверки подлинности “ в “Центре администрирования” (по умолчанию интеграция отключена с предупреждением типа “не все клиенты совместимы с проверкой на основе форм” и соответствующих пунктов в меню библиотек и страниц даже и не появляется). Но решается только наполовину – извлечь документ приложением можно можно, но положить после редактирования обратно приложение уже не может. Только через сохранение файла на локальном диске и загрузку его в библиотеку.
С редактированием же страниц при помощи SPD – не решается никак 
. Только через расширение приложения, которое имеет Windows Authentication.
После некоторых упражнений с Sharepoint (по-правде, в упражнения входил полный снос и повторная установка) обнаружился ещё один недостаток - пропала группа Authenticated Live Users (аналог группы NT AUTHORITY\authenticated users для Windows-аутентификации). Понятно, что она должна создаваться провайдером, но когда и как его подтолкнуть на этот подвиг, выяснить не удалось. А без такой группы настраивать разрешения для каждого пользователя – ужасная затея…
В итоге добавил процедуру формирования на каждом узле, где предполагается использование LiveID-аутентификации, группы с именем вида <имя узла> - Authenticated Live Users. При логине или изменении данных пользователи заносятся в эту группу.
Для облегчения жизни добавил скрипт _config.cmd с инструкцией по настройке в файле README_ru.txt.
Результаты можно скачать отсюда (установочный пакет) и отсюда (целиком проект с исходными текстами).
На codeplex Lawrence Liu размещено отличное решение по аутентификации на Sharepoint-сайтах с использованием Windows LiveID. Практически готовое к использованию решение и, если не обращать внимание на мелкие неудобства, его можно сразу и использовать.
Неудобства заключаются, во-первых, в неправильной работе редактора профиля LiveID, подключённого через CustomAction к меню пользователя (введённые данные не передаются в свойства пользователя узла и после закрытия редактора пользователь оказывается в корневом узле). Во-вторых, решение явно разработано без учёта использования на системах с неанглийской локализацией (все формы/меню на английском, а использовать узел с русской, например, локализацией в качестве служебного, просто не получается).
Для исправления недостатков проведён анализ предоставляемого кода и исправлены досадные ошибки (неверная привязка EventHandler’а, к примеру). Жёсткая привязка к английской локализации устранена заменой в двух операторах
SPListTemplate template = web.ListTemplates["Custom List"];
SPList list = sweb.Lists["User Information List"];
использования английских имён списков и шаблонов на вызовы методов, не зависящих от локализации. Кроме того, заменено использование list.Fields["Title"] на list.Fields[SPBuiltInFieldId.Title]. В результате решение стало работать и на узлах с русской локализацией.
Перенаправление на корневой узел исправлено добавлением адреса контекстного узла в описание CustomAction:
<UrlAction Url="~site/_layouts/liveinfo.aspx"/>
Средства для локализации решения обнаружились в блогах Mikhail Dikov, Maxime Bombardier и Jan Tielens. В aspx-формах и XML-описаниях текстовые константы заменены ссылками на строки в ресурсном файле LiveIDAuth.<culture>.resx. Нетривиальным, как выяснилось, является размещение ресурсов для использования в разных объектах. Так, для Feature-объектов, размещённых в папке \12\TEMPLATE\FEATURES\WindowsLiveAuthenticationSettings, ресурс должен находиться в папке \12\Resources (с использованием ссылок вида $Resources:LiveIDAuth,varName) или в папке 12\TEMPLATE\FEATURES\WindowsLiveAuthenticationSettings\Resources\ с именем Resources.<culture>.resx (с использованием ссылок вида $Resources:varName).
Для aspx-форм ресурс должен находиться в папке App_GlobalResources web-приложения.
В итоге в wsp-пакет пакет помещаются две копии ресурса с разными именами в разные папки (WindowsLiveAuthenticationSettings\Resources\Resources.resx и Config\Resources\LiveIDAuth.resx), а командный файл для установки дополнен командой
stsadm -o CopyAppBinContent,
копирующей ресурсы в папки App_GlobalResources веб-приложений.
Продолжение истории - здесь.
Результаты можно скачать отсюда (установочный пакет) и отсюда (целиком проект с исходными текстами).
Пытался на базе шаблона “блог” сделать узел для работы со статьями. Статьи от “записей” блога отличаются довольно мало, поэтому была надежда малыми силами (средствами WSS и, м.б., SPD) привести узел к нужному состоянию.
Добавил к списку "Записи"(Posts) поле "Автор статьи", изменил параметры веб-частей (поля запроса, группировка, сортировка) на страницах default.aspx и Post.aspx. Всё легко прошло, не удалось только сделать нормальную группировку по авторам (группировка-то получилась, но на страницу при этом мимо всяких веб-частей и зон лепится текст, до управления выводом которого простыми средствами добраться не удалось
). Пришлось ограничиться сортировкой по автору и названию, что, впрочем, и не так уж и плохо.
Засада ждала на странице Category.aspx, показывающей список с фильтром по категориям. Очень быстро выяснилось, что страница очень легко портится простым изменением состава полей запроса данных – после этого не показывается никаких результатов (или все сразу, в зависимости от настроек фильтра в запросе). При этом выяснилось, что инвалидность страницы – 1-й степени (работоспособность не восстанавливается никакими доступными средствами). Попутно обнаружилось, что стандартные средства связи веб-частей не используются, а сама фильтрация закопана где-то в коде.
В итоге ничего не оставалось кроме действий по учебнику – связал две веб-части стандартным способом и всё заработало.
Внешний вид, конечно, похуже… Но в итоге даже SPD не понадобился.
Вот примеры, которые можно использовать в вычисляемых полях.
1. Перевод первого символа в верхний регистр:
Строка:= xs="#this#",
String.IsNullOrEmpty(xs)?"":
xs=xs.Trim(), String.IsNullOrEmpty(xs)?"":
xs.Length==1?xs.ToUpper():
xs.Substring(0,1).ToUpper()+xs.Substring(1)
2. Проверка возраста на заданное число лет:
Строка:=xi=16,xs="~~Дата рождения~~",xs==""?"":
(new DateTime(
Int32.Parse(xs.Split('.')[2]),
Int32.Parse(xs.Split('.')[1]),
Int32.Parse(xs.Split('.')[0])) > DateTime.Today.AddYears(-xi))?
throwerr(String.Format("Возраст не может быть меньше {0} лет!",xi)):xs
/*годится для русской локализации */
3. Проверка даты на заданное "упреждение" - время от текщего момента до срока в дате:
Строка:=DateTime.Parse("#this#")>DateTime.Now.AddHours(24)?"#this#":
throwerr("Заявка не может быть оформлена позднее, чем за 24 часа до начала конференции")
Попытался использовать в форме стандартный контрол UserField. Нашлась неплохая статеечка на эту тему. Добавил код, как описано, плюс после некоторых поисков добавил ещё контекст (по умолчанию контрол работает на том же узле, что и связанный список), т.к. мне нужно работать со списками с других узлов. В общем, всё замечательно, только кнопка для выбора пользователей никакого эффекта не вызывает.
Кнопка проверки ввода работает, а эта - нет. При внимательном рассмотрении выяснилось, что не находится имя нужной функции, причём по причине длины имени!? В итоге получился вот такой работающий фрагмент кода 
:
((UserField)ValElem).ListId = DataItem.ListItems.List.ID;
((UserField)ValElem).ItemId = DataItem.ID;
((UserField)ValElem).ID = "uf_" + DataItem.Fields[name].Id.ToString("N");
//DataItem.Fields[name].Id даёт слишком длинное имя!!!
((UserField)ValElem).FieldName = this.Name;
((UserField)ValElem).ControlMode = SPControlMode.Edit;
SPContext ctx =
SPContext.GetContext(HttpContext.Current,
DataItem.ID, DataItem.ListItems.List.ID,
DataItem.ListItems.List.ParentWeb);
((UserField)ValElem).ItemContext = ctx;
((UserField)ValElem).RenderContext = ctx;
При создании полей в списках для имён, которые содержат цифры и не более 4-х букв (например, f1...fff1), первая буква преобразуется в конструкцию _x0_nn_... При этом безразлично, какова локаль текущего узла, есть ли вообще локализация... 
Совсем уж сюрприз неожиданный - постоянно операцию создания использую, а вот как-то не попалось...
Одному из пользователей в период наладки узла были предоставлены разрешения уровня "Полный доступ", после начала эксплуатации разрешения понижены до чтения, но ...не понизились. В итоге пользователю удалось удалить пару документов из библиотеки, при этом удаление делалось из SPD, мимо корзины. Вот такой вот сюрприз.
И опять от Sharepoint, на этот раз не сильно безобидный .
Есть у меня веб-часть, разработанная ещё пол WSS 2003 и переработанная под WSS 2007. Собственно, форма для ввода данных в списки со всякими наворотами типа проверок/валидаторов, вычисляемых полей и т.д. Имеется также режим для работы анонимных юзеров. Всё жило довольно мирно, готовились к передаче заказчику, но после того, как прикрутил в веб-части HIP-систему MS ASirra, начали выскакивать странные ошибки, ранее никогда не встречавшиеся. При внимательном рассмотрении выяснилось, что возникает ошибка в куске кода вроде вот этого
myData = myList.GetItemById(dataID);
после нескольких (5-6) постбеков с неправильными значениями в полях формы (юзеру выдаётся сообщение и предлагается заполнить поля правильно). При этом и myList != null, и dataID имеет нужное значение, а вылетает ошибка с сообщением о неверном значении dataID . Самое противное, что возникает ошибка только на "боевом" сервере у заказчика, на моих тестовых серверах - ни разу не получил, насмотревшись на кошек до мяуканья. Впору тронуться...
Решилось дело (вот уже два дня ошибки не возникает) заменой кода на вот такой
myData = myList.Items.GetItemById(dataID);
Вот, блин...
Потребовалось сохранить информацию для веб-части в библиотечном файле. Сделал текстовый файл с нужной информацией, сохранил в UTF-8, загрузил в библиотеку.
В веб-части информацию считываю примерно таким кодом:
encoding = Encoding.UTF8;
//читаем документ
byte[] chars = file.OpenBinary();
OutStr = encoding.GetString(chars);
В OutStr получаю первый символ - мусорный . Другое дело, что у меня там комбинации вида имя=значение, поэтому удалось выкрутиться за счёт регэкспа. А если б патроны везли?
