Опять сюрприз

И опять от Sharepoint, на этот раз не сильно безобидный .

Есть у меня веб-часть, разработанная ещё пол WSS 2003 и переработанная под WSS 2007. Собственно, форма для ввода данных в списки со всякими наворотами типа проверок/валидаторов, вычисляемых полей и т.д. Имеется также режим для работы анонимных юзеров. Всё жило довольно мирно, готовились к передаче заказчику, но после того, как прикрутил в веб-части HIP-систему MS ASirra, начали выскакивать странные ошибки, ранее никогда не встречавшиеся. При внимательном рассмотрении выяснилось, что возникает ошибка в куске кода вроде вот этого

   myData = myList.GetItemById(dataID);

после нескольких (5-6) постбеков с неправильными значениями в полях формы (юзеру выдаётся сообщение и предлагается заполнить поля правильно). При этом и myList != null, и dataID имеет нужное значение, а вылетает ошибка с сообщением о неверном значении dataID . Самое противное, что возникает ошибка только на "боевом" сервере у заказчика, на моих тестовых серверах - ни разу не получил, насмотревшись на кошек до мяуканья. Впору тронуться...

Решилось дело (вот уже два дня ошибки не возникает) заменой кода на вот такой

myData = myList.Items.GetItemById(dataID);

Вот, блин...

del.icio.us Tags: Глюкалово, Sharepoint

Очередной сюрприз от Sharepoint

Потребовалось сохранить информацию для веб-части в библиотечном файле. Сделал текстовый файл с нужной информацией, сохранил в UTF-8, загрузил в библиотеку.

В веб-части информацию считываю примерно таким кодом:

encoding = Encoding.UTF8;
//читаем документ
byte[] chars = file.OpenBinary();
OutStr = encoding.GetString(chars);

В OutStr получаю первый символ - мусорный . Другое дело, что у меня там комбинации вида имя=значение, поэтому удалось выкрутиться за счёт регэкспа. А если б патроны везли?

О глупости разработчиков антивирусов

В деревне Глюкалово не утихает жизнь. На досуге нашёлся ещё один способ подвесить мой компьютер с Vista x64 - в виртуальной машине с сервером Windows 2003 запустил антивирусный сканер от Microsoft OneCare в режиме полной проверки, на хосте (собственно, Vista x64) - сканер Dr.Web CureIt в режиме полной проверки. В течение 3-5 минут память "съели" на 99% и компьютер перестал подавать какие-либо признаки жизни.

После Reset'а выяснилось, что фокус произвёл Dr.Web, который сломал зубы на зацикливании при "обходе" папки, в которую смонтированы все мои диски и разделы - этим достигается инвариантность путей к файлам при работе в нескольких операционных системах. Ну, а так как подмонтированы все разделы, то и получается цикл. Не стал ждать очередного повешения и остановил это "сканирование".

Стало любопытно и запустил уже на Вистовом хосте Microsoft OneCare - вот уже не менее часа наблюдаю, как бедолага "выполняет" операцию "Чтение папок...". Интересно, когда остановится? Памяти ещё гигабайт есть. Неа, не дождался... Но остановить удалось, что уже хорошо

Осталось ещё ClamWin запустить на сканирование этой папки...

Technorati Tags: Глюкалово, Vista, Dr.Web, OneCare

Предел Висты или Vista limited

Похоже, удалось увидеть предельную загрузку, при которой происходит крах системы.

Система - Vista Ultimate x64 на процессоре Core 2 Duo 2.16 Ghz, память - 4 Gb , диски SATA.

Было загружено на момент краха:

• MS Virtual PC 2007 (память 1.5 Гб) с полной установкой Server 2003 и OSS 2007 (база небольшая, используется для тестирования при разработке)
• два экземпляра Visual Studio 2008 с 15-20 открытыми окнами в каждой, одна в режиме отладки веб-части на виртуальном сервере
• 4 экземпляра ИЕ 7.0 с 10-12 открытыми страницами в каждом
• 1 экземпляр Firefox 2.0 с 5 страницами
• 2 окна с удалёнными серверами по протоколу RDP
• SQL Server Express
• Outlook и OneNote 2007, Word 2007, 2 окна Excel 2007
• 6 окон Sharepoint Designer 2007 с открытыми узлами на удалённых серверах
• всякие мелочи - Sidebar, WMP, Intel Audio Studio, nnCron, DaemonTools и т.д.

Всё это хозяйство (естественно, несколько состав менялся) функционировало достаточно исправно в течение более 4-х суток (по таскманагеру Висты). В один из моментов стали наблюдаться сначала мелкие неполадки (типа моргания окон), потом и крупные (неправильная компиляция проекта в Студии). В таскманагере выяснилось, что в этот момент запустиось сканирование WinDefender'ом, индексация дисков встроенным поисковиком, Шарепойнт в виртуальном сервере тоже занялся какими-то своими делами. Загрузка процессора - постоянно 100%, памяти - 98%, на действия система не реагирует. Минут через пять сама предложила отключить Aero, после этого удалось закрыть некоторые программы, однако некоторые процессы остались висеть и чего-то делать. Загрузить ProcessExplorer и посмотреть на их занятия не удалось. Мало того, не удалось сделать ни Restart. ни Shutdown, работал только Hibernate, толку от которого в этой ситуации было мало. Помогло только отключение питания.

Хорошо хоть, что почти ничего не пострадало, пришлось только запускать офисного тестировщика - чего-то восстанавливал, сказал, что всё хорошо.

Ыщо один сюрприз от Sharepoint

Новая фигня обнаружилась с этими SPD-процессами - будучи повешенными на создание элементов списка, запускаются только при ручном "создании". Если элемент добавляется программно (другим РП), то это событие молча игнорируется.

РП "студийные" запускаются в обоих случаях.

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

Custom Workflow Activities

На Codeplex нашёлся довольно симпатичный проект, в котором привлек внимание компонент "Copy List Item Extended Activity" для копирования элементов списков (потребовалось нечто похожее для организации интеграции данных с разных узлов). При внимательном рассмотрении выяснилось, что основная "фича" - перезапись (OverWrite) скопированных данных после редактирования оригинала - не работает. Авторы не поскупились приложить исходники, из которых выяснилось, что соответствующего кода вовсе нет (спешили, наверное ).

Пришлось вникать и доделывать/переделывать - заодно пришлось переделывать все xml-описания (изобретатели забыли положить свой ключ шифрования ) и установщик (приложенный сборщик пакетов почему-то не пожелал работать как задумано ). Кое-что перевёл на русский.

В итоге стало работать как надо, правда, обнаружился сюрприз, который больше от Microsoft, нежели от авторов проекта.

Доработанный вариант можно взять здесь.

Сюрприз от Sharepoint

На одном из подшефных серверов перестали работать workflows (РП), сделанные при помощи Sharepoint Designer'а - не запускаются и всё тут... Новые РП при сохранении вызывают ошибки компиляции с отказом их принять (Errors were found when compiling the workflow.The workflow files were saved but cannot be run.Unexpected error on server associating the workflow). Много чего проделал - переустановил .NET'ы (попутно мусору вычистил немало), на виртуальном сервере попытался получить похожее поведение, перечитал все найденные материалы с описанием таких симптомов (их оказалось не так и много) - всё тщетно .

Рецепт нашёлся здесь. Спасибо, Jason Nadrowski . Механизм сюрприза такой: в систему раньше устанавливал пакет "возможностей", который нужно активировать для каждого приложения (на сервере делалось для трёх). Во время активации в файлы web.config всех приложений добавляется без проверки её там наличия запись в секцию <System.Workflow.ComponentModel.WorkflowCompiler>, где описаны сборки, которые должны загружаться при компиляции SPD-workflows. При деактивации и/или удалении feature запись удаляется, но одна из каждого конфига. В итоге в файлах web.config может остаться (а может и не остаться) любое количество записей о сборках, которых может в системе уже не быть. Поэтому компилятор и ругается.

Неясно, правда, почему не работают ранее скомпилированные процессы, не имеющие отношения к отсутствующей сборке, ведь процессы, скомпилированные в Visual Studio, вполне себе работают. В общем, очередной привет от благодетелей .

.NET и Mono continued

Помрёт, похоже, этот мой эксперимент на гриде - элементах DataGrid или DataGridView. В принципе, они работают и в Linux (Ubuntu), кое-какие свойства глючат, но терпимо. Плохо, что не работает толком редактирование в ячейках, но обойти можно, хоть и будет это выглядеть чесанием левой ногой правого уха. Самое плохое с навигацией по гриду - на колесо мышиное не реагирует, а полосы прокрутки (scrolling) загружают процессор на 100% :

Нижний контрол на форме - DataGridView, зелёная линия справа - график загрузки процессора (скачок загрузки произошёл в момент изменения размеров формы до появления scrollbar'а на гриде).

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

Осталось попробовать сделать интерфейс на ListView вместо грида - он, вроде, без фокусов с навигацией. Или делать программу в технике asp.net - говорят, эти программки переносятся хорошо (собственно, только они и переносятся).

.NET и Mono

Сделал в VS 2008 простую формочку и запустил в Ubuntu 7.10/ Все настройки Mono - дефолтные. Выглядит смешно (слева - убунтовский экземпляр):

смайлы