• Пишем документацию API при помощи RAML
    +1
    Учитывая что эти форматы чаще употребляются сриптами чем читаются человеком (зачем это читать если можно посмотреть что в UI нагенерили для каждого endpoint) то логичность синтаксиса — это вопрос второй.

    А вот коммунити — это наживается непросто. За RAML стоит одна компания, как и за API Blueprint. Swagger старается вовлечь сообщество в стандарт.

    Ну и набирает обороты он быстрее и дальше это будет только ускоряться, как снежный ком.
    Например и Microsoft (Azure API Management, API Apps) и Amazon ( AWS API Management import) используют Swagger, а не RAML или API Blueprint.

    Для RAML есть генераторы клиентов, как например AutoRest для .NET?
  • Доступно обновление для ReSharper Ultimate
    +1
    Хмм, вопрос к тем кто перешел — а у вас Esc тоже «поломан»? когда всплывают автокомплиты — окошки не всегда убираются по Escape, в одной из промежуточных бета-версий \ RC это починили, но в релизе опять вернулось, печально как-то…
  • Готовим ASP.NET5, выпуск №3 — внедрение зависимостей по-новому
    0
    Когда юнити зарелизили — продвигали довольно настойчиво, потом как-то поубавилось энтузиазизма. А EF это да, как и стандартные шаблоны — так много приходится выкорчевывать, что уже на автомате ищешь только Empty …
  • Готовим ASP.NET5, выпуск №3 — внедрение зависимостей по-новому
    0
    Даже не буду спорить, бесполезно. Для меня это выглядит как размывание аудитории. Вместо 14 конкурирующих контейнеров — у нас теперь будет 15, xkcd #927…

    У вас же была Unity, везде ее пихали, народ так ужаснулся что написали кучу приличных контейнеров, лишь бы не Unity. С EntityFramework — очень похожая история. Начиная с расцвета microORM и заканчивая тем, что похоже сама команда EF поняла что нахрен этот велосипед, давайте выпилим новый с нуля.

    Как прекрасно было когда вместо своего DataContractSerializer, MS взяла и задействовала Newtonsoft.Json.NET — в итоге это стандарт де-факто, прекрасная библиотека и легко найти ответы и куча примеров.

    Ну вот так, без сарказма, вы можете рассказать — а для чего нужен именно свой. Какая практическая долгосрочная цель у этого контейнера — что, МС будет в него вкладываться, создавать и поддерживать сообщество, допиливать фичи для лучшего покрытия edge-cases, исправлять сложные дедлок баги когда они полезут? Бюджет будет на контейнер дальше выделяться? не на asp.net а именно на конкретную вот эту область. Какие планы на дальнейшее развитие этого участка? Или это чтобы hello-world сэмплы было проще писать?
  • Готовим ASP.NET5, выпуск №3 — внедрение зависимостей по-новому
    0
    Ну это как — зачем тащить решарпер если студия тоже умеет рефакторить. Я понимаю любовь некоторых разработчиков к уютненькому «MS-из-коробки», была бы возможность — они бы и из студии не вылазили и пользовались только встроенными тулзами. Но таким способом вы же только стимулируете вендорлок подход и плодите разработчиков которые дальше MSDN в интернете не ходят…
  • Готовим ASP.NET5, выпуск №3 — внедрение зависимостей по-новому
    0
    А при наличии nuget, которым уже фреймворк можно по кускам собирать, это все еще аргумент? Просто есть прекрасные производительные контейнеры которые легко подключаются и удобно настраиваются — какой смысл брать «ис коропки»? Тут как-то возникает подозрение на рецидив любимого not invented here синдрома.
  • Использование Visual Studio Application Insights — опыт инженера по тестированию
    0
    Сценарий очень простой — есть Worker Role, помимо всего остального, внутри ее крутится OWIN self-hosted WebAPI. Этот webapi используется как в Angular так и в настольном приложении. Хочется с него собирать телеметрию которая специфична для web — время от начала запроса до first-byte-sent, корреляцию по пользователю — какие запросы от него приходят, как активно он ходит по сайту итд. Ну и видеть статистику по клиентам, браузерам, ОС (это для web запросов, для desktop еще не думали что хотим видеть, но как минимум версию приложения, скорей всего X-Version или что-то такое будем слать).
    В общем ничего невозможного нету, но есть одна загвоздка, как я понял — есть nuget package для всего что хостится на IIS — т.е. в виде HttpHandler, вроде есть не очень понятная бета версия для очередной беты asp.net 5, реализации в виде owin middleware ( для self-hosted и non-IIS серверов) — я не нашел и судя по вот этому ответу от сотрудника MSFT — не сильно планируется.

    Я понимаю что можно написать свою middleware в которой надо дергать AI напрямую, через TelemetryClient или если чуток получше — через serilog +serilog.AI sink. Но так можно логгировать куда угодно, и потом долго и мучительно настраивать диаграммы и чарты в каком-нибудь портале. Но тогда зачем грызть гранит AI.

    Value Application Insights для меня в том что это настроенная связка — клиент который знает что собирать для web запросов и сервер с уже настроенным набором стандартных диаграмм и correlation id. И вот пока не понятно, как задействовать это на полную катушку, а не как «тупой логгер». Может я что-то не понимаю и можно взять версию для ASP.NET 5 и вкрутить в OWIN pipeline? Вроде как сигнатуры middleware похожи, но все- таки отличаются немного (поправьте если я тут не прав, глубоко в asp.net vNext еще не смотрел)…
  • Использование Visual Studio Application Insights — опыт инженера по тестированию
    0
    А скажите, планируется ли поддержка AI в OWIN-Self Hosted сценариях. А то хочется чтобы была диагностика такая же как и для IIS, а не вручную вызывать API во всяких фильтрах. Даже для беты ASP.NET 5 уже есть, а для такого стабильного стека как OWIN — нету.
  • Как сделать красивую документацию для Web API, за которую будет не стыдно
    +5
    А вас не смущает что внешняя красивость достигается через кучу кастомных тегов и описаний в коде? Почему никто не думает о читабельности кода? тот же Swagger — просто стандартный формат описания, из него можно и документацию сгенерить красивую (генераторов статичного красивого html — завались) так и сгенерить автоматический прокси для вызова этого api в коде.

    Внизу уже упомянули что написание отдельной документации для каждого метода, помимо стандартной — утомляет. Это на самом деле — проблема в long-run. Когда проект только начинается — все радостно пишут документацию, когда ближе к окончанию, или даже через полгода — все уже начинают забивать на документацию. Хорошо еще если есть настрой написать стандартную доку, не говоря уже про специальную отдельную доку для генератора. В итоге — гладко было на бумаге…
    Мне больше импонирует подход swagger (вернее разных пакетов генерящих swagger описание по коду) — выяснить максимум о коде и представить это в виде стандартного описания. А уж пользователь-разработчик сам решит что ему генерить — красивую документацию или прокси или CRUD интерфейс.
  • Пишем Custom MSBuild Task для деплоя (WMI included)
    0
    А с версии 4.0 — можно писать вообще inline — msdn.microsoft.com/en-us/library/dd722601.aspx, мсбилд сам его скомпилирует и подключит в контекст скрипта.
    За примером можно сходить сюда.

  • Как работает API нашего IaaS-провайдера
    +1
    Это не совсем приложение, это довольно популярный формат описания api, который позволяет автоматически генерировать запросы в правильном формате. Посмотрите swagger.io
    Например на .NET для генерации интерфейса типа вот такого petstore.swagger.io к WebAPI нужно просто добавить пакет swashbuckle, и все.
    Для генерации клиента к чужому api который имеет описание в формате swagger — вызвать утилиту autorest с парой параметров — и она сгенерирует строго типизированные классы и методы на C#.

    Если пользовались раньше WSDL — это все то же самое только без SOAP & XML, и все кросс-платформенно для REST API

    Помимо этих плюшек, большое количество приложений и сервисов поддерживают Swagger, например PostMan, Runscope и другие…
  • Как работает API нашего IaaS-провайдера
    +1
    Мне кажется большинство таких постов уйдут в прошлое тогда, когда компании начнут использовать swagger для описания своих REST API. А из него и документацию можно сгенерить, и клиентов на разных языках, и просто фронтэнд чтобы поиграть с вызовами. Swagger это прекрасный аналог WSDL для RESTful api

    У вас есть?
  • Обмен сообщениями в Microsoft Azure, или Как общаться в облаках
    +1
    Ответ на ваш вопрос — если сообщение не помещается в 64Кб — стоит задуматься над архитектурой и тем что вам слишком много данных нужно передавать. Сообщение это больше команда — краткое указание. А по факту — сложите ваши большие данные в блоб и в сообщение засуньте ссылку по которой блоб можно скачать или его ID.

    И еще — 20 000 сообщений в секунду для очереди — это не опечатка? вот тут msdn.microsoft.com/library/azure/hh697709.aspx говорят только про 2000 сообщений в секунду на очередь, 20 000 это вроде предел на весь аккаунт…
  • Нью-Йорк — самый мусорный город на планете, а в Москве — одна из самых эффективных систем отопления
    0
    Не особо — трудно разделить отопление и остальное потребление. Можно было бы проследить и сравнить с летним периодом — но там опять же кондишен на охлаждение работает.
    А так если интересно — вот свежий счет

    Billing Period: 29-January-2015 — 03-May-2015
    1031 kWh — $285.08

    Семья из 3х человек, 2хбедрумная квартира ( т.е. 3 комнаты, зал совмещен с кухней)

    Довольно сильный скачок в апреле-мае на потребление, потому что стали включать кондиционер на обогрев.

    Изоляция тут в домах — да, гипсокартон и будки. Ну и строят они их как в 3х поросятах — сено и солома. Тепло выветривается быстро. Только пока своего дома нету — изменить ничего не получится в плане переделать и утеплить.
  • Нью-Йорк — самый мусорный город на планете, а в Москве — одна из самых эффективных систем отопления
    +6
    Это не негатив, это простое утверждение — массовое производство энергии\тепла всегда эффективнее индивидуального. Ну фабричные методы эффективнее же ремесленичества.

    Про носитель — верно подмечено. Но только вы почему-то не учитываете что газ тоже надо подводить, это тоже инфраструктура и она куда сложнее чем вода в трубах. Газовая система просто более эффективна в передаче «энергии» в определенной форме, с меньшими потерями. Правда куда опасней и сложней в обслуживании. И хорошо когда она уже построена. В мегаполисах она есть — отлично.
    Много в многоквартирных домах газового отопления или не разрешают, ибо опасно?

    Линии с электричеством — еще круче, много входных источников, проще в обслуживании, универсальный и безопасный формат. Вы же не будете утверждать что производство электричества тоже надо сводить к индивидуальным генераторам на солярке или угле…

    А на тему эффективности — думаю как-то просчитали общие затраты обогрев\электрификацию и поделили на население. Стало очевидно что котельные на мазуте и угле не эффективны, а старые ТЭЦ даже с их потерями тепла в трубах — дают фору многим новомодным веяниям. Гибкости меньше зато производство энергии на рубль затрат — выше. Даже включая стоимость инфраструктуры против массовой закупки домашних котлов и кондиционеров.

    Если так вопрос интересует как именно авторы считали — можно или почитать оригинальное исследование или написать авторам — вполне могут ответить.
  • Нью-Йорк — самый мусорный город на планете, а в Москве — одна из самых эффективных систем отопления
    +5
    Кстати вместо того чтобы спорить — достаточно привести цитату из самой статьи ( это даже не полное исследование):

    Moscow has built the largest district heating system in the world, providing combined heat and power to buildings housing 12 million people; this being more efficient that using separate systems for each building.


    Т.е. сами исследователи говорят — центральная система (даже такая старая и проблемная, построенная еще в СССР) более эффективна чем индивидуальные (которые динамичные и легче модернизируются).
  • Нью-Йорк — самый мусорный город на планете, а в Москве — одна из самых эффективных систем отопления
    +5
    Неужели, кто-то действительно серьёзно может говорить о том, что в США и Канаде что-то там не подсчитали и просто так выкидывают деньги на ветер?


    Неужели кто-то проживший дольше года в любой западной стране продолжает ее идеализировать и считать что вот они то самые умные и эффективные?
    Во всех странах есть свои особенности как государственной так и локальной политики, и поварившись немного в теме начинаешь замечать — В «А» это сделано лучше, а это хуже чем в «Б». Где-то нагло воруют бюджет, а где-то официально тратят его на перераздутые программы якобы улучшений. Где-то топят газом и теряют тепло при передаче, потому что инфраструктура плохая, а где-то топят мазутом и углем потому что это дешево и инфраструктура под это уже есть. А где-то законодательно запрещено муниципалитетом делать что-то, поэтому все вынуждены пользоваться более дорогими системами.
    А еще есть официально разрешенное лобби, и там вообще эффективностью не пахнет, только для вида…
  • Нью-Йорк — самый мусорный город на планете, а в Москве — одна из самых эффективных систем отопления
    +22
    Интересная статья, спасибо.
    Никто не говорит что чехи дураки, но опять же домовая система, которая является самой популярной в Чехии, это совсем не индивидуальная. Это централизация отопления но в масштабах дома, а не района.

    В итоге достигается экономия на потерях при передаче тепла от точки генерации к точке потребления, что есть классно и правильно (хотя современные методы изоляции тоже могут сократить эти потери). Все отличие этой системы от системы центрального отопления только в том, что у там нету больших ТЭЦ, которые выглядят страшно но вырабатывают самое дешевое тепло. И вместо котельных которые производят донагрев, там есть современные и автономные котельные в каждом дом которые производят полный нагрев. В итоге — платите больше за определенную долю гибкости. Если пойти дальше до этажных и индивидуальных систем — вы увидите ровно ту же тенденцию что я описал — чем более индивидуальные средства обогрева начинают использоваться — тем больше гибкость, но ниже энергоэффективность в пересчете на затраты.

    В индивидуальных домах может даже газа не быть (потому что газ это тоже инфраструктура), только электричество, тогда греемся маслянными\конвекционными обогревателями и кондеями. Любите тепло — получите счет в 1000 долларов за зимний период ( и это Мельбурн где средняя зимняя температура +13, в Чехии еще даже могут не включить обогрев в такую зиму, судя по статье). Тащить вот эту индивидуальную систему в мегаполисы где есть высотная застройка — глупо и экономически не выгодно.

    И да, не забывайте что централизованная система создавалась тогда, когда еще не было всей умной автоматики которая убережет котел от перегрева и взрыва, а массовые индивидуальные котлы — были из разряда фантастики. Взрыв котельной в соседнем дворе и в подвале вашего подъезда \на этаже — совсем разные вещи.
  • Нью-Йорк — самый мусорный город на планете, а в Москве — одна из самых эффективных систем отопления
    +38
    Знаете, индивидуальное отопление ни капельки не эффективно по сравнению с централизованным
    Оно имеет смысл и применяется на больших территориях просто потому что тянуть трубы к индивидуальному домохозяйству — не выгодно. Как и высокоскоростной интернет, например. В мегаполисах, с высокой концентрацией потребителей на квадратный километр, как раз выгодно делать централизованные услуги, потому как в этом случае есть доступ к оборудованию и технологиям промышленного качества.

    Централизованное и массовое производство тепла позволяет эффективнее распределять его излишки или создавать сложные схемы по пере-использованию тепла от промышленных производств.
    Все это недоступно для индивидуалов и все что можно реально сделать — выбрать чуть более эффективную модель кондиционера ( который все равно за 2-3 месяца может нагенерить счет на $1000 за электричество) или более дорогой но быстрее нагревающий комнату обогреватель.
    Это вся свобода выбора в вашей прославляемой индивидуальной системе. Достаточно даже школьной арифметики чтобы понять насколько она чудовищно неэффективна и должна применяться только выборочно, когда централизованная система недоступна ( индивидуальные участки, дома, отсутствие инфраструктуры).

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

    Вы же говорите откровенные глупости, не приводя аргументов и используете разжигание ненависти и оскорбления, как способ подтвердить свою точку зрения. Читайте меньше литературы пропагандистско-истерического толка и чаще применяйте ганглий между ушами.
  • Обзор ServiceStack.OrmLite — micro-ORM для .NET
    0
    От Object-Relational Mapper — да, мне необходим именно маппер, потому что все остальное оно делает хуже чем нативный интерфейс.
    Ну и удобный способ исполнять мои запросы на языке базы данных. А не универсальный комбайн-переводчик с свистоперделками. Уже все вроде наелись с EF и признались — создание суррогатных языков, пусть даже с автокомплитами и все такое — всегда генерит худший результат (и если смотрели в профайлере — сильно худший) чем обычный SQL, который lingua franca реляционных БД.
  • Обзор ServiceStack.OrmLite — micro-ORM для .NET
    +1
    Что то POCO ( plain old class objects) тут и не пахнет, все эти аттрибуты и navigation property засоряют модель. Пример работы с POCO — PetaPoco, берем любой класс и в него маппим результат SQL запроса. И не надо fluent городить — SQL для общения с базой — самый правильный и родной вариант.
  • Visual Studio Extensibility. Часть первая: MSBuild
    0
    Эти системы (я про fake &psake) направлены на другое — это просто обертка, которая прячет от вас функциональную часть сборки. Мсбилд — возможность заглянуть и понять что происходит под капотом. Просто не понимая что внутри — невозможно модифицировать систему чтобы она делала что нужно вам, всегда будут ритуальные пляски — а вот такой плагин добавим, а вот такой модуль, а еще их надо вызвать в строгом порядке, а между вызовами очистить вот эту папку. Это называется культ карго.

    Да, мсбилд использует не самый дружественный синтаксис, да, весь каскад импортов и переопределенных свойств может вызвать мигрень, да, половина таргетов для не основных продуктов написана криворукими идиотами, но понимание самой системы сборки дает вам знание о том, что происходит когда вы вызываете msbuild ./mylib.csproj. А также вы знаете как повлиять на это, в любой билд системе. И это кстати совсем не хардкор 8-)

    PS про TFS — ппкс, и спасибо за наводку, как то пропустил что появились детали 2015…
  • Visual Studio Extensibility. Часть первая: MSBuild
    –1
    А еще есть TFS — вообще гуй есть и можно в workflow в drag-and-drop стиле редактировать, не то что ваши тестикулярные скриптовые языки. Типа ура…

    Обычно, необходимость в скриптовых и императивных языках возникает когда в команде многие не способны ( в силу ограниченности кругозора) понимать XML мсбилда и его декларативность. Ну это в общем проблемы команды, а не мсбилда. Хоть на batch пишите, только все эти обвязки — как забивать гвозди микроскопом — от непонимания.
  • Visual Studio Extensibility. Часть первая: MSBuild
    +1
    Ок. т.е. получается в данном случае они не только используют свойства как способ хранения, но и используют такой же синтаксис? Или все-таки они заимствуют синтаксис из мсбилда, потому что само строковое значение будет интерпретироваться\разворачиваться не студией, а мсбилдом? Кто их разворачивает, эти «макросы»? Если второе — то все-таки это сущность билда, а не макрос студии.
  • Visual Studio Extensibility. Часть первая: MSBuild
    +1
    Классно, спасибо за пояснения, как работает мсбилд я знаю неплохо, а вот такие детали про проектные системы и их проекции на систему сборки — очень полезны.
    Кстати такой технический вопрос — можно ли убедить студию что ей нужно отрисовать содержимое файла Х как набор свойств проекта в GUI (т.е. убедить ее в том, что «проектная система — C#, но вот тут отрисуй пожалуйста используя другой компонент, из CPS» ), или это все жестко связано с расширениями и внутренними Guid? А то я сейчас покопался — и обнаружил что куда-то пропал графический редактор свойств в С#, похоже раньше это мне какое-то расширение делало… Не то что бы очень надо, просто любопытно, можно ли так обмануть систему…
  • Visual Studio Extensibility. Часть первая: MSBuild
    0
    и да, проект становится проектом «студии» если у него соответствующий ProjectGuid, а не невинные импорты
    <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
    <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
    
  • Visual Studio Extensibility. Часть первая: MSBuild
    +1
    То, что они где-то находятся в IDE — не определяет их предназначение. Вы такими выдуманными обозначениями запутаете читателей еще больше, а потом опять будем видеть жалобы на то, что кто-то потратил уйму времени (как автор) просматривая targets мсбилда и все равно ничего не понял.

    Да, статью я читал. На соглашения я указал потому, что если им следовать — можно получить некоторые встроенные в msbuild(и поставляемые targets) ништяки. Если не следовать — можно сделать все то же самое, но руками и через «мучения».
  • Visual Studio Extensibility. Часть первая: MSBuild
    +2
    $(BlaBlaBla) — это не макрос, это способ адресации Свойства (Property) в MSBuild.

    Вообще все остальное, включая ваши наборы свойств выглядит как мало относящееся к MSBuild. Props и Targets это просто «соглашения», можете именовать как угодно, но студия любит их и например может дать возможность редактировать ваши собственные props в окне свойств проекта.

    int19h А в чем отличия этой Common Project System от стандартной системы сборки проектов в MSBuild? И почему декларативное описание свойств не будет работать? Мсбилд всегда так работает, ну или я не правильно понимаю ваше высказывание.
  • Entity Framework: повышаем производительность при сохранении данных в БД
    0
    Поддержу предыдущего комментатора, по работе вынужден сталкиваться с EF, даже 6тая версия — какие-то наборы архитектурных костылей. Когда была возможность выбирать — использовал PetaPoco и Даппер — ничуть не жалею. Вообще громоздить абстракцию поверх и так уже абстрактного языка SQL — это коряво. А все эти трекинги объектов и контексты — ну не знаю, для меня это издевательство и переусложнение простой задачи — прочитать данные или записать данные. SQL надо знать и надо им пользоваться, а не придумывать велосипеды чтобы его избежать. А аргументы про то как легко сменить базу данных когда у вас есть абстракция — вот честно, кто хоть раз на больших проектах менял базы данных ???
  • Запись вебинара: Файловая система ReFS в Windows Server 2012/R2 и её будущее в vNext
    0
    Хмм, ограничение на полное имя файла все также 256 символов. Печально, ждем следующую версию.
  • Самый большой кубик Рубика в мире: на решение головоломки требуется 7,5 часов
    +1
    Глупость комментария удалена
  • Здания, которые не получилось бы построить без компьютерных технологий
    +1
    Хмм, Сиднейская Опера начали строить задолго до появления приемлемых компьютеров, И закончили в 1973.
    Wiki
    Причем тут помощь CAD вообще?
  • Продвинутый вирус следил за компьютерами с 2008 года
    +4
    так и ShellShock и HeartBleed показали что не работает мантра про открытый код= безопасный и много глаз = меньше багов.

    Единственное утверждение, которое пока прошло проверку временем — «если на вашей платформе нету вирусов — это означает что в масштабах ботнета вы статистически незаметны, т.е. неинтересны».
  • Алгоритм быстрой посадки на самолёт
    0
    Схема холостяка или диванного теоретика.
    Если летаешь один — мб она и оптимальна, но тогда весь самолет должен состоять из одиночек. А если летишь с семьей или с группой, ну или сопровождаешь кого-то, кому нужна помощь — эта схема сбоит сильно — до серьезных скандалов.Ну например — на местах 5 и 25 летит ребенок с ДЦП и сопровождающая его мать. И что вы посадите ребенка одного, чтобы он еще сумку закинул наверх?
  • Jump Start в PowerShell (часть II)
    +1
    Для JumpStart будет очень полезно, если вы расскажете в подробностях про Pipeline PoSH, ибо очень важная и большая часть.
    И как это все интегрированно с .NET тоже полезно знать (но это уже не совсем фундаментальные основы).

    Продолжайте, неплохие материалы в итоге получатся.
  • Jump Start в PowerShell (часть II)
    +1
    ну не то что бы совсем экспертом, можно вполне не программировать под .NET, но успешно пользоваться PoSH. Хотя не отрицаю — знание .NET хорошо помогает, ибо по сути это скриптовый язык для .NET =)
  • Подробное описание возможностей разработки с Microsoft Azure Cloud Services
    +1
    Откуда ж вы, в Microsoft, копируете эту несусветную глупость про то, что Staging окружение надо использовать для тестирования ??? У вас там что где-то есть список официально распространяемых неработающих и идиотских практик?

    НЕ используйте staging для тестов, это не только физически «трудно» в силу таких очевидных косяков как отсутствие правильных bindings на сайтах в staging — ваши сайты в staging получают те же bindings что и продакшен, а реальный домен — guid.cloudapp.net, т.е. если у вас binding не *:80\443 — без шаманских плясок вы не достучитесь до своих сайтов в staging слоте.

    И заканчивая тем, что при активном стейджинге он у вас будет таскать сообщения из очереди, «тестовый» слот будет писать в продакшен базу, блобы и таблицы. А если вы используете миграции Entity Framework (отдельные грабли) — еще и получите измененую Production базу и с большой вероятностью — P1 Incident в придачу.

    Забудьте вы про тестирование в Staging пожалуйста, Staging предназначен для уменьшения времени простоя и гладкого обновления — загрузили новую, оттестированную версию в стейджинг, прогрели, убедились что все инстансы запустились и работают как надо — переключили ее в продакшен, старую остановили.

    За все остальные варианты использования Staging — бейте своих разработчиков по рукам стальной линейкой, чтобы неповадно было.

    А Microsoft должно быть стыдно, что пишете такие практики.

    И еще маленькое имхо — думаю что Cloud Services будут выводиться из обращения — во первых на смену им пришли легковесные websites+webjobs, во-вторых грядет Docker — куда более правильная идея контейнерных приложений.
  • Ультра-легкий переключатель раскладки клавиатуры
    +1
    Так было раньше. И даже это не совсем так — студия все равно загружала в себя движок мсбилда и прогоняла все через его пайплайн, за исключением пары проектов (которые уже морально устарели имхо). Т.е. тогда было 2 хоста для движка — студия и msbuild.exe. Это приводило к тому, что окружение проектов отличалось — студия подсовывала кучу переменных окружения.

    Но сейчас это не так — студия, по крайней мере современные ее версии, собирает проекты при помощи честного msbuild.exe, причем можно увидеть отдельные параллельные процессы msbuild.exe запущенные студией с определенными параметрами.

    Да, солюшен это не мсбилд скрипт, но его преобразование происходит в msbuild.exe, а не в devenv.exe

    В итоге — всё собирается одним и тем же движком, просто вызывается(лся) этот движок из разных врапперов — msbuild.exe и devenv.exe. Теперь один враппер вызывает другой, вместо того чтобы хостить Core engine в себе. Это и есть принципиальная разница?

    PS: Господа минусующие, зачем портите дискуссию?
  • Ультра-легкий переключатель раскладки клавиатуры
    –1
    Вообще не такие уж и разные.
    За исключением нескольких проектов, студия для сборки не нужна, но возможно не все разработчики это знают.
  • Ультра-легкий переключатель раскладки клавиатуры
    +1
    А собрать мсбилдом из консольки не позволяют убеждения?