|
3/04/2011Сейчас явно прослеживается тренд на облачные вычисления. Не обошел он и нас стороной, и перед нами встала задача - разместить некоторые разрабатываемые службы в облаке. Естественно, перед публикакией, пусть даже и 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 и теперь оно работает ;) 6/09/2010
Продолжаю цикл постов про совместимость.
Я думаю, те, кто не первый год работает с 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-файле по какой-то нелепой причине не были прописаны те самые зависимости проектов. Зависимости прописываются сразу после объявления проекта вверху файла:
Project("{SOMEGUID}") = "SampleProject", "SampleProject", "{SAMPLEPROJECTGUID}"
ProjectSection(ProjectDependencies) = postProject
{DEPENDENCYPROJECTGUID} = {DEPENDENCYPROJECTGUID}
{DEPENDENCYPROJECTGUID2} = {DEPENDENCYPROJECTGUID2}
EndProjectSection
Где DEPENDENCYPROJECTGUID и DEPENDENCYPROJECTGUID2 – GUID’ы проектов, от которых зависит проект SampleProject. После прописывания этих строк вручную, все стало собираться вновь без ошибок.
Надеюсь, вы потратили меньше времени на поиск решения, чем я ;) 6/08/2010
Если вдруг для серверной сборки проектов вы используете 64-битную машину, то при попытке собрать любое Silverlight-приложение у вас вылезет ошибка:
C:\Program Files (x86)\MSBuild\Microsoft\Silverlight\v3.0\Microsoft.Silverlight.Common.targets (101): The Silverlight 3 SDK is not installed.
Прямо скажем, малоинформативно, особенно учитывая тот факт, что Silverlight 3 SDK у вас наверняка есть (при наличии установленной Visual Studio 2010 на билд-сервере) и никакая переустановка/восстановление не поможет.
Ларчик открывается просто: по умолчанию на 64-битной машине платформа msbuild также x64, что совершенно несовместимо со сборкой Silverlight-проектов. Поэтому для корректного выполнения билда необходимо включить один маленький параметр в Build Definition - Process - 3. Advanced - MSBuild Platform = X86 как показано на картинке:
5/03/2010
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)
Кто бы мог подумать ;) 1/15/2010DevTen, как ее называют внутри Майкрософт (по порядковому номеру версии - 10), будет официально "запущена" 12 апреля 2010 года (то есть уже меньше, чем через три месяца). Пока проходит обкатку Release Candidate.
Это значит, что в мае этого года факультет ждет как минимум еще одно глобальное мероприятие :)
А как много вкусного обещают в "десятке"! Мне, как человеку завязанному и на разработку, и на IT Pro-тематики, крайне интересны возможности командной разработки с помощью Team Foundation Server 2010, а уже во второй бете были реализованы те функции, которых так не хватало в девятой версии - например:
- разбивка проектов на коллекции с возможностью быстрой миграции с сервера на сервер
- распределение нагрузки
- управление лабораторией тестирования
- практически безграничные возможности по настройке автоматической сборки
- Visual C++ проекты собираются с помощью MSBuild - последняя теперь является по настоящему универсальной средой
- официально добавлен еще один язык программирования: F#
12/07/2009
Вот такие рисунки образуются во время теологических споров – о дальнейшем развитии одного из проектов лаборатории:
(нажмите на картинку для увеличения)  10/23/2009
Подготовка к запуску Windows 7 идет полным ходом.
Освобождайте 20 ноября, у вас будет повод отдохнуть и узнать тонны полезной информации!
Кстати, если у вас есть пожелания по поводу запуска Win7 в частности, и мероприятий Microsoft в целом, можете прислать их нам. Контактная информация - тут.
Stay tuned! 10/21/2009
Если вдруг у вас возникло желание установить Silverlight 3 Tools на компьютер без интернета, то обычным переносом инсталлятора на машину и его запуском вы не отделаетесь.
Дело в том, что, как и большинство плагинов к VS, S3Tools устанавливается с помощью утилиты SPInstaller. Она достаточно простая в плане входных параметров, но, в то же время, достаточно сложная изнутри. Помимо этого, добрые создатели установочного пакета S3Tools обязали инсталлятор обязательно связываться с сервером при установке содержимого, проверять версию и чексуммы. Угадайте, во что это выливается при установке в оффлайн-режиме:
Правильно, ни во что хорошее. Причем, такое поведение инсталлятора не меняеся с первой версии. Глупость.
Например, у нас в лаборатории есть несколько билд-серверов, на которых необходимо поддерживать актуальный софт для автоматической сборки проектов. Сеть, в которой работают билд-сервера, “стерильна” и закрыта для доступа, а все результаты сборки выкладываются на промежуточный (staging) сервер. Здесь приходится ухищряться, но обычно, как и в данном случае, работает нижеописанный метод.
Если взглянуть на файл инсталлятора вооруженным взглядом, то все содержимое окажется как на ладони:
Из всего этого великолепия нам понадобятся либо комплект файлов для Visual Studio 2008:
- VS90SP1-KB967143-enu.msp
- silverlight_sdk.msi
- VS_SilverlightTools_Setup.exe
…либо комплект для Visual Web Developer 2008:
- VS90SP1-KB967144-enu.msp
- silverlight_sdk.msi
- VWDX_SilverlightTools_Setup.exe
Экспортируйте из инсталлятора эти файлы. Установив набор, соответствующий вашей системе разработки, и вы получите необходимый и достаточный набор для разработки Silverlight 3 приложений.
Да, и вам все еще понадобится Silverlight 3 Developer Runtime ;-) 10/13/2009
Каждый мечтает о хорошей карьере. Но что делать, когда хочется ее совмещать с исследовательской деятельностью?
Ответ: стажировка и работа в MSR. Уже второй по счету сотрудник лаборатории, автор леденящего душу высказывания “птицы летят на нерест”, отправляется в Кэмбридж (Великобритания) гастарбайтером интерном. Его ждут интересные научные исследования, хороший соцпакет и высокая зарплата. Пожелаем ему удачи!
Завидно?
Попробуйте сами: Internship Opportunities @ MSR и England Lab Internship Program. 10/12/2009
Доступна в MSDN, а соответственно, и в ELMS. Качайте :)
|