К сожалению, у меня сечас нет времени перевести статью, так что читайте в оригинале – Automated Build and Deployment with Windows Azure SDK 1.6.

К слову сказать, я уже давно пользуюсь. Мне нравится.

Профилирование приложений, работающих в Azure

Шаблоны для создания MVC 3 ролей

Поддержка нескольких конфигураций для одного облачного проекта (мой фаворит)

Улучшенная валидация пакетов во время сборки

Также стало доступным контекстное меню по нажатию правой кнопки мыши:

Портал стал быстрее и активно использует кэширование для уменьшения времени загрузки и снижения потребления сетевого трафика. При первой загрузке он предложит пользователю увиличить лимит локального изолированного хранилища:

Улучшена функциональность по удалению развёрнутых служб – теперь Вы можете удалить запущенную службу, не дожидаясь её остановки.

Единственное замечание к новому порталу – при первом запуске он у меня подвис на этапе загрузки. Видимо, это произошло из-за конфликта с предыдущей версией. Мне пришлось вослользоваться IE9 developer tools (F12), для того, чтобы почистить кэш только для этого домена (Ctrl-D).

• Инструменты Windows Azure для Microsoft Visual Studio 1.2 (июнь 2010)

Но, хочется отметить интересный факт. Поводом для выпуска этой версии послужило, как мне кажется, 2 события – поддержка Windows Azure Drive и Visual Studio 2010 RC.

Да, да, Вы прочитали правильно – именно Release Candidate. “Но ведь его ещё нет!” – заметит внимательный читатель. Именно это меня приятно поразило. Дело в том, что между Beta 2 и RC произошли незначительные изменения внутреннего API IDE. В связи с этим, очень многие расширения требуют перекомпиляции с новым VS 2010 SDK, иначе они просто не смогут работать. Думаю впервые у нас появится возможность использовать RC сразу, а не дожидаться обновлённого инструментария. Приятная новость, согласитесь!

Кстати, версия Windows Installer XML или WiX поддерживающая Visual Studio 2010 RC уже вышла (не без участия Вашего покорного слуги).

По сути, это API и примеры использования облачного сервиса Microsoft, который позиционируется как удобное средство для Web приложения (и для Azure Service в том числе) общаться с большим количеством удалённых клиентов. В качестве протокола предлагается, в том числе и HHTP/HTTPS. Очень полезной особенностью данного решения является прозрачность для proxy/firewall и возможность “вещания” (broadcast). Очень рекомендую обратить внимание.

Скачать SDK можно тут Windows Azure platform AppFabric SDK V1.0. Более подробно о технологии можно узнать на сайте Microsoft Windows Azure platform AppFabric Development Center.

Дело в том, что при сборке Team Build перенаправляет весь output в один фолдер для всех проектах в solution. При этом, от каждого Azure проекта там должно оказаться две сущности – фолдер <azure_project_name>.cxx и файл .cscfg из проекта, т.е. ServiceConfiguration.cscfg. Вполне очевидно, что в общеем фолдере окажется этот файл только от того Azure проекта, который собирался последним. Остальные будут перезаписаны.

Что делать? Ответ очевиден – дать файлу ServiceConfiguration.cscfg уникалное имя, например – <azure_project_name>Configuration.cscfg. К сожалению, сделать это просто нажав клавишу F2 в IDE не получится, если Ваш проект лежит в Source Control – в версии Beta 2 у IDE будут проблемы с этим. Так что самый простой способ:

1. Выгрузить проект или закрыть solution.
2. переименовать файл:
   ServiceConfiguration.cscfg
   в
   <your_new_name>.cscfg
3. Открыть файл проекта в редакторе и исправить:
   <ServiceConfiguration Include="ServiceConfiguration.cscfg" />
   на
   <ServiceConfiguration Include="<your_new_name>.cscfg" />