Skip navigation links
Блог лаборатории
Eugene Nourminsky
Dmitry Grechka
DreamSpark Premium
Проекты
Digital Workbook
Dynamic Data Display
Live@EDU на ВМК
Космические проекты
Мероприятия
Курсы
Семинар «Технологии разработки и анализа программ»
О лаборатории
Обратная связь
Categories
Archive
Тестирование Azure-сервисов в TFS Build
Categories: Visual Studio, Windows Server 2008, SQL Server, TFS

Сейчас явно прослеживается тренд на облачные вычисления. Не обошел он и нас стороной, и перед нами встала задача - разместить некоторые разрабатываемые службы в облаке. Естественно, перед публикакией, пусть даже и 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 и теперь оно работает ;)

WSS + SQL Server 2008 на Windows Vista?
Categories: Vista, Visual Studio, SQL Server, SharePoint

Предыстория.

Любой разработчик под 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 под Вистой.

И, конечно, сам факт работы с системой безо всяких соединений не может не радовать: