Sharepoint и Windows Store - 4

Как, в общем-то, и ожидалось, прислали из магазина отлуп:

Нам не удалось сертифицировать SPExplorer для Магазина Windows, так как мы обнаружили проблему. Чтобы узнать, в чем дело, просмотрите отчет о сертификации с помощью инфопанели

Естественно, в этой “панели” рассказывается про использование “неправильного” API.

Последняя возможность соорудить, всё же, программку для работы с Sharepoint в Windows 8 – использование для получения данных REST-интерфейса (сервиса).

В магазине обнаруживается приложение “SharePoint REST Toolkit”, которое, правда, не соединяется с сервером SP 2010, но содержимое узлов SP 2013 показывает исправно. Написано приложение на jscript. На codeplex можно найти пример, как можно написать похожее приложение на CSharp, которое нацелено на работу с Sharepoint Online (в приложении используется лишь тот способ аутентификации, который нужен на SPOnline).

Собственно, доработать аутентификацию (учесть FBA и WinAuth) больших научных подвигов не требует – и вот, приложение соединяется с любыми (по крайней мере, доступными мне) серверами SP2010 и SP2013 и получает ответ на запрос к сервису /_vti_bin/ListData.svc (данные SP-списков). Ура!

Правда, довольно скоро выясняется, что в случае SP 2010 все радости этим и ограничиваются. В SP2013 способы REST-работы изменены радикально – используется сервис /_vti_bin/client.svc (/_api), который есть и в SP2010, но используется там только через CSOM. Собственно, тут и конец всей истории – программка для просмотра только списков мне лично не нужна (трудов – море, а толку – чуть), а для SP2013 написать полноценный SP-браузер, может, и можно (надеюсь, API позволяет), но для этого надо - ни больше, ни меньше – написать для REST-вызовов обёртку наподобие CSOM. Думаю, в следующей версии SharePoint такая обёртка появится. Ну, или изменятся отношения между подразделениями, занимающимися Sharepoint и “безопасностью” WinRT и мы увидим версию CSOM, пригодную для использования в “магазинных” программах для планшетов и телефонов.

Если, конечно, вся эта затея с WP-телефонами и Windows-планшетами до тех пор не помрёт тихой смертью…

Все исходники, из которых можно собрать действующие приложения, повешу здесь – вдруг, кому-то захочется повозиться с обёрткой...

Sharepoint и Windows Store - 3

Буквально через три дня после предыдущего поста на эту животрепещущую тему  обнаружилась прекрасная наводка от Mark Racley на решение проблемы использования CSOM-библиотек для подключения к удалённому серверу Sharepoint. Действительно, Windows Runtime Component с подключёнными SP-сборками выполняет подключение к ферме, запрашивает и отдаёт данные:

 

Сборки использовались от Sharepoint 2013, 2010-е использовать невозможно из-за конфликта версий .NET (очень уж древней оказалась версия, использованная в SP-2010). Сам компонент стандартным образом подключается в проект для Windows Store:

Код для доступа к удалённым SP-узлам тот же, что в утилите SpfExplorer. Были некоторые сомнения относительно передачи и использования в CSOMWinRTComponent делегатов из SPExplorerCSOM Win8 (CS) (всё же, версии framework’ов, вроде бы, разные). Но всё обошлось, делегаты передаются и узлы деревьев благополучно рисуют.

Следующее возникшее сомнение – при выборе средств построения пользовательского интерфейса. Вариантов, собственно, два – C# + XAML или HTML + JS

При использовании C# нужно бороться с ужасной хренью в виде XAML с его жуткой моделью элементов интерфейса. "Стандарты" в виде студийных проектов предполагают использование MVVM с биндингом данных. В случае же "деревянных" данных, как в SP, слабо представляется, что и как там надо привязывать. Да и дерева там, собственно, нет, все советуют реализовывать его самостоятельно…

При использовании JS есть надежда, что борьбу с ним можно ослабить при использовании TypeScript, а строить дерево на HTML когда-то все умели… Правда, при внимательном рассмотрении выясняется, что и на HTML программы предлагается делать так же, как на XAML (через специфические атрибуты). Может, конечно, и "обычный" HTML пойдёт, но экспериментировать с этим как-то не сильно хочется…

