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

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

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

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

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

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

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

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