Вышли релиз-кандидаты Visual Studio 2010 и TFS 2010. Поставил, смотрю…

Про “студию” могу сказать пока только то, что работать стала существенно быстрее, чем прошлая Beta2. Предыдущая версия своей производительностью, признаться, наводила на мысль о том, не пошло ли использование WPF в ущерб. Однако, теперь этого ощущения нет. Работает не медленнее 2008-й – это точно.

А вот TFS стоит отметить отдельно. Устанавливать его теперь гораздо приятнее, чем его 2008-го предка, с которым ещё намучаешься устанавливая, да и немало (помню, как в Алкателе сидел до 10 вечера, выполняя установочные инструкции по шагам).
Установка же 2010-й версии проста и даже примитивна. Два этапа: собственно, установка, которая занимает всего пару минут, и конфигурация в визарде, что тоже занимает примерно столько же времени.
Сразу скажу, что я пробовал только Basic конфигурацию (там есть ещё пара вариантов), так как устанавливал на локальную машину. Приятно, что в Basic-варианте работает и билд сервис, и даже web access, и при этом ему не нужно ничего, что начинается с “Sharepoint”. И работает даже с SQL Server Express.
Поставил – и работай. Просто, удобно, как и хотелось.

Много всяких интересных штук там, в TFS 2010, но я хочу отметить две:

1. Билд-сервисы:
• На одной машине можно без хаков иметь несколько build-агентов, что не может не радовать;
• Билд-скрипт, который был раньше MSBuild-проектом, теперь представляет собой Workflow. Редактировать его в Workflow-дизайнере, добавлять и даже создавать свои собственные задачи теперь гораздо удобнее и приятнее.
  
2. Gated Check-Ins.
   Здесь я, признаться, в замешательстве. Поясню: Gated check-in – это когда разработчик делает check-in в репозиторий, при этом выполняется build, если хотите – прогон unit test’ов, и если что-то пошло не так, то внесённое изменение отвергается и не попадает в систему контроля версий. А если всё прошло как надо, то изменение попадает в соурс контрол, конечно. Соответственно, в соурс контроле мы имеем ветку, которая никогда не будет сломана и всегда будет как минимум компилироваться, а как максимум – зависит от вашего покрытия юнит тестами.

Так вот, Gated Check-Ins работают в TFS2010 замечательно, билд никогда не ломается и всё такое. Но есть у меня одно недопонимание, одна фича, которую, как я надеялся, исправят после Beta2, но она осталась…

Выглядит это так:

1. Я изменяю код и делаю check-in.
2. Поскольку мои изменения, пока не прошла валидация, де-факто не попадают в репозиторий, я всё ещё вижу изменённые файлы как checked-out.
3. Билд и юнит-тесты проходят успешно, код попадает в репозиторий.
4. Здесь я ожидаю, что файлы станут checked-in, если я их больше не трогал. Онако, этого не происходит.
5. Я пытаюсь делать Get Latest Version или Check In снова, не важно что из этого.
6. TFS, внимание, заявляет, что у меня локально присутствует версия файла #7, а в репозитории она уже #9 (очевидно, #8-это мой промежуточный check-in, #9 – финальный после валидации).
7. Мне необходимо сделать merge версий 7 и 9! Хотя, ежу понятно, что они одинаковы, ибо это изменение делал я, только я и никто больше!
8. Я признаю, что merge в VS2010 и в VS2008 – вещи очень и очень разные в пользу VS2010, там надо нажать ровно одну кнопку, даже никаких всплывающих окон, но сам факт… И так, делаю auto merge, всё проходит отлично, так как нет разницы, но файлы-то остаются в состоянии checked out!
9. Я должен снова сделать check-in, и тогда оно мне скажет: изменений нет. И пометит файлы как checked in, чего мне и хотелось.

Звучит, возможно, сложнее, чем есть на деле, но вы попробуйте :)

Я понимаю, что это, наверное, достаточно сложно – отследить, что я действительно не менял файлов пока шла валидация, поэтому нельзя просто сделать их checked out когда она закончена.. Ну, вдруг я менял.
Я понимаю, что в общем случае при таком вот “отложенном” check-in может возникнуть automerge от нескольких разработчиков и в этом случае нужно просить делать merge…
Но я не понимаю, разве нельзя было ввести ещё один статус “в процессе валидации" для файлов в солюшн эксплорере? И “сбрасывать” его обратно в “checked out” если я меняю эти файлы? Пусть даже и на основе read-only атрибута в файловой системе?
Разве нельзя отследить, что во всём этом процессе вот для этого конкретного файла не было никакого автоматического merge’а сделано на уровне TFS? И не просить меня делать merge если файл не меняли ни локально, ни в TFS?
Во всех остальных случаях – спрашивайте, пожалуйста, я только рад буду и буду делать merge с удовольствием!