В итоге, с учётом всех мнений, выбран вариант C# + XAML, дерево для вывода данных – собственного изготовления. После долгих кровопролитных сражений с XAML (о ходе и результатах сражений как-нибудь попозже в отдельных постах) получилась программка, пригодная для эксплуатации на планшете с использованием пальцетыканья. Нормально подключается к серверам SP-2010 и SP-2013 и выводит данные в виде дерева:

Следующая, совсем отдельная задача – размещение программки в магазине Windows 8 (а другого официального способа распространения и нет, вроде бы). Здесь вовсе уж цирк – проверка в Студии на соответствие требованиям не проходит:

Собственно, уговорить разработчиков Sharepoint исправить ситуацию с использованием “не того” API (а список неправильных вызовов довольно длинный) я не могу, остаётся только удивляться, почему это некоторый вызов “не поддерживается для данного типа приложений”, если в программке он наверняка используется и вполне себе работает… Щас отправлю пакет, поглядим…

Очередной сюрприз, от ИЕ10

Пожаловался юзер, что после недавних (март 2013) ИЕ10 в Win7 неправильно показывает пикер в списках Шарепойнтах (не отображается скроллер и кнопки)

У меня нет Win7, но вот как оно выглядит в ИЕ10 в консоли сервера Win2008R2 (аналог Win7 в некотором смысле):

А так - в браузере ИЕ10 на моей десктопной Win8:

А так - в моём же браузере Iron (аналог Хрома):

Браузер Maxthon 4 с переключением движков (ИЕшный и WebKit) в обоих движках показывает форму правильно. Уж не знаю, как они используют ИЕшный движок, но если как-то вшивают, а не обращаются к актуальной версии, то это означает, что произошло вредительство в последнем обновлении клиентских ОС (браузер выпущен до обновлений).

Мораль - очередное спасибо благодетелям за удачные обновления “передовых” клиентских систем…

Не впервой…

WinFoms or WPF

Есть у меня утилита для работы с локальными или удалёнными серверами Шарепойнт, которую переделываю/усовершенствую уже много лет. Решил на этот раз "усовершенствовать" интерфейс программки.

Собственно, в нынешнем интерфейсе на WinForms практически всё устраивает - две панели, дерево, менюшки - контекстные и общие - особенно ничего и не нужно больше - программка-то для админского использования.

Правда, после рефакторинга прямоугольники для отметки узлов стали почему-то изображаться пунктиром:

Почему - понять не удалось, да и не очень-то хотелось…

В WPF, конечно, изобразительные возможности покруче, поэтому решил попробовать. Студию открыл, проект сделал, стал пытаться воспроизвести нынешний интерфейс…

Практически удалось - и две панели с изменением размеров, и деревья в них, и выращивать деревья можно программно… Но возни оказалось побольше, чем в WinForms: элементы во второй (правой) панели (ColumnDefinition в Grid) базируются относительно окна и им приходится приписывать отрицательный Margin. Передвижение GridSplitter требует неслабой обработки - все эти смещения пересчитывать… Может, я для панелей неправильный способ реализации выбрал, но ничего лучше Студия почему-то не предложила, а копаться в гуглях ради такой мелочи (при постройке WinFoms-интерфейса точно нигде не копался) - не стану, это должно быть очевидным…

Собственно, на этом с "новым" интерфейсом и закончил - возня очевидна и в больших количествах, а выгод не видно совсем.

Sharepoint и Windows Store - 2

