|
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. После прописывания этих строк вручную, все стало собираться вновь без ошибок.
Надеюсь, вы потратили меньше времени на поиск решения, чем я ;) 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#
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 ;-) 11/03/2008
Предыстория.
Любой разработчик под SharePoint рано или поздно сталкивается с тем, что необходимо либо заводить виртуальную машину с системой WSS, либо проводить тестовое развертывание на специальных серверах организации. Эспериментаторов на production-серверах в расчет не берем, хотя и такие встречаются :) .
К сожалению, главные компоненты для разработки собственных приложений для платформы SharePoint требуют наличие самой платформы на девелоперской машине, то есть как мимимум установки Web-сервера IIS и Windows SharePoint Services (WSS), плюс база данных (SQL Server, конечно же). Но как быть, если не хочется ставить Windows Server, и отвыкать от уже “родной” Висты?
Дебют
Задача – разрабатывать решения для Microsoft SharePoint прямо из Windows Vista без использования дополнительных систем в виде виртуальных или удаленных машин. Пускай у такой схемы есть недостатки – в виде захламление рабочей памяти, например, но удобство развертывания и возможности отладки на локальной машине (надо было ставить Windows Checked/Debug version для полноты ощущений), по-моему, перебивают все возможные недостатки.
Да, пускай не все признали 6-ую версию Windows в качестве подходящей операционной системы (те же студенты ВМК, например, за первые два месяца текущего семестра по программе MSDNAA заказали “всего” 61 дистрибутив различных версий Windows Vista против 84 дистрибутивов Windows XP), но ставить Windows Server 2003/2008 на рабочую машину также осмеливаются немногие энтузиасты (пользуясь случаем, передаю привет одному такому “энтузиасту” Андрею Адинцу), а сами SharePoint Services упорно не хотят устанавливаться на что-нибудь отличное от заявленных в поддержке ОС, в кои, по удачному стечению обстоятельств, Vista как раз и не входит.
WSS, в свою очередь, входит в список требуемого программного обеспечения для Windows SharePoint Services Extensions for Visual Studio 2008 (VSeWSS 1.2), которые, в свою очередь, являются необходимой каждому SharePoint-разработчику расширениями к Visual Studio.
Кроме того, я решил усложнить задачу, и в качестве системы баз данных поставить SQL Server 2008 Express – самую свежую версию бесплатно распространяемой СУБД от Microsoft. В ней появилось много вкусняшек – о них я расскажу на одном из тренингов лаборатории. Сам установщик заметно изменился, и несколько усложнился. Впрочем, этим страдали практически все масштабные софтверные проекты, но здесь все основные действия по установке и настройке стали более наглядны и разложены по шагам.
Миттельшпиль
С последним пунктом, к счастью, проблем не было. С совместимостью WSS (с предустановленным Service Pack 1) никаких проблем не возникло – сказалась заявленная совместимость версий. На Windows Vista SQL Server 2008 установливается вообще без каких бы то ни было проблем.
Дальше. Предстояло убедить инсталлятор WSS в том, что он запускается под “серверной” операционной системой. Естественно, никакие compatibility mode’ы тут не помогают, и надо искать обходные пути – например, прямо подсказывать что и где смотреть. С этой задачей до нас справились разработчики из Bamboo Solutions – попросту создали специальный инсталлятор-помощник, который запускает установщик WSS (линк - http://community.bamboosolutions.com/media/p/193.aspx).
Джим Паршел сделал специальное видео, в котором подробно расписывает все шаги, необходимые для установки WSS - http://ninjamurai.com/blog/2008/08/21/install-sharepoint-on-vista/. Несмотря на приличный размер данного видеоролика, рекомендую в качестве руководства использовать именно его. Если же интернет-соединение не позволяет закачать 140 мегабайтный видеофайл, то текстовая инструкция доступна здесь.
Эндшпиль
Спустя примерно полчаса-час при наличии всех компонентов (и в зависимости от быстродействия компьютера), система будет готова для использования.
Конечно, после установки возникнут определенные неудобства. Как то: придется либо терпеть работающие сервисы SQL и WSS на локально машине (если вы разрабатываете Web-приложение, или у вас просто много памяти на компьютере – это оправданно), либо настроить быстрый запуск и остановку этих сервисов по команде (об этом также в отдельном посте моего блога). Также, при работе с Central Administration необходимо запускать Internet Explorer с правами администратора. Есть еще ряд мелких проблем, но все они разрешимы. Те же ребята из Bamboo Solutions организовали отдельный форум для работы c WSS под Вистой.
И, конечно, сам факт работы с системой безо всяких соединений не может не радовать:
|