Короче, тут можно, конечно задать вопрос “Вам шашечки или ехать?”, и утверждать, что целостность билда важнее всех этих мелких неудобств.. Но ведь хочется, чтобы и их не было… :)

В общем, пока как-то так…

Как-то вот здесь я рассказывал о методе синхронизации БД, который мы решили использовать в нашем проекте.
Так вот, сегодня хочу сказать, что решение хоть и было неплохим, но от него пришлось отказаться по причине некоторых проблем, которые не решаются с его помощью.

Проблемы эти таковы:

1. При изменении объекта базы данных (процедуры, функции, триггера и т.д.) разработчик создаёт скрипт и помещает его в репозиторий. Всё бы хорошо, но несколько разработчиков могут написать свои скрипты (пофиксить что-то в процедуре, скажем), положить в репозиторий независимо.. И “победит” последний. Причём узнаётся об этом обычно в самый ответственный момент: на этапе тестирования (если не позже). Проявляется баг, разработчик недоумевает “я же пофиксил его, вот и скрипт есть!”. А то, что одни-двумя изменениями дальше идёт совершенно иная копия – как же это проверишь.
   
2. Вышеописанная проблема многократно усугубляется в случае использования веток (бранчей).
   Так, как в разных бранчах делаются разные куски функциональности, то, во-первых, достаточно сложно поддерживать “сквозную” систему нумерации. Либо при каждом слиянии бранчей нужно как-то “перенумеровывать” скрипты, но тоже никогда не скажешь, какой именно должен быть порядок в итоге.
   Кроме того – та же проблема: в одном из бранчей поменяли процедуру, в другом – тоже. Скрипты перенумеровали, залили в репозиторий – а не работает.
   При этом очень сложно сказать, какая же версия была “в оригинале” (базовая), какая являет собой изменение в одном бранче, какая – в другом. Это же всё разные файлы, да и их ещё поискать.

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

На замену пришёл новый Database Project для Visual Studio 2008: http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en

Его нужно скачать, установить – и вроде как все проблемы решены :)

Краткое описание того, что мы имеем, используя эту штуку.

Все объекты БД представлены в виде скриптов.

На этапе инициализации проекта ему нужно указать БД, из которой он “заскриптует” все элементы схемы: таблицы, представления, процедуры, очереди, индексы, ключи, роли.. всё-всё-всё, даже CLR-сборки, если таковые имеются.
В результате разработчик получает дерево, по своей структуре очень похожее на то, что мы привыкли видеть в Management Studio, но все элементы – в виде create-скриптов.

Проект “умеет” отслеживать ошибки на этапе “компиляции”.

Это очень удобно! Например, если мы попытаемся создать скрипт для индекса по несуществующей колонке, создать view для несуществущей таблицы или что-то ещё “этакое” (да просто допустим синтаксическую ошибку или опечатку), то мы увидим ошибку “компилятора” (так же, как мы видим в случае ошибок в коде). Понятное дело, что пока в проекте есть ошибки, изменения в БД применяться не будут.
Что характерно, проект разбирает скрипты и зависимости между ними самостоятельно, а не просто пытается выполнить SQL-код и перехватывает ошибки.
Так с предупрежденями.

Возможности рефакторинга.

Если честно – много не пробовал. Но оно там есть. Например, переименование таблицы или столбца. Просто кликаем правой кнопкой мыши на элементе в дереве, выбираем Refactor –> Rename – и готово. Будет переименовано везде.

Использование макро-переменных.

Скрипты – они, конечно, обычные SQL-скрипты, но в них можно (если захочется) использовать макро-переменные в виде $(DatabaseName). Значения этим переменным можно задать в конфигурации проекта, далее эти макросы будут автоматически подменены там, где они встречаются.
Зачем? Ну, я не знаю :) То же имя базы данных (или linked-сервера). Тот же логин пользователя. Словом, то, что может отличаться от среды к среде (у разработчиков – одно, в продакшн – другое).