Как-то смешно выглядит невозможность сделать приложение для WinRT, работающее с Шарепойнтом – прямо из серии “такого не может быть…”. Должна же быть какая-то возможность…
При рассматривании SDK попадается на глаза “ECMAScript Class Library” – библиотека для работы с CSOM на языке ECMAScript (JavaScript, JScript). Отлично, щас попользуемся…
Раскопки на MSDN показывают, что программу для WinRT тоже можно соорудить на JavaScript (+ HTML5, CSS 3 etc). Совсем здорово, начинаем пробовать практически, тем более, даже книжка бесплатная на эту тему существует.
Делаем по книжке, примеры работают, начинаем смотреть, как оно вообще устроено, и …приходим в ужас: написать руками  код на JScript длиннее 50 строк и сложнее вызова alert(“Hello!”) можно только после двух месяцев тренировок…
Выходим из прострации, обращаемся к Гуглю и выясняем, что для облегчения жизни существует язык TypeScript – масштабируемый, с типизацией, поддерживается MS. Ура, мы спасены! Тем более, к языку приложено довольно приличное приложение для WinRT. Ну, немного кривоватое, но к мелочам зачем же цепляться…
Делаем новое приложение, добавляем туда js-скрипты из папок Шарепойнта, в файле script.ts пишем долгожданное
clientContext = SP.ClientContext.get_current();
На этом эксперименты с TypeScript заканчиваем: выясняется, что JS-библиотеки языком TypeScript не воспринимаются, а библиотек с определениями типов (*.d.ts-файлов) никто пока не сделал и в общее пользование не предоставил.
При попытках продолжить эксперименты уже на JavaScript выясняем, что “ECMAScript Class Library” вовсе не предназначена для работы вне страниц, полученных с сервера Sharepoint: в отличие от C#-библиотеки, js-объект SP.ClientContext не имеет средств для логина пользователя и не позволяет коннектиться к произвольному УРЛ. И это не только в версии 2010, но и в новейшей 2013-й… Можно, наверное, эти библиотеки дополнить соответствующим функционалом – но это уже другая песня.
Остаётся, конечно, ещё одна возможность – REST-сервисы. Но что-то в 2010-й версии Шарепойнта лично у меня с ними отношения не сложились, а 2013-й Sharepoint пока не сильно интересует…
В общем, подождём развития событий. А WinRT пока поживёт без Шарепойнта (особенно, в версии для ARM).

Sharepoint и Windows Store

Прочитал книжку Сергея Пугачёва с соавторами и вдохновился соорудить метрошную программку для просмотра Шарепойнт-сайтов. С использованием клиентской модели, которую немного освоил…

Естественно, облом случился - Шарепойнт-то на .NET 3.5, а проект строится на 5.0.5 и никаких переключений версий не предполагает.

По идее, надо пробовать сборки от 2013-го Шарепойнта… Как они, любопытно, будут работать с 2010-м Шарепойнтом?  В принципе, должно быть без разницы…

C 2013-ми сборками - тоже облом.

В тексте программки написал:

 using Microsoft.SharePoint.Client;

…

private Web web = null;

При компиляции получаю сообщение:

Ошибка - Не удаётся найти тип System.ComponentModel.MarshalByValueComponent в модуле System.dll.       

При расследовании выясняется, что сборка System.dll, подключённая к проекту (подключение называется ".NET for Windows Store apps"), какая-то урезанная и помянутого типа там, и вправду, нет, а подключить нормальную сборку не дают - её, дескать, и без вас подключили… И удалить то, что подключено, не предполагается…

Похоже на то, что программы для работы с пупер-флагманским продуктом Sharepoint 2013 в Windows Store не сильно-то и требуются…

Вот про салаты или коктейли - это да…

Кривые списки и модели данных

При доработке утилиты SpfExplorer столкнулся со списком, при обращении к Title которого вылетает исключение с диковинным сообщением:

"Недопустимое имя файла.

Нельзя использовать указанное имя файла. Это имя существующего файла или папки, либо у вас отсутствует разрешение на доступ к этому файлу."

Как такое чудо сотворили, не признаются…

 

В программке с использованием серверной модели (OM) для отрисовки узлов со списками использовался Linq-код:

 

 

Этот код при наличии помянутого чудо-списка падал без генерации узлов, ещё на выборке элементов…

 

Для обхода пришлось вернуться к "старому доброму" циклу:

 

 

с обработкой ошибок при доступе к данным каждого списка…

 

При использовании клиентской модели (CSOM) для получения коллекции списков используем код

 

 

Код падает при наличии чудо-списка, коллекция списков оказывается неинициализированной.

 

Попытка эмуляции (размер коллекции-то неизвестен…) второй возможности из OM тоже не удаётся:

 

 

Этот код падает до запроса данных, ещё на строке var list = lists[ii];

 

Остаётся только посоветовать обратиться к администратору для исправления ошибок…

 

Конечно, есть ещё возможность попытаться обращаться через веб-сервисы (а CSOM разве что-то другое делает?), сильно будет надо - сделаем…

Бойся Try/Catch…

Вот, только что наткнулся: конструкция try/catch в PS v.2 (которая с Шарепойнтом 2010 только и работает) срабатывает в зависимости от типа ошибки - некоторые вовсе не перехватывает.

Пример: конструкция try{2/0}catch{"низя!"} вываливает сообщение в консоль:

PS v.3 исполняет как надо:

Выясняется, правда, что если делить не на нуль, а на переменную, содержащую нуль, то этот примерчик работает и во второй версии:

С другой стороны, наткнулся-то я на такое смешное поведение Catch в реальном скрипте при попытке в блоке Try записать данные в системный лог:

Write-EventLog -LogName $eventLogName -Source $eventLogSourceName ...

Если переменная $eventLogSourceName пустая, то в Catch ловится ошибка с сообщением "Cannot validate argument on parameter 'Source'. The argument is null or empty."

А если там неверное значение, то исключение не ловится и сообщение пишется в консоль:

Как с этим бороться? Не перечислять же все известные в природе исключения? Тем более, что некоторые всё равно не перехватываются…

Нашёлся способ в виде конструкции Trap - нечто наподобие On Error в бейсике.

Ловит все ошибки, но особо с действиями над этими ошибками не развернёшься. В файл на диске ошибки записать можно (чего я, собственно, и добивался), а вот собрать тексты разных ошибок, чтобы потом их разом записать в лог, как обычно в CS делаю - вигвам.

Вот примерчик:

$err="Error: "

trap {  $err += $_
$err
Out-File -FilePath "errors.log" -Encoding "utf8" -Append -InputObject $_.Exception.Message
continue }

$dvdr = 0
1/$dvdr
NonsenseString  2+3
$err #здесь та же строка "Error: " :(

Здесь выполняются все действия, а сообщения об ошибках выводятся в файл:

Попытка деления на нуль.
Имя "NonsenseString" не распознано как имя командлета, функции, файла скрипта или выполняемой программы.

Не фонтан, конечно, но, всё же, лучше, чем просто пропадающее сообщение (пускай даже код после "кривых" Catch иногда и выполняется нормально)…

Троянский конь…

С декабрьским пакетом обновлений установился Windows Management Framework 3.0 for Windows Server. Спасибо, конечно, но можно было бы и предупредить, что при попытке воспользоваться “Командной консолью Sharepoint 2010” получим сообщение “The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.”

Конечно, новый PS работает под .NET 4.0, а Sharepoint – под 3.5…

Хорошо хоть, что решается проблемка простым удалением этого “обновления”. Но опять перезагрузка… А на сервере люди…

SPFExplorer 2010 с клиентской моделью

Модифицировал старую свою утилиту для работы с объектами Sharepoint 2010 на предмет работы не только в консоли сервера, но и на удалённом компьютере. Собственно, по работе понадобилось сравнить структуру и свойства разных ферм, что удобнее (привык как-то уже…) делать в соседних окошках в “деревянном” виде.
Для обеспечения удалённой работы с Шарепойнтом использовал клиентскую объектную модель (сборки Microsoft.SharePoint.Client и Microsoft.SharePoint.Client.Runtime), функциональность утилиты относительно “удалённых” объектов ограничил только просмотром структуры и свойств, т.к. выполнение каких-либо модификаций требует дополнительных исследований, затраты на которые вряд ли когда окупятся (лично мне хватает быстрого перехода к странице, где можно сделать модификацию стандартным образом). При большой нужде можно написать и соответствующие плагины, интерфейс открыт.
Описание и полный набор файлов утилиты (включая “опасные” плагины удаления и копирования) выложил на гугле-странице (сайт на officelive.com погиб, потому как благодетелю стало жалко ранее обещанных пожизненно бесплатных ресурсов, которые оказались даже лучше, чем новейший Office365).
Теперь подождём до переоснащения оборудования новыми Осями (Windows 8 и Windows Server 2012) и Студией и можно начинать адаптацию утилиты к использованию с новым Шарепойнтом, несмотря на многочисленные восторженные всхлипы по его поводу. Всё равно же когда-то он станет использоваться…

Technorati Теги: Sharepoint 2010

Групповой сюрприз

Потребовалось ограничить доступ к списку. Всё, вроде бы, просто – разрешения списка –> прекратить наследование –> удалить разрешения для ненужных групп и пользователей. Но это же Шарепойнт – пропадает ссылка на список в левой панели быстрого запуска. Будь ты хоть кто, с какими угодно разрешениями – хоть бы админ сайта и изготовитель этого списка…

Исследования показывают, что такой эффект даёт изменение разрешений для встроенной группы “участники узла” – их нельзя удалять, можно уменьшить до “Только просмотр”. 

Ну, спасибо…

Technorati Теги: Sharepoint

Сюрприз от DocumentSet - 3

Вполне возможно, что этот сюрприз и не только к набору документов относится, но нашёл я его именно здесь. Проявляется сюрприз в виде разных наборов “заметок” в веб-части “Доска заметок”, установленной на странице набора документов, в зависимости от активности на сайте фичи “Инфраструктура публикации SharePoint Server”.

Если посмотреть на “своём сайте” список заметок, то там они имеются все, при рассматривании ссылок на объекты комментирования видно, что в УРЛ при неактивной фиче вставлен лишний слеш после имени сервера. Вот и вся причина сюрприза…

Если эксперименты продолжить и формировать заметки не через веб-часть, а через кнопку вверху справа, то сюрприз не наблюдается… Получается, это веб-часть так шутит… Ура индийским братьям!

Technorati Теги: Шарепойнт

Хе!

Юбилейный пост на форуме

 

Не всё так просто…

Потребовалось сделать переустановку Sharepoint Server 2010 – требовалось заменить дистрибутив на Server 2010 for Internet Sites и поменять язык с английского на русский. Казалось бы, пустяковая операция – один дистрибутив снести, другой поставить. Ага, так бы, может, и было два года назад, когда система только вышла, но сейчас навыпущено много изменений и согласовать их между собой – та ещё задача.

На заменяемой системе был установлен sp1 и декабрьский (2011 г.) CU, к моменту переустановки уже был выпущен февральский (2012 г.) CU, и было бы глупым возвращаться к декабрьскому пакету. После установки дистрибутива “Server 2010 for Internet Sites”, сервиспака (вместе с английским языковым пакетом), февральского пакета обновлений и подключения к существующей Sharepoint-ферме оказалось, что “Центр администрирования” формируется с английским интерфейсом, а базы данных не обновляются “Мастером настройки”. С обновлением баз с данными (WSS_Content…) справиться удалось при помощи PowerShell, а вот базы разных служб (особенно упорствовали базы службы поиска) поддались не все. И оставить их в состоянии “как есть” было нельзя – из-за них не выполняется бекап фермы. Вопрос с этими базами “решился” просто – пересозданием служб вместе с базами. А у кого там какие-то данные есть, им как быть?

В итоге в системном логе остались два сообщения об ошибках (одно из них даже Critical):

1. Исключение при обновлении адресов для подключенного приложения {e65aeea2-865c-49d8-a394-2ecdeb613811_4c8b4429-9205-4f6f-b3fb-0b4cd99de394}.
2. Сбой при попытке синхронизировать веб-приложение 55e17656-0ee7-45ba-87ab-e971ab00ed24; база данных содержимого 23812d7b-3a7c-476c-bf6a-07c1bfec026f

Сообщения представлялись совершенно загадочными и никаких сбоев в работе фермы при этом не наблюдалось, а английский интерфейс не менялся при пересоздании “Центра управления” при помощи “Мастера”. Осталось последнее средство – пересоздание фермы. В новой ферме добавил веб-приложение, к которому присоединил базу данных контента – всё стало с нужным интерфейсом, все узлы/подузлы/списки/библиотеки оказались на месте.

Нда…

Technorati Теги: Sharepoint

Сюрпризик от локализации.

Делал программку генерации списков на узле Sharepoint 2010. В предыдущем проекте такие же действия (создание списка, добавление нужных полей, присвоение русских значений title’ов и т.п.) делал при активации features на узле. Теперь же удобнее было выполнять подобные действия в консольной утилите. Собственно, всё и выполняется без всяких изменений в коде, однако результат получается совсем неожиданным: при просмотре перечня списков в браузере (“весь контент сайта”) видны английские названия, с которыми они создавались методом web.Lists.Add(<EngName>,…), а при просмотре через объектную модель, напр., при помощи PowerShell, видны русские названия, которые присваивались через свойство newList.Title = <RuTitle>; Такая же ситуация с полями списков.
Загадка разрешилась просто – ОС, в которой запускалась утилита – английская, а локализация сайта, на котором генерились списки – русская. Для согласования локалей достаточно в начале программки выполнить присваивание Thread.CurrentThread.CurrentUICulture = web.UICulture;
Собственно, к вопросу о пользе чтения документации.

Technorati Теги: Sharepoint 2010

Оказывается - 9

Выяснилось, к удивлению и сожалению, что методы класса SPWeb

public override SPBasePermissions GetUserEffectivePermissions(
    string userName
)

и

public bool DoesUserHavePermissions(
    string login,
    SPBasePermissions permissionMask
)

совершенно не учитывают разрешений, получаемых пользователем через членство в группах AD, которым назначены разрешения на узле.

Функция “Проверить разрешения” на странице /_layouts/user.aspx таких разрешений не учитывает тоже.

Technorati Tags: Sharepoint

Раскопки SharePoint продолжаются!

SharePoint, ASP.NET, C# и не только: Чем плох CAML в SharePoint?: В последнее время, я всё чаще и чаще пишу обертки для CAML. Началось всё, кстати, с моего любимого SharePoint 2010 Fluent Ribbon API , благо...

Оказывается - 8

Нечаянно выяснилось, что определения свойства веб-части в виде

отличаются радикально: первый определяет свойство только для чтения, второй вызывает вывод сообщения о неправильном формате свойства и невозможности десериализации свойств веб-части.

И никакой отладчик не позволяет найти причину сообщения

XSLT-сюрприз

 

Описание – здесь.

В связи с участившимися покушениями на ГДН перенесу текст сюда:

Непонятное наблюдается при отображении дат через настроенную XsltListViewWebPart
Дата 01.02.2010 16:26, т.е. 1-е февраля 2010г., отображается почему-то как 2 января 2010 г.
при этом дата 24.11.2009 10:24 - отображается правильно 24 ноября 2009 г.

вот код:
<xsl:value-of select="ddwrt:FormatDate(string($created) ,1049 ,1)" /> |
<xsl:value-of select="$created" /> |
<xsl:value-of select="ddwrt:FormatDate(string($created) ,1049 , 3)" />
вот, что на выходе:
02.01.2010 | 01.02.2010 16:26 | 2 января 2010 г.
24.11.2009 | 24.11.2009 10:24 | 24 ноября 2009 г.

Портал русский, поле - системное Created, в БД хранится в поле tp_Created:
2010-02-01 13:26:24.000
2009-11-24 07:24:12.000

ошибка связана с реализацией XSLT DateFormat функции в Sharepoint 2010. Чтобы исправить данный bug придется написать свой xsl template, см. ниже:

Bug With SharePoint 2010 XSLT DateFormat Function

XsltListViewWebPart Date Format using DDWRT

Technorati Tags: Sharepoint 2010, Глюкалово

Снова сюрприз. Многострочный.

При наличии в списке многострочных полей их отображение в стандартных веб-частях зависит от установленного вида этого поля в момент образования элемента списка. В поля списка (“Название” – однострочное текстовое поле, “mlfield” – многострочное) введены одинаковые строковые значения), первые два элемента списка формировались, когда тип поля mlfield был установлен в “Обычный текст” и “Форматированный текст” соответственно, третий – “Расширенный форматированный текст”.

Видно, что содержимое “многострочного” поля отображается с вертикальным смещением.

В то же время подобного фокуса не наблюдается в “старом” интерфейсе, остающемся после конвертации узлов из версии 2007:

Technorati Tags: Sharepoint