Сейчас явно прослеживается тренд на облачные вычисления. Не обошел он и нас стороной, и перед нами встала задача - разместить некоторые разрабатываемые службы в облаке. Естественно, перед публикакией, пусть даже и development, необходимо проверять результаты автоматических сборок.

0. На билд-машины был установлен VSCloudService из набора Azure SDK. Внутри каталога Windows Azure SDK находятся следущие файлы:

csrun.exe – непосредственно запускает эмулятор

\devstore\DSInit.exe – инициализирует локальное хранилище и выставляет права доступа для базы.

Для отработки тестов, надо предварительно инициализировать хранилище в локальном SQL Server на сборочной машине, а затем запустить Storage Emulator. Во многих форумах предлагается запускать их в методе AssemblyInitialize. Мы так и сделали.

На этом этапе мы столкнулись с проблемой, когда все тесты, требующие для своей работы StorageEmulator, отрабатывают локально, и благополучно валятся на сервере, выводя ошибку:

System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:10000

1. Естественно, начали грешить на закрытый порт. Открыли порт 10000 (именно он используется Storage Emulator’ом) на сборочных серверах для внутризонного подключения. Ошибки заменились другими:

Microsoft.WindowsAzure.StorageClient.StorageServerException: Server encountered an internal error. Please try again after some time. ---> System.Net.WebException: The remote server returned an error: (500)

Ну дела.

2. Поскольку удаленная отладка в данной ситуации – дело не самое простое, было решено проверить работоспособность компонентов отдельно. Оказалось, что добрые разработчики утилиты DSInit зачем-то сделали приложение оконным, что делает его запуст билдом невозможным, так как TFS Build работает в режиме сервиса, и UI-консоль ему не доступна.

Запускаем DSInit вручную для билд-аккаунта. Вот тут и выясняется основная ошибка – инициализатору не хватает прав сборочного аккаунта для выполнения операций настройки. Даем права sysadmin на SQL Server’е сборочной машины, запускаем – работает.

3. Самое замечательное. Правка Workflow-шаблона сборки проекта для запуска эмулятора.

В начале последовательности Try блока “Compile and Test” добавляем InvokeProcess параметрами:

FileName - "C:\Program Files\Windows Azure SDK\v1.3\bin\csrun.exe"

Arguments – “/devstore:start”

Сразу после рекомендуется поставить Delay в 5 секунд, чтобы эмулятор успел запуститься и выполнить все приготовления.

В последовательности Finally блока “Compile and Test” включаем тот же InvokeProcess, только с аргументом “/devstore:shutdown” для останова эмулятора.

Чекиним измененный BuildTemplate и теперь оно работает ;)

Продолжаю цикл постов про совместимость.

Я думаю, те, кто не первый год работает с Visual Studio знаю о том, что процессы сборки проектов из IDE и через утилиту msbuild при всей внешней схожести весьма различны.

В первую очередь это касается дополнительных надстроек Visual Studio – не всегда все работает корректно в обоих средах. И тот факт, что solution у вас собирается под Visual Studiо вовсе не гарантирует корректную сборку под MSBuild.

В частности, с этим сталкиваются пользователи Team Foundation Server. В TFS есть специальный компонент Team Foundation Build, который отвечает за автоматическую сборку исходников проекта на сервере. Выполняется он под MSBuild, который собирает проекты руководствуесь лишь ограниченным и достаточно простым набором правил.

DevEnv (Visual Studio) же собирает проекты в последовательности, определенной на нескольких источниках, таких как явные зависимости проектов и прописанные зависимости внутри файла solution.

Проблемы возникают, когда вы создаете нестандартный проект и ссылаетесь в нем на выход других проектов. Например, у нас это произошло с WIX, который создает инсталляционные пакеты. Под MSBuild проекты перестали собираться в нужной последовательности, в результате чего серверная сборка рухнула, а через IDE на всех машинах все прекрасно собиралось и работало.

Проблемы была локализована отнюдь не сразу. Впрочем, решение все-таки было найдено – в sln-файле по какой-то нелепой причине не были прописаны те самые зависимости проектов. Зависимости прописываются сразу после объявления проекта вверху файла:

Где DEPENDENCYPROJECTGUID и DEPENDENCYPROJECTGUID2 – GUID’ы проектов, от которых зависит проект SampleProject. После прописывания этих строк вручную, все стало собираться вновь без ошибок.

Надеюсь, вы потратили меньше времени на поиск решения, чем я ;)

Microsoft, как и все другие компании, старается совершенствовать свои продукты от версии к версии. Я очень часто работаю с Visual Studio, и считаю 2010 версию самой удобной на текущей момент средой разработки.

Для меня очень важно, чтобы проекты, разработка которых ведется как днями, так и ночами, всегда собирались. Чтобы всегда была работоспособная версия, которую можно продемонстрировать заказчику, а сам код проходил все необходимые тесты. В комплекте Team System есть компонент Team Foundation Build, 2008 версия которого была полностью построена на MSBuild - все действия и управление последовательностями и зависимостями выстраивались в набор Target-файлов, зачастую слабо документированных и уязвимых к ошибкам.

В версии 2010 Team Build'ом руководит уже Windows Workflow, правила и описания для которого хранятся в файле шаблона процесса - по умолчанию в корне дерева исходных кодов проекта в папке BuildProcessTemplates. Если открыть любой из XAML-файлов из этой директории, откроется редактор рабочих процессов:

И здесь вы вольны менять систему так, как вам заблагорассудится.

Это не попало в наш с Гавриловым курс по разработке программных систем в этом году, но, думаю, в следующем я включу полноценную лекцию по практикам Software Configuration Management и подробно рассмотрю вопросы по автоматизации построения различных кофигураций.

Кстати, если вы пользовались в Team Build 2008 параметром ConfigurationFolderRecursionType = full в конфигурационном файле сборочного сервера (это необходимо для того, чтобы при загрузке файлов описаний сервер загружал и все поддиректории), то теперь это прописывается прямо в Build Definition:

(Вкладка Process –> Build Process Paremeters –> 3. Advanced: Agent Settings)

Кто бы мог подумать ;)

DevTen, как ее называют внутри Майкрософт (по порядковому номеру версии - 10), будет официально "запущена" 12 апреля 2010 года (то есть уже меньше, чем через три месяца). Пока проходит обкатку Release Candidate.

Это значит, что в мае этого года факультет ждет как минимум еще одно глобальное мероприятие :)

А как много вкусного обещают в "десятке"! Мне, как человеку завязанному и на разработку, и на IT Pro-тематики, крайне интересны возможности командной разработки с помощью Team Foundation Server 2010, а уже во второй бете были реализованы те функции, которых так не хватало в девятой версии - например:

• разбивка проектов на коллекции с возможностью быстрой миграции с сервера на сервер
• распределение нагрузки
• управление лабораторией тестирования
• практически безграничные возможности по настройке автоматической сборки
• Visual C++ проекты собираются с помощью MSBuild - последняя теперь является по настоящему универсальной средой
• официально добавлен еще один язык программирования: F#

Вот такие рисунки образуются во время теологических споров – о дальнейшем развитии одного из проектов лаборатории:

(нажмите на картинку для увеличения)

Каждый мечтает о хорошей карьере. Но что делать, когда хочется ее совмещать с исследовательской деятельностью?

Ответ: стажировка и работа в MSR. Уже второй по счету сотрудник лаборатории, автор леденящего душу высказывания “птицы летят на нерест”, отправляется в Кэмбридж (Великобритания) гастарбайтером интерном. Его ждут интересные научные исследования, хороший соцпакет и высокая зарплата. Пожелаем ему удачи!

Завидно?

Попробуйте сами: Internship Opportunities @ MSR и England Lab Internship Program.

Доступна в MSDN, а соответственно, и в ELMS. Качайте :)

Материалы с семинара (презентацию) можно взять отсюда: CMC Live Services

Спасибо за внимание! Пишите :)

Майкрософт серьезно взялся за умы студентов. Теперь все подписчики MSDN, включая Academic Alliance, самыми первыми получают новые продукты Корпорации. Недавно на elms были загружены образы Windows 7 (и студенты ВМК одними из первых получили доступ к Beta и RC-выпускам новой ОС), а вместе с ней и Visual Studio 2010.

Если Windows 7 RC уже установлена почти на половине рабочих комьютеров лаборатории, то победное шествие VS10 только начинается. Однако, уже сейчас мы готовимся к закупке нового Team Foundation Server’а – слишком уж вкусный пирог приготовила Корпорация для всех любителей MSF, командной разработки и Application Lifecycle Management.

Подробнее о Team System 2010 я планирую рассказать сразу после сезона сессий, перед тем, как все разбегутся по отпускам. Пока же, вы можете почитать о ее возможностях на официальном сайте - http://msdn.microsoft.com/en-us/teamsystem/dd819231.aspx.

И, конечно, можете загрузить ее прямо сейчас – из центра загрузки Microsoft, либо из системы электронных лицензий ELMS.

[clickable]

С лабораторного конкурса логотипов на футболку "я сломал билд".

Если:

1. Active Directory домен живет под 2003 Mode
2. Подсоединенный к домену сервер работает под Windows Server 2008
3. Прописывать указанному в п.2 серверу явный dns-суффикс

То при попытке логина на машину (как с помощью локальной консоли, так и с помощью Terminal Services), вылезает ошибка:

“The security database on the server does not have a computer account for this workstation trust relationship.”

Так вот, знайте, надо убрать dns-суффикс.

Платформа удалась, как и операция “преемник”.

Напоминаю, что с 1 января 2009г. генеральным директором Microsoft Rus становится Николай Прянишников. И 4-5 декабря 2008-го случилась конференция “Платформа 2009”, на которой мне посчастливилось быть.

P.S. на фото участники MSTLab