Ещё много всякого…

…в виде определения изменений между проектом и базой данных, возможностями юнит-тестирования и т.д.

Как это работает.

Процесс примерно такой:

1. Мы говорим проекту “Deploy”.
2. Происходит Rebuild проекта. На этом этапе делаются все проверки на ошибки, предупреждения и т.д. В том случае, если ошибок нет, идём дальше.
3. Происходит сравнение схемы базы данных, в которую мы делаем deploy cо схемой, которая присутствует в нашем проекте в виде кучи create-скриптов. По результатам этого сравнения генерируется дельта-скрипт, который содержит уже всевозможные alter, delete, create и т.д.
   Надо сказать, что дельта эта генерируется очень качественно. Мы тестировали на достаточно сложных комбинациях – всё проходило “на ура”. Проблем не было ни разу.
4. Дельта-скрипт применяется в базу данных.

Кстати, применять дельта-скрипт вовсе не обязательно, можно “сказать” проекту, что этот скрипт нужно просто сгенерировать.
Вообще настроек у проекта достаточно много: ANSI-ключи, нужно ли удалять объект, если он пропал из схемы проекта, нужно ли делать бекап перед применением дельта-скрипта и т.д, проще посмотреть.

Да, это всё DDL.
Что касается DML: тут всё совсем примитивно просто: есть два раздела: PreDeployment Scripts и PostDeployment Scripts. Туда (обычно в Post-, разумеется) и предполагается складывать скрипты для DML. Единственное, за чем надо следить – так это за тем, чтобы скрипты проверяли, нужно ли делать то, что они хотят делать. Ибо все они будут исполняться каждый раз при обновлении БД из проекта. Но это, как и понятно, сделать очень и очень нетрудно и вообще best practices :)

Автоматическое развёртывание.

Поскольку всё делается через msbuild, все targets уже на месте, то нет проблем ни с каким билд-сервером, ни даже без него (msbuild можно и из командной строки запустить). Словом, всё точно так же, как и с любым “кодовым” проектом - “на ура” автоматизируется ночной билд-деплой, например.

Плюсы.

Для нас – очень существенные. Судите сами: каждый объект -  это просто текстовый sql-файл. Как и любой другой файл с кодом, он отлично “уживается” в системе контроля версий, если два или более разработчика правят один файл – они будут иметь нормальный “человеческий” конфликт при чекине (или при слиянии веток) на этом файле и будут иметь все возможности грамотно этот конфликт разрешить.

Кроме того, правка таблиц, например, становится гораздо более лёгким делом, так как не приходится задумываться об ALTER TABLE, проверке на наличие (дабы не свалиться с исключением при попытке добавить то, что почему-то уже существует) и т.д. Нужен новый столбец: просто дописал его в CREATE-скрипт для таблицы – и всё. Остальное проект сделает за тебя.

Минусы.

У нас база данных – большая. Поэтому сравнение идёт достаточно долго. Долго – это где-то от 5 до 10 минут.
Хотя тут тоже не всё понятно. Сравение идёт долго на UAT-сервере, а вот локально, на той же БД (backup/restore) – одна минута пятнадцать секунд на весь деплоймент. Так что тут нужно ещё смотреть, нет ли у нас каких-то инфраструктурных затыков.

Пока это единственный минус, который я нашёл. Хотя для нас он не очень-то и существенен, даже если с инфраструктурой не разбираться. Ну, будет ночью билд-деплой длиться не 15 минут, а 25. Ну и кому какая разница, все спят :)

Словом, будем теперь так жить.

Такую вот ошибку выдала сегодня Visual Studio. Ну, или Team Explorer, не знаю, кто из них:

Думал, такое в сказках бывает :)

Вчера (или позавчера) в публичный доступ выложили Visual Studio 2010 Beta 1 и .NET Framework 4.0 Beta 1.
Поскольку я из своего личного опыта знаю, что начиная с бета-версии со студией уже можно вполне нормально работать, да и сам статус “Бета” означает, в отличие от CTP, что архитектура фреймворка устоялась и даже если и будет меняться, то будет меняться незначительно… В общем, нет повода не начать присматриваться к будущему инструменту. И нет повода не начать изучать инфраструктуру, с которой придется работать, опять таки в будущем.
Ну а чтобы было не так скучно, буду писать по ходу дела. Сегодня – только про “студию”, дальше – глубже.

