, в основном, на одном ядре (хотя и на разных) – даже иногда сообщения выскакивают о достижении 75 градусов на процессоре…public override SPBasePermissions GetUserEffectivePermissions( string userName )
public bool DoesUserHavePermissions( string login, SPBasePermissions permissionMask )
При работе со списками Шарепойнт обычной практикой, надеюсь, является использование CAML-запросов (свойство SPQuery.Query), которые заметно ускоряют получение данных. Другой возможностью уменьшить объём перерабатываемых данных является ограничение на перечень полей данных (свойства SPQuery.ViewFields и SPQuery.ViewFieldsOnly). Правильное использование помянутых свойств способно заметно улучшить характеристики по быстродействию и потреблению ресурсов.
Проблемы могут возникнуть при попытке использовать характеристики типов содержимого (ContenttType) в списках с поддержкой разных типов. При “чрезмерном” ограничении перечня полей списка можно получить в свойстве SPListitem.ContentType значение null, а в свойстве SPListitem.ContentTypeId совершенно “левое” значение… Для предотвращения подобных проблем следует к списку запрашиваемых полей добавить поле с внутренним именем “ContentTypeId”. При обработке результатов запроса тип содержимого элемента item можно определить кодом наподобие item.ParentList.ContentTypes[item.ContentTypeId].
Нечаянно выяснилось, что определения свойства веб-части в виде
отличаются радикально: первый определяет свойство только для чтения, второй вызывает вывод сообщения о неправильном формате свойства и невозможности десериализации свойств веб-части. 
И никакой отладчик не позволяет найти причину сообщения 
Описание – здесь.
В связи с участившимися покушениями на ГДН перенесу текст сюда:
Непонятное наблюдается при отображении дат через настроенную 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
Лихой плагин для ФАРа – это раскрашенный текст из фаровского редактора, перенесённый с его помощью:
public partial class XmListViewer : Microsoft.SharePoint.WebPartPages.WebPart {
/// <summary>
/// Путь к папке с файлом локализации
/// </summary>
string localsFolderPath = "";
/// <summary>
/// Прочитать locals.xml из папки ресурсов
/// </summary>
/// <remarks>Вызывается в OnInit()</remarks>
void Localize() {
localsFolderPath =
this.Context.Server.MapPath(
this.ClassResourcePath.Replace(SPContext.Current.Web.Url, ""));
this.Description = GetLocalizedString("description", "Working with XML-files and Sharepoint-lists");
}
При наличии в списке многострочных полей их отображение в стандартных веб-частях зависит от установленного вида этого поля в момент образования элемента списка. В поля списка (“Название” – однострочное текстовое поле, “mlfield” – многострочное) введены одинаковые строковые значения), первые два элемента списка формировались, когда тип поля mlfield был установлен в “Обычный текст” и “Форматированный текст” соответственно, третий – “Расширенный форматированный текст”.
Видно, что содержимое “многострочного” поля отображается с вертикальным смещением.
В то же время подобного фокуса не наблюдается в “старом” интерфейсе, остающемся после конвертации узлов из версии 2007:
Попытка соорудить способ параллельного выполнения кода по запросу данных из нескольких списков Sharepoint. Собственно, способ предполагалось использовать в веб-части, написанной на C#, выбор F# для реализации способа обусловлен наличием в нём средств для параллельного выполнения асинхронных операций (класс Async).
Упрощённая тестовая программка на C#:
Параллельный исполнятель на F#:
Однако фокус не удался: из всех списков, переданных в ParallelExecutor, данные добываются только из одного (иногда из первого, иногда из последнего). На всех остальных операция list.Items.GetDataTable() падает с диковинным сообщением <nativehr>0x80010102</nativehr><nativestack></nativestack> 
Похоже, разработчики Sharepoint не сумели подружиться не только с .NET 4.0, но и с F#-классом Async…
На базе версии XmListViewer 2007 сделал веб-часть XmListViewer 2010 для работы на фермах Sharepoint 2010. Собственно, практически только рефакторинг кода да использование некоторых фич SPF 2010 и понравившихся функциональных приёмчиков. Расширил функциональность light-версии – теперь можно получать данные одновременно из двух списков.
Функциональное нововведение одно - консолидация данных списков на узлах Шарепойнт на манер стандартной веб-части “Запрос контента” с некоторыми расширениями (или уходами в сторону?).
В процессе реализации преисполнился благодарностей (надеюсь, от икоты никто не умер…) разработчикам Sharepoint, исключившим из него возможность параллельного исполнения кода (в WSS 2007 такая возможность была с использованием ParallelExtensions-CTP, теперь она включена в .NET 4.0, с которым разработчики Sharepoint подружиться не сумели 
) – при консолидации списков набирается много, а запрос данных дорог и прямо напрашивается на параллельное исполнение…
Ко всем прочим удовольствиям добавилась новелла с нерабочим редактором страниц на officelive.com (может, и починят, может, и навсегда…). Поэтому отдельную страничку сделать пока не удаётся, ссылки на закачку здесь – Light-версия веб-части, инструкция по установке и настройке.
Добавил:
Фокус с отдельной страничкой удался - http://dyakov.design.officelive.com/xmliv2010.aspx. Там кроме прочего все необходимые ссылки.
Ширятся наши ряды – появился ещё один собиратель всякой бяки от Шарепойнта. 
Нельзя не поприветствовать!
Соберу до кучи его результаты здесь:
Думаю, со временем список продолжится… 
Часто бывает удобно выделить общий для нескольких проектов код в отдельную сборку и подключать её к проектам. Собственно, так же, как и чей-то чужой код в виде готовой сборки (с 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, но некоторым так привычней 
Дал себе задание (довольно давно уже) при появлении возможностей заняться изучением новомодного языка. С первого взгляда - всё есть: поддержка Студии (хоть 2008, хоть 2010), полно литературы (правда, вся английская, но так даже и лучше).
Переносить из книжек всякие примеры - скучно, поэтому решил начать делать одновременно и второе обещанное себе дело - перенести имеющуюся у меня утилиту для работы с Шарепойнтом в ФАР (с использованием техники .NET-плагинов).
Борьба продолжалась почти два световых дня и осложнялась скудной документацией по Far.Net (та самая поддержка .NET-плагинов, к появлению которой когда-то имел достаточнно близкое отношение). Дело, конечно, естественное (человек разрабатывает систему практически в одиночку и добровольно), обижаться не на что...
Удивительней положение с изучаемым языком: синтаксис у него оказался достаточно заковыристым, чтоб постоянно спотыкаться, поддержка редактором Студии не в пример слабее таковой для C#. Показывать классы и прочие объекты в FS-сборке студия отказывается (Рефлектор, однако, показывает картинку, весьма похожую на правду). Подписывать сборку проект FS-библиотеки даже и не предлагает, а я как-то привык за 6 лет занятий разработкой под Шарепойнт любой проект начинать с настройки размещения, которого без строгого имени не бывает...
Добила необходимость ручного регулирования порядка размещения файлов в проекте и объектов (функций, классов и т.д.) в файле 
Ладно, кое-какой опыт получился, попозже можно будет и вернуться...
P.S. Совсем уж остановил вот такой фокус…
Потребовалось в проекте выгружать на диск документы из библиотек Шарепойнт. На первый взгляд – ничего особенного: запрашиваем у пользователя путь к папке сохранения на манер модуля резервного копирования в Центре Управления, подключаем пространство имён System.IO, класс DirectoryInfo, методы CreateSubdirectory, file.OpenBinary() + stream.Write() – и все дела. На второй взгляд – тоже просто: примеры решения подобных задач имено так и сделаны. На третий взгляд – вообще всё замечательно: после компиляции код работает, документы выгружает. Ура.
Хуже на четвёртый взгляд, взгляд тестировщика – не выгружаецца! Целевая папка как бы недоступна… Нда… Модуль резервного копирования в ту же папку спокойно свои файлы сохраняет… При помощи отладчика можно наблюдать, как конструктор
new DirectoryInfo(path)без выбрасывания каких-либо исключений возвращает непустой объект (что и ожидается), у которого свойство Exists == false. Сюрприз, фокус-покус.
Фокус разоблачается разглядыванием в Рефлекторе или IL-шпионе (ILSpy) кода классов из пространства Microsoft.SharePoint.Administration.Backup. Там методы System.IO используются примерно так:
using (SecurityContext.RevertToSelf())
{
info = new DirectoryInfo(dir);
}
Вообще-то, собирался написать заметку про Internet Explorer 9, какой он падучий в версии RC – гораздо более падучий, нежели был в версии “бета” (уже отправил несчётное количество своих отчётов на “базу”, один отчёт перегонял больше часа), и как в нём не работают некоторые фичи, которые вполне хорошо работали в “бете”. И про то, что мои попытки переключиться на x64-вариант закончились, можно сказать, ничем (хоть и работает он не в пример стабильнее – точнее, вовсе ни разу не завалился, и фичи в нём все работают, и быстрее он – по ощущениям, конечно).
Остановило и заставило вернуться к 86-варианту IE9RC, наряду с невозможностью сделать x64-вариант браузером по умолчанию, отсутствие в природе x64-варианта одной “флагманской” вещи – Silverlight’а. Вот Adobe свой x64 Flash-плеер выпустила, ролики в x64-IE смотреть можно запросто, а MSFT конкурирующий SL – не выпускает (и даже анонсов не припоминается). А так как довольно много приходится заниматься Шарепойнтом, в котором заметная часть интерфейса переведена на Silverlight, - приходится постоянно спотыкаться: привыкаешь к новому…
В связи с этим вспомнился прошлогодний скандал после обмолвки одного из руководителей MSFT про скорый конец Silverlight’а – очень быстро для успокоения возмущённой общественности “анонсировали” пятую “версию” SL, на чём общественность и успокоилась… Получается, что зря успокоилась – забросят, всё же, Silverlight… Вероятность того, что забросят x64 линейку продуктов, следует оценивать, по-моему, гораздо ниже…
А жаль – работать с SL гораздо продуктивнее (в разных смыслах), чем с jscript. Остаётся надеяться, что сработает традиция MSFT поддерживать всякие legacy и истреблять уже имеющийся SL не станут.
Порекламировали тут в рассылке Google Cloud Connect
Поставил это чудо, покрутил, но так и не понял особого смысла всей затеи. Ну да, закинул документ Ворда в Google Docs - там его можно открыть в браузере и посмотреть. При редактировании, что в браузере, что в Ворде на десктопе, порождаются отдельные версии документа и не предлагается никаких средств для слияния 
Хотя есть share - можно пригласить людей для как бы совместной работы над документом.
Excel и вовсе повисла на "подготовке к синхронизации".
Office Web Apps ведут себя не в пример лучше - документ редактируется, предлагается режим одновременного редактирования, а потом версии сливаются, браузерная и десктопная.
В итоге снёс примочку, тем более, что она присобачила собственную дополнительную панель жуткого вида и нехилых размеров. Ленту, похоже, не осилили...
Работать с Шарепойнтом в ряде случаев уже удобнее с использованием браузеров Google Chrome или Mozilla Firefox.
Один из таких случаев – групповая загрузка файлов в библиотеку.
В принципе, Шарепойнт предлагает “встроенную” функциональность в виде кнопки “Отправить несколько документов” на ленте
Однако эта кнопка работает только в случае, если на компьютере пользователя установлен MS Office 2007/2010 (да и то не всегда – я на собственной машине правильной работы компонента добиться не могу, списываю на то, что кроме Офиса много всего понапичкано…). Но если работает, то всё работает хорошо – выбирать файлы достаточно удобно, обработчики, установленные в библиотеке, правильно обрабатывают загружаемые файлы.
Второй “стандартный” способ – с использованием WebDAV (через “представление проводника”)
Выбирать файлы достаточно удобно, однако с копированием могут быть проблемы -
Копирование происходит очень медленно, а обработчики обрабатывают файлы не совсем верно (похоже, при этом, как и при добавлении файлов вручную, по одному, выполняется “двухтактная” работа: сначала добавление файла в папку, потом редактирование элемента списка для установки атрибутов). В результате правильно срабатывает обработчик ItemAdded, а обработчик ItemUpdated запускается впустую (нужных атрибутов никто ведь не устанавливает…). С другой стороны, если никаких обработчиков нет, то и такой способ может пригодиться.
Для использования с другими браузерами на Codeplex можно найти симпатичный компонент Drag & Drop upload for SharePoint, который устанавливается на ферму и даёт возможность загружать файлы в библиотеки перетаскиванием из окна проводника Windows:
Выбирать файлы для загрузки достаточно удобно, обработчики, установленные в библиотеке, правильно обрабатывают загружаемые файлы
Итого: Наиболее удобным (когда работает) для использования следует считать “встроенный” способ с использованием офисных компонентов, наиболее надёжным и дешёвым – способ с использованием браузера Google Chrome и решения RENIT DragNDropUpload SP2010.
Очередной капкан обнаружился опять при работе с новым типом (ContentType) “набор документов” (DocumentSet). Потребовалось в качестве свойств элемента этого типа использовать Lookup-поля, ссылающиеся на списки в узлах, отличных от того, на котором лежит библиотека с нашими элементами…
Всё шло хорошо до того момента, когда значения Lookup-свойств потребовалось вывести на странице набора. Значения не выводились! WTF… 
Раскопки с помощью Reflector’а показали, что веб-часть DocumentSetPropertiesWebPart (используется для вывода свойств набора) использует для рендеринга метод SPField.GetFieldValueAsHtml(), который для Lookup-полей, работающих со списками с других узлов, выводит пустую строку 
. Собственно, разработчик этого метода, похоже, не подозревал о способностях поля работать с “посторонними” списками, поэтому и не использовал параметр LookupWebId 
, а по-простому обращался к списку со “своего” узла. Нормальненько так… 
Для обхода капкана можно, конечно, написать свою веб-часть вместо DocumentSetPropertiesWebPart, однако выяснилось, что так же ведёт себя и DocumentSetContentsWebPart, отображающая список документов внутри набора. А писать собственные гриды – удовольствие тО ещё…
В общем, спасибо индийским коллегам…
Второй сюрприз от неплохого типа – неверный перенос средствами экспорта/импорта настроек представления для содержимого набора документов. После импорта используется представление по умолчанию для библиотеки, а вовсе не то представление, которое было настроено до экспорта.
Исправляются последствия сюрприза использованием вот такого метода:
1: /// <summary>
2: /// Востановление представления стартовой страницы набора документов
3: /// </summary>
4: /// <param name="list">список/библиотека</param>
5: /// <param name="contentTypeName">Название типа содержимого</param>
6: /// <param name="viewName">имя представления</param>
7: private void ResetDocSetView(SPList list, string contentTypeName, string viewName) {
8: SPContentType contentType = null;
9: try { contentType = list.ContentTypes[contentTypeName]; } catch { }
10: if (contentType != null) {
11: DocumentSetTemplate docSetTemplate = DocumentSetTemplate.GetDocumentSetTemplate(contentType);
12: if ((docSetTemplate.WelcomePageView == null) (docSetTemplate.WelcomePageView.Title != viewName)) {
13: SPView view = list.Views.TryGetView(viewName); 14: if (view != null) {
15: docSetTemplate.WelcomePageView = view;
16: docSetTemplate.Update(true);
17: } else {
18: msgError += 19: string.Format("В списке [{1}] отсутствует представление [{0}]", viewName, list.Title);
20: } 21: } 22: } else {
23: msgError += 24: string.Format("В списке [{1}] отсутствует тип [{0}]", contentTypeName, list.Title);
25: } 26: }Technorati Tags: Sharepoint, DocumentSet