Мой новый рекорд по количеству установок Windows Vista подряд

Я убедился, что был прав. До первого сервис пака Висту ставить не следует.

Недавно мне потребовался IIS и я попытался его поставить. Не получилось, как не получилось поставить даже банальный Telnet Client - в Event Log сыпались ошибки, связанные с Windows Servicing (Windows Servicing failed to complete the process of setting package XXX into YYY(YYY) state). Кроме того, при попытке перемещения\копирования файлов с рабочего стола диалог копирования подвисал, а файл блокировался даже на чтение до перезагрузки. Это то, что меня уж сильно достало (было еще несколько неприятных вещей).

Я записал установочный образ июльской Vista Ultimate от noPE, поставил, при первом старте выполнил привычные действия - изменил рабочую группу и поменял метки\точки монтирования дисковых разделов. При попытке добавить\удалить компоненты системы - та же ошибка Windows Servicing!

Сначала согрешил на какой-то апдейт, встроенный в июльскую сборку. Записал июньскую от ETH0 (с нее я ставил в прошлый раз и помню, что удаление\добавление компонентов работало). Поставил, попытался изменить компоненты - успешно! Выполнил привычные действия, после которых начала вылазить горе-ошибка...

Итак, проблема может быть следствием

1. изменения рабочей группы по умолчанию;
2. переразметки букв разделов.

Переставил, сменил рабочую группу, проверил - работает. Выходит, проблема в переразметке букв разделов.

Диск был разбит на два первичных раздела и один логический. На primary1 стоит Windows XP, на primary2 - ставлю Windows Vista, logical - хранилище. primary2 получал точку C:\, а primary1 - D:\, причем букву primary1 Disk Management сменить не разрешал (Windows cannot modify the drive letter of your volume. This may happen if your volume is a system or boot volume, or has page files). Переразметку я выполнял с помощью Acronis Disk Director 10, который сумел сменить букву так, как мне надо. В результате - проблемы с Windows Servicing. Бред, конечно, но, что поделаешь.

В результате: 5 переустановок, массивные сдвиги\переносы разделов (раздел с XP переехал на отдельный винт, раздел Vista стал единственным первичным). 7 часов угробил.

Назойливые дефекты Visual Studio 2005/2008

Мучительно неприятно, что некоторые вещи не исправляются даже с выходом новой версии. Не говоря уже о сервис паках! Предыдущий пост, новый дефект:
Окна задочены наверху, включен Auto Hide - списки "Modules" и "Processes" пустые!
Убираю Auto Hide - строчки появляются в обоих окошках.
Ставлю Auto Hide - список "Processes" опять пустой, "Modules" заполнен.
Картинка снята с Visual Studio 2008 B2. В 2005SP1 ситуация аналогичная. А в 2005 без SP1, кажется, все нормально.

Скучно

Программинг подобен чтению хорошего детектива - все проясняется только в самом конце... На работе сейчас полный застой. Что делать - непонятно, как делать - непонятно. Кого спрашивать - непонятно. Сижу, читаю Акунина :)

Visual Studio native debugging

Visual Studio можно использовать в качестве отладчика нативного кода (по большей части интересует возможность прерывания на функциях WinApi). Для этого нужно установить некоторые параметры отладчика:

http://msdl.microsoft.com/download/symbols
Галочка "Search ..." установлена для того, чтобы символы грузились по требованию, а не каждый раз при старте приложения или аттаче к уже запущенному.

Собственно, вот и просьба загрузить символы:

Самое важное - как установить точку останова на функции. Формат функции такой: {,,some.dll}MangledFunctionName. Пример: {,,user32.dll}_MessageBoxW@16

TypeMock.NET

По словам моего сотрудника, человека с приличным опытом, TypeMock.NET - лучшее решение для генерации (точнее сказать - просто решение, но об этом позже) Mock-объектов и использования их в юнит тестах.

Традиционные Mock фреймворки имеют определенные требования к объектной модели, обусловленные принципами функционирования - сабклассинг и динамическая генерация кода. Эти требования нередко заставляют проектировать с учетом необходимости юнит тестирования посредством Mock-объектов, что негативно сказывается на конечном результате и удобстве использования. Некоторые вещи вообще с трудом подлежат юнит тестированию, например, классы, использующие внешние статические методы. Решается либо условной компиляцией (далеко не уйдешь) либо перепрограммированием механизма взаимодействия объектов (порядочное усложнение существующего кода).

Итак, почему же "#1 Mocking Framework"? Лучше всего сразу посмотреть на возможности TypeMock.NET, который доступен в 3-х редакциях - Community (бЭсплатно), Professional и Enterprise (соответсвенно, за денюжку).

Если пройтись по списку фич, можно заметить такие интересные и, на первый взгляд, невозможные вещи, как "mock all types, including sealed and internal classes", "fake any method", "mock third-party types, including types in the .NET framework". Нам заявляют, что TypeMock способен подделать поведение любого объекта, в т.ч. его статических методов!

Банальнейший пример демонстрирует, что sealed класс SqlConnection начинает вести себя так, как ему приказано! Шокирующих примеров хватает.

Досих пор меня мучил главный вопрос - как это работает?! Парочка часов скитаний по сети увенчалась успехом! Итак айнц, цвай, драй. И все стало на свои места.

Хитрое решение - перехватывать события .NET приложения (например, вызов метода) с помощью публично доступного Profiler API (на этом, кстати, построены все профайлеры .NET приложений) и подменять исходное поведение требуемым. Хитрое, но не идеальное, т.к. возникают проблемы с отладкой юнит тестов.

Как итог могу написать, что TypeMock решает главную проблему, связанную с юнит тестированием, - проблему создания изолированно-тестируемых классов. С TypeMock об этом вообще можно смело забыть.