Про установку рассказывать не буду. Установка – как установка, времени сколько заняла – не считал, не принципиально. Самое интересное – после.

Нужно сразу сказать, что UI у Visual Studio теперь сделан на WPF. Даже редактор кода. Отсюда много всяких интересностей (а то, на самом деле, для всех людей программы развиваются, принципиально эволюционируют, а программисты до сих пор в примитивных, в общем-то, текстовых редакторах сидят). Но пойдем по порядку.

При первом запуске на обновленной стартовой странице я увидел возможность загрузить расширения.
Про расширения – отдельная история. Расширения к новой “студии” делаются и подключаются до безобразия элементарно (фактически атрибут навесить да в папку скопировать), не то, что раньше. Над extensibility поработали тоже неслабо. В общем, наверное, стоит ожидать большого количества плагинов на любой вкус, начиная от визуализаторов (те же комментарии показывать не в виде xml comments, а более красиво и функционально, как это показывали на MIX) и каких-то очень функциональных вещей.

Итак, расширения. Конечно, стало интересно. И, конечно, их пока не много – всё же бета, да и комьюнити не подключилась… Но полезного я себе уже нашел:

Полезным показался Regex Editor (возможно будет альтернатива глючному “The Regulator” и волшебному “ConsoleApplication1”), Italic Comments (интересно попробовать) и Image Insertion для вставки картинок в комментарии (я уже говорил, что UI написан на WPF и редактор стал более продвинутым?). Комментарии я люблю (в том числе и писать). Советую.

Что приятно, очень приятно - “студия” “научилась” строить sequence-диаграммы! То есть, можно кликнуть мышкой на любой метод, ограничить уровень вложенности и получить такую вот диаграмму:

Или вот так:

Это как раз то, чего не хватает в повседневной работе! Не слишком-то это удобно – отслеживать Call Flow с помощью Find All References / Go To Definition. Или в дебаге по call stack’у, тоже не всегда удобно.

О дебаге, кстати. Появился новый (во всяком случае я такого раньше не видел) инструмент: Debug History:

Очень удобно! На каждом шаге можно посмотреть и autos и call stack. Ну и обратите внимание на значки на второй картинке: тоже, на мой взгляд удобно.

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

Всё это, конечно, очень полезно. Очень всего этого не хватет, когда садишься, как у меня это в последнее время бывает, рефакторить подсистему, с которой дела раньше не имел…

Над профайлером тоже поработали в плане внешнего вида и отчетности. Функциональные отличия, впрочем, пока не сравнивал.

Плюс в составе студии (team suit я ставил конечно) появились очень полезные инструменты для работы с базами данных, из картинки хорошо видно, что там.

Впрочем, если говорить о поддержке нескольких ДБ (релиз или несколько, тест, девелоперская база) мы в команде нашли отличную методику поддержки всего этого дела в едином состоянии, синхронизировании схем и т.д.
Как-нибудь расскажу, а то давно ничего не писал :)

Инструментов рефакторинга, кстати, в Visual Studio 2010 не добавили. Жаль. Ибо ReSharper, например, глючен неимоверно, так и пришлось его снести чуть ли не всей командой. Самые стойкие еще держатся (таких у нас один). Из категории “мыши плакали, кололись, но продолжали есть кактус” :)

Это был мой первый запуск Visual Studio 2010, так сказать, знакомство с интерфейсом. На более функциональные вещи как студии, так и 4-го фреймворка посмотрим чуть позже.

Мы, как и многие-многие команды, используем TFS для организации командной работы. Штука-то удобная. Но речь не об этом. А о том, что проект в TFS предполагает использование какой-либо методологии. Чаще всего это MS Agile, реже люди используют CMMI (эти два типа доступны в TFS сразу после установки), реже люди устанавливают и используют что-то свое.

Опять же, чаще всего выбор какой-либо из двух этих методологий (CMMI или Agile) производится неосознанно и только лишь потому, что нужно же что-то выбрать, иначе проект создать не получится. Поэтому часто бывает так, что следование методологии заканчивается на требовании каждый checkin привязывать к воркайтему. Получается так потому, что обе эти методологии, если ими пользоваться “как положено”, достаточно затратны, сами эти методологии недосточно “прозрачны” и, как следствие, отдача от них, в общем-то не слишком и велика.

Затратны потому, что слишком велико количество ролей в команде, слишком формализованы их взаимоотношения, на поддержание “курса” требуется ощутимое время.

Непрозрачны потому, что, с точки зрения разработчика плюсов практически не видно, его лишь заставляют следовать определенному набору правил, а почему и зачем..
Со стороны менеджера (того, который настоящий менеджер, а не того, который непонятный PM), в общем-то, тоже не ахти. В каком состоянии продукт прямо сейчас? Что нужно для того, чтобы успешно закончить проект? Сколько времени это займет? Непонятно. Нет, конечно, некоторое понимание есть…
Отсюда получается, что единственный человек, который понимает, что происходит – это тот самый непонятный PM, который ведет этот проект в рамках этой методологии.

Естественно, я утрирую – конечно, существуют организации, в которых все, как один, пронизаны духом той или иной методологии, прекрасно взаимодействуют друг с другом, отлично понимают, что делают и зачем. В этом случае и отдача есть. Но, думаю, утрирую я не сильно, ибо и мировой опыт применения CMMI, да и просто здравый смысл показывает, что таких команд мало.

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

Этим “чем-то” оказался Scrum. Scrum настолько прост, чтобы вся методология уместилась на одном листе А4, затраты на его поддержание выливаются в 10-15 минут в день, а прозрачность такова, что в любой момент любой (даже совершенно незнакомый с методологией) человек может увидеть и понять, в каком состоянии находится проект сейчас, что уже сделано, что еще будет сделано и сколько времени еще понадобится для того, чтобы получить продукт с нужной функциональностью.

При этом вся эта информаци доступна для понимания и дивелоперов, и менеджеров, и кастомеров. Всё гениальное просто, впрочем, поэтому Scrum и пользуется такой популярностью.

Впрочем, Scrum – это лишь методология, её еще необходимо связать с реальностью рабочим окружением. Да, он настолько прост, что достаточно Excel для полноценной его поддержки, но работать с TFS (удобно же!) и еще и с Excel параллельно тоже не хотелось (хотя недели три и это давало свои ощутимые плоды).

Для осуществления этой связи мы перебрали несколько шаблонов Scrum для TFS. В результате я нашел шаблон, который отлично соответствует как букве методологии (нехитрая терминология, жизненный цикл), так и ее духу (простота и прозрачность). Взять его можно вот здесь: http://www.scrumforteamsystem.com/en/default.aspx

Примечательно, один из наших тимлидов, который работал на “пилотном” для нас проекте Scrum, очень сильно проникся выгодой его применения и даже купил книжку от создателя этой методологии о том, как выгодно применять ее в enterprise-среде, когда увидел портрет при инсталляции темплейта закричал: “О! Это он! Это он!” :) Оказалось, что в создании этого шаблона автор методологии принимал участие лично :)

Конечно, шаблон “умеет” гораздо побольше Excel-проектика, особенно в части отчетности. Выполнен шаблон тоже очень качественно в части того, что из себя представляют воркайтемы, как они выглядят, какие имеют поля. Портал проекта тоже на высоте.

Что важно для меня как для дивелопера – наряду с тем, что интуитивно понятно, как заполнять тот или иной воркайтем, сами они перестали быть некими абстрактными единицами, как было ранее (разве что воркайтем Bug имел какой-то интуитивно понятный смысл), но приобрели какое-то значение, стали обладать, можно сказать, своей функциональностью и смыслом. А раз появился четко выраженный смысл и функциональность, то и отпадают всякие вопросы о том, какой воркайтем в каких условиях создается и в какое состояние когда переходит.
То есть, не как было с Task и Scenario – потому, что “вот так договорились, так предполагает Agile, а вообще-то, физически, разницы никакой”, а вполне себе четко, повторяюсь, интуитивно понятно и, главное, для проекта действительно _имеет_ смысл то, какой тип воркайтема ты создаешь.

Кроме этого темплейта у той же команды и еще одна интересная штука: Task Board. Это WPF-приложение, работающее с TFS посредством веб-сервисов и отлично визуализирующее процесс (и позволяющее управлять им). Вот оно: http://www.scrumforteamsystem.com/en/TaskBoardBeta/Default.aspx

Там есть видеоролики, наглядно демонстрирующие возможности, и скриншоты.

Словом, если у вас тоже есть команда (или несколько) из нескольких человек, вы хотите получить дополнительный ресурс в дивелоперскую команду (роли непонятного PM’а там нет, поэтому он сможет заняться делом вместо того, чтобы спрашивать “как продвигается”), если вы тоже пользуете Agile или CMMI-шаблон, но не используете саму парадигму, если вы хотите сделать проект прозрачным для себя, руководства и заказчиков и при этом не погрязнуть в формализации – есть смысл посмотреть на Scrum и на его “инкарнацию” в TFS :)

Готовится к выходу первый сервиспак для VS2008 и .NET Framework 3.5.

Очень много багфиксов, обещают поднять производительность. Впрочем и список нововведений впечатляет.

С сегодняшнего дня доступна бета-версия сервиспака.

Подробнее здесь: http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx

Сегодня переустанавливал Team Foundation Server, пришел таки диск с новой, 2008-й версией.

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

Оказалось зря. В Майкрософте времени даром не теряли и сделали-таки нормальный инсталятор, который сам обновлял базы данных, перезапускал IIS и так далее. Все произошло очень быстро, я только успевал замечать ход работ по task manager'у.

Клиентские машины даже не поняли, что что-то поменялось (внешне, конечно).

Однако, не обошлось и без "ложки дёгтя".

После обновления оказалось, что функция Undo Pending Changes не работает по причине несоответствия кодировок базы tempdb и TfsVersionControl (вроде). Поиски в интернете привели к тому, что я такой не один, а причина в том, что в сохраненной процедуре, отвечающей за Undo Pending Changes, ребята из Майкрософт забыли указать правильную кодировку, создавая временные таблицы. Именно что забыли :)
В качестве решения было предложено пересоздать системные таблицы с нужной кодировкой, что равносильно переустановке SQL-сервера. Даже хуже, пересоздать базы для SQL-сервера с установленными сервиспаками ни капли не просто, а быть может даже невозможно, в виду отсутствия дистрибутива со включенными сервиспаками.

Однако я нашел слухи, что Майкрософтовцы сделали hotfix для этого дела, но никому его не дают - надо отдельно запрашивать. Я написал разработчикам из команды TFS, они ответили, что hotfix действительно есть, но просить его надо не у них лично, а у support-команды ("команды поддержки", чтоли, на русском? Смешно :))

Позвонили в саппорт. Там обещали перезвонить через недолгое время и заплатку дать. Посмотрим, что получится.

Быть может потом расскажу о впечатлениях от новых фич TFS :)

Несколько месяцев назад Microsoft анонсировала, что код .NET Framework будет открыт для всех желающих.

С сегодняшнего дня это так. Открыт код системных библиотек, код ASP.NET, Windows Forms, WPF, ADO.NET, ASP.NET и XML. Остальные библиотеки, такие, как LINQ, WCF, WWF и CardSpace будут открыты чуть позже.

Кроме того, этот код можно использовать для дебага с помощью Visual Studio 2008 - чрезвычайно полезная штука. То есть, теперь можно просто жать F11 в режиме отладки, студия сама будет подкачивать необходимые файлы и исходным кодом и отладочной информацией.

Для того, чтобы дать студии возможность это делать, нужно:

1. Установить обновление VS 2008 QFE, с ним у дебаггера появится возможность делать то, что мы от него в данном случае хотим.
2. В опциях Visual Studio 2008 нужно найти раздел Debugging\General и в предложенном обилии настроек снять галку "Enable Just My Code" и установить галку "Enable source server support".
3. Там же, в Debugging перейти к подразделу Symbols и добавить адрес, откуда будет скачиваться отладочная информация, вот этот: http://referencesource.microsoft.com/symbols. На этой же вкладке нужно указать каталог, в котором эти самые файлы отладочной информации будут кешироваться (чтобы не грузить каждый раз заново, это занимает существенное время, при первой загрузке увидите, будте готовы), а так же установить галку "Search the above locations only when symbols are loaded manually".
4. Нажать кнопку ОК :)

Теперь можно дебагить код Microsoft аки свой (что иногда очень удобно).

Оказывается, Visual Studio 2005 Office Tools не может работать без еды. Причем еда годится не любая, первоначальный вариант ее, видимо, либо быстро кончился, либо пришелся не по вкусу и пришлось готовить "второй выпуск":

А вы говорите "искусственный интеллект" :)

Итак, релиз свершился ранее, чем 2008й год.