Создание управляемых свойств для поиска в Sharepoint 2010

В связи с миграцией решения с 2007 на 2010 версию Sharepoint, потребовалось переделать функционал регистрации управляемых свойство в службе поиска Sharepoint. Хотя старый функционал и работал, но функции, которые в нем применялись, были помечены как устаревшие.
Начал гуглить. Вначале нашел решение на PowerShell, а затем на C#.
Пользуйтесь!

Миграция с MOSS2007 на MOSS2010. Поехали!

Как я писал ранее, миграция Sharepoint с версии 2007 на 2010 не приносит особых сложностей, если используется только стандартный функционал. Но такое бывает крайне редко. Передо мной стала задача миграции портала вместе с существующими наработками.
Текущая версия портала развернута на MS  Windows Server 2003 SP2 (32-разрядная). В приведенной ссылке есть ссылка на документацию от MS по миграции. Существуют Требования к оборудованию и программному обеспечению (SharePoint Server 2010). Исходя из этой ситуации мне подходит только миграция БД с сервера c Sharepoint 2007 на сервер с Sharepoint 2010. Как всегда в интернете можно найти много информации, поэтому буду отталкиваться от статьи SharePoint 2010 Cookbook: How to Migrate a SharePoint 2007 Site to SharePoint 2010 Using Database Attach (некоторые картинки будут оттуда).
Опишу последовательность шагов:

Установка MOSS 2007 на Windows Server 2008 R2

В процессе миграции с MOSS 2007 на MOSS2010 решил попробовать In Place Upgrade. Для этого понадобилось установить имеющейся MOSS 2007 SP1 на Windows Server 2008 R2. Конечно же это не получилось сделать так просто, т.к. для того чтобы провести эту установку надо использовать MOSS 2007 SP2.

Решений много:

• Скачать MOSS 2007 SP2
• Скачать только  SP2 и провести обновление с MOSS 2007 SP1 на MOSS 2007 SP2 [1, 2]

Инструкция от Microsoft как проводить слияние.
Я решил пойти вторым путем, как наиболее интересным.

Во время установки и настройки Sharepoint может возникнуть проблема: When you launched “SharePoint Products and Technologies Configuration Wizard” and got into this error: Failed to start the database service MSSQL$OfficeServers.

Решение находится там же: Go to “regedit”, browse thru “HKLM_Local_Machine/Software/Microsoft/Shared Tools/Web Server Extensions/12.0/WSS/”. Then change the value of attribute named “ServerRole” from SINGLESERVER to APPLICATION. 

Анализ зависимостей программно? NDepend!

Натолкнулся на просторах интернета на хорошую статью:
Regfor's devblog: Анализ зависимостей программно? NDepend!: "Как поддерживать качества код на должном уровне? Есть много способов – культура написания кода, регулярное code review, всевозможные договор..."
Сам недавно поработал с этой утилитой. Хотел написать заметку, но меня опередили :)
Постараюсь поподробнее описать функционал, если меня не опередят :)

Миграция с MOSS2007 на MOSS2010

Сегодня возникла необходимость миграции портала, реализованного на базе MOSS 2007 на новую версию MOSS 2010. Благо тема не новая, т.к. новая версия вышла в мае 2010 года, поэтому инструкции по миграции давно есть. Среди них всех я выделю пожалуй только одну от производителя. Очень подробно описано.
В общем, пока такой вердикт: если не было сторонних разработок и контент не успел сильно распухнуть, то проблем в миграции быть не должно.
Но у меня как раз ситуация в том, что надо мигрировать решения, которые были развернуты на MOSS 2007. Благо все исходники на руках.
Вооружился студией и начал перекидывать реализованный код. Т.к. при реализации существующих решений не использовалось расширение от Microsoft VseWSS, то процесс миграции кода происходит немного болезнее.
Создал простенький проект. При развертывании решения получил такую ошибку: "Путь содержит недопустимые знаки." Проблема быстро нагуглилась, оказалось, что русские имена в пути лучше не использовать и не работать под пользователем, в имени которого есть русские буквы.
Еще заметил интересный факт. Если создать фичу, то в папке Features на сервере она именуется как [Имя проекта]_[Имя фичи]. На мой взгляд, это очень удобно, т.к. приходилось самому называть подобным образом фичи, чтобы не было дублирования в разных проектах. Не знаю как это повлияет на мигрирование решения. Посмотрим...

Протоколирование. Часть 2 Внедрение протоколирования.

Хотелось бы рассмотреть уровни зрелости внедрений протоколирования. Как-никак мы все в разной степени проходили через эти этапы.

Уровень 1. Начинающий.

Как правило, о протоколировании начинаешь задумываться, когда сталкиваешься с проблемами работы приложения на производственной среде Заказчика. Т.к., как говорилось ранее, не всегда у Заказчика возможно развернуть графические инструменты отладки, то приходится реализовывать инструмент протоколирования, например, запись в файл. Обычно разработчики начиняют свой код разного рода сообщениями, по которым он может понять до куда программа дошла, какие значения переменных имела и т.д. Иногда даже удается найти источник ошибки. После чего разработчику необходимо пересобрать приложение, убрав излишнее протоколирование или просто закомментировать, т.к. сильно частый вывод сообщений в протоколировании может уменьшить быстродействие приложения, поскольку тратится время на сам вывод сообщений. Но что происходит, когда появляется новая ошибка в приложении? Правильно, разработчик опять внедряет отладочные сообщения. Кстати, вполне реально, что он будет это делать в уже «отлаженном» в прошлый раз коде.

Dependency Injection в SharePoint

Сегодня потребовалось внедрить в проект по SharePoint управление зависимостями.
В качестве инструмента IoC был выбран Ninject.
Внедрение зависимостей в SharePoint дело не простое. Там нет удобной так называемой единой точки входа, которую мы имеем в любом другом решение, которое пишем с нуля (например, ASP.NET-проект, где в нашем распоряжении есть файл global.asax). Кое-какие идеи по внедрению конечно были, но чтобы не изобретать велосипед, решил вначале в интернете посмотреть как люди решают подобную проблему.
Практически сразу наткнулся на статью. Почитал её. На мой взгляд, там нет ничего криминального для SharePoint. Да и к тому же увидел, что человек применил некоторые из моих идей, которые я хотел попробовать. Спасибо ему, что сэкономил моё время.
Попробую на продакшине. Должно работать как часы.
А вы что думаете?

Установка Timeout в сгенерированных DataSet

Добрый день!
В одном из рабочих проектов используем сгенерированные DataSet через XSD-схему, на которую переносятся хранимые процедуры из БД. Как говорится, программа работала отлично до поры до времени. Объем данных вырос и отчеты, использующие эти хранимые процедуры, стали долго строиться (используем ReportViewer) и в конечном итоге вылетать по тайм-ауту. Ясно дело, что надо устанавливать Timeout у SqlConnection. Но лесть в сгенерированный код не хочется, но и не нужно.
Натолкнулся на статью с примером функции расширения:

public static void TableAdapterCommandTimeout(this T TableAdapter, 
        int CommandTimeout) where T : global::System.ComponentModel.Component
{                
    foreach (var c in typeof(T).GetProperty("CommandCollection", System.Reflection.BindingFlags.NonPublic | 
                         System.Reflection.BindingFlags.GetProperty | 
                         System.Reflection.BindingFlags.Instance).GetValue(TableAdapter, null) as 
                         System.Data.SqlClient.SqlCommand[])
        c.CommandTimeout = CommandTimeout;

}

Теперь можно её использовать, например так:

this.FooTableAdapter.TableAdapterCommandTimeout(60);

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

Явное и неявное преобразование в строку

Тут что-то подумалось. Почему люди так любят вызывать метод ToString() в случаях подобном этому:

int x = 10; 
string str = "Значение = " + x.ToString();

Лично я предпочитаю следующую запись:

string str = "Значение = " + x;

Это удобно для меня во многих случаях. Самый яркий пример: есть коллекция и я пытаюсь получить оттуда значение:

IList<string, int> list = new List<string, int>();
list.Add("key", 10);
string str = "Значение = " + list["key2"]; //Напишет "Значение = "

Если попробовать применить ф-ю list["key2"].ToString(), то получим исключение. Чтобы не было исключений, надо проверять возвращаемое значение из коллекции.
Лично мне кажется это неудобным и поэтому я использую комбинацию:

• list["key2"] + ""
• Последующая проверка на string.IsNullOrEmpty(), если нужно.

А вы что думаете?

Протоколирование. Часть 1.

Всех с наступившим 2011 годом!!! Начнем цикл статей... 

Введение
Этот цикл статей родился не просто так. Тема протоколирования широкая (это демонстрирует объем прочитанных статей в интернете, на основе которых вкупе со своим опытом и создан этот материал), и каждый программист решает, как ему удобно отлаживать свои программы. Т.о. количество средств протоколирования растет очень быстро, т.к. постоянно изобретаются велосипеды. Вред подобного «велосипедостроительства» рано или поздно становится понятен каждому разработчику. К сожалению, я не стал исключением, реализовав свою систему протоколирования в нескольких проектах. Цель этого цикла статей – дать разработчику информацию о существующих системах протоколирования. И пусть каждый разработчик сам выбирает готовый инструмент в зависимости от своих потребностей. Если появятся интересы, то можно будет провести тестирования средств и понять, какое из них нам все же по душе.

Так же стоит понимать, что ни одно из средств не может быть панацеей от всех бед. Т.е. скорее всего, для каждого отдельно взятого случая подойдет та или иная система протоколирования.