Эволюция веб-фреймворков Microsoft. ASP.NET vNext



    Предпосылки к переменам


    Новость о выходе ASP.NET vNext в сети распространилась достаточно быстро вместе с анонсом наиболее интересных новшеств, предложенных в обновлении. ASP.NET MVC 6 получил новое имя и позиционируется как что-то действительно новое в среде web фреймворков Microsoft (MS). Для того чтобы наиболее полно можно было понимать важность заявленных изменений vNext, вспомним особенности текущей реализации веб приложений на платформе .NET.

    Типичное ASP.NET MVC приложение состоит из Global.asax файла, в котором мы расширяем класс HttpApplication (System.Web) и таким образом добавляем желаемое поведение обработки Http запросов путем конфигурирования отдельных составляющих компонентов MVC. В классическом ASP.NET MVC класс Router (System.Web.Routing) является неотъемлемым звеном обработки Http запросов, путем перенаправления их на нужный HttpHandler – в стандартном поведении (MvcRouteHandler) который создает фабрику контроллеров и запускает дальнейший pipe обработки запросов. Эти компоненты являются заведомо тесно привязанными к веб-серверу от MS – Internet Information Services (IIS), использующий HttpHandlers и HttpContext (доступ к параметрам http запроса/ответа) для обработки запросов. Полученное в наследие от ASP.NET Web Forms повсеместное применение этих компонентов в MVC предполагало тесную интеграцию с IIS, что сделало невозможным использование альтернативного веб-сервера для хостинга приложений. Эти обстоятельства с течением времени вызывали все больше критики со стороны сообщества разработчиков и являлись действительно не очень благоприятным фактором развития ASP.NET MVC, который будучи Open source проектом развивается куда быстрее чем Microsoft разрабатывает обновления для компонентов System.Web.



    Попытка исправить ситуацию была предпринята в рамках развития проекта Web Api. Во время миграции с фреймворка MS WCF разработчики отказались от подхода к построению RESTful сервисов на базе концепции «привязок-контрактов», в пользу более удобному MVC, что предопределило много общего и созвучное название — ASP.NET Web Api. На самом же деле разработчики нового фреймворка смогли сделать его с оглядкой на описанные выше недостатки ASP.NET MVC. В Web Api не использовали этих самых компонентов System.Web напрямую благодаря адаптерам для HttpContext.Request, HttpContext.Response – абстракциям c обновленной структурой HttpRequestMessage, HttpResponseMessage, в которые HttpControllerHandler (точка входа в Web Api приложение) производил преобразование указанных объектов. Так же была устранена и зависимость от HttpHandler’ов IIS, путем обработки запросов через цепочку вложенных друг в друга HttpMessageHandlers (System.Net.Http), на базе которых и был реализован обновленный стек (filters, dispatchers, delegating handlers, controllers).



    Все эти изменения позволили сделать Web Api приложение независимым от хоста и развивать в рамках OWIN (Open Web Interface) спецификации. Ключевым стало понятие middleware – компоненты веб приложения (в IIS – HttpModules) и application delegate, который вместо HttpContext, взаимодействует с куда более абстрактным набором параметров запроса/ответа в хеш-мапе вида IDictionary<string,object>.



    Несмотря на все преимущества, гибкость, улучшенную расширяемость и целый ряд исправлений архитектурных недостатков Web Api все же не мог стать полноценной заменой MVС будучи ориентированным на Single Page Applications(SPA). В то же время один фреймворк ничем не мешал другому. Более того, они отлично уживались рядом в одном веб-приложении в случае использования IIS для их хостинга и даже могли использовать общие Http модули, например, для аутентификации. Тем не менее рассмотренный подход требовал четкого разделения ответственности в приложении и учета особенности, что все-таки Web Api и Mvc используют совершенно различный pipeline для обработки запросов. Последнее добавляло другого рода сложностей разработчикам и предполагало последующий рефакторинг в новой версии фреймворка, который и получил название vNext.

    Шаблон проекта ASP.NET vNext


    Первое, что бросается в глаза в новом веб-приложении — отсутствие файлов конфигурации web.config, packages.config и даже AssemblyInfo.cs.



    В структуре решения имеем только два файла:
    • project.json – файл конфигурации для проекта, где находятся зависимости с указанием версий подключаемых сборок, параметры компиляции проекта, метаданные, перечень зависимостей для развертывания в режимах .NET и Core CLR.
    • Startup.cs – входная точка, класс веб-приложения.

    Сейчас заглянув в свойства проекта VS мы не увидим того изобилия опций, которыми прежде были снабжены проекты ASP.NET. Всего доступны две вкладки: General – конфигурация пространства имен и типа приложения при построении; на вкладке Debugging – номер порта, на котором будет доступно наше приложение.
    Далее интересней, собственно файл конфигурации project.json проекта. Выглядит он приблизительно следующим образом.



    Первичный набор предусматривает наличие всего двух ключей.
    • dependencies – указание зависимостей для проекта получаемых из сборок, NuGet Packages и даже исходников на диске;
    • configurations – перечень зависимостей при построении проекта для конкретной целевой среды: .NET или Core CLR.

    Столь кардинальные изменения в структуре проекта обусловлены использованием нового компилятора Roslyn, который позволяет в runtime компилировать исходный код в IL и выполнять его. Возможности Roslyn легли в основу и новой среды выполнения K Language Runtime (KLR). На данный момент для нее предусмотрено две опции запуска проекта в режиме .NET Desktop, либо — Core CLR (в alpha версии режим доступен только в KLR из под Win 8). Собрать проект можно так же используя K Versions Manager (KVM)/K Packages Manager (KPM) — консольные утилиты поставляемые с K, что позволяют самостоятельно управлять установленным версиями KRE(K Runtime Engine), распаковывать приложения на основании project.json и запускать их. Для более детальной информации стоит ознакомиться с ресурсом github.com/aspnet/home.

    Структура веб-приложения ASP.NET vNext


    Единственный файл исходного кода в проекте — Startup.cs, содержит ссылку на пространство имен Microsoft.AspNet.Builder и класс, структурой схожей с OWIN based приложениям. В нем один метод — Configure с входным параметром типа IBuilder. Проект компилируется и запускается, но ничего не возвращает в качестве ответа (а точнее возвращает «403-ий», поскольку IIS не находя обработчика запроса пытается получить доступ к файловой системе), что логично, поскольку мы не добавили никакого middleware.



    На www.asp.net/vnext нам предлагают вызвать статический extension метод (UseWelcomePage), чтобы добавить простейший Request Handler, но он нам мало интересен, так как скрывает всю специфику работы интерфейса IBuilder. Попробуем «копнуть» глубже взглянув на его определение:

    using System;
    namespace Microsoft.AspNet.Builder
    {
        public interface IBuilder
        {
            IServiceProvider ApplicationServices { get; set; }
            IServerInformation Server { get; set; }
    
            RequestDelegate Build();
            IBuilder New();
            IBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);
        }
    }
    


    Для того что бы сориентироваться в коде, необходимо вспомнить, что понятие middleware в OWIN напрямую относиться к Application Delegate, который получает перечень параметров Http запроса и выполняет над ним какое-то преобразование, возвращая Task.

    Func<IDictionary<string, object>, Task>
    


    Для OWIN мы также имели статический Extensions method на уровне интерфейса IAppBuilder, который позволял добавлять middleware используя более удобную структурированную версию контекста — IOwinContext. В vNext он немного преобразился, поскольку подразумевает работу с HttpContext напрямую. Последний теперь находится в пространстве имен Microsoft.AspNet.Http, и не имеет ничего общего с HttpContext из System.Web, как это было в случае с оберткой HttpContextBase в ASP.NET MVC:

    public delegate Task RequestDelegate(HttpContext context);
    


    Таким образом все понемногу становится на свои места — RequestDelegate в vNext и есть тем самым OWIN Application Delegate’ом.
    Для добавления нового middleware в оригинальной реализации метода Use мы передаем generic делегат, содержащий в качестве параметра вложенный делегат типа RequestDelegate. Внешний Generic делегат ссылается на весь дальнейший pipeline обработки http запроса, RequestDelegate – выполняет работу Http Handler’a.
    Попробуем взглянуть на пример с добавлением модулей — это должно немного прояснить ситуацию.

    public void Configure(IBuilder app)
            {                               
                app.Use(next =>
                      httpContext =>
                            httpContext.Response.WriteAsync("Executed before all  followers." + Environment.NewLine)
                            .ContinueWith(task => next(httpContext)));
    
                app.Use(next =>
                  httpContext =>
                    next(httpContext)
                        .ContinueWith(task => 
                            httpContext.Response.WriteAsync("Executed after all followers." + Environment.NewLine)));
    
    
                app.Use((httpContext, next) => httpContext.Response.WriteAsync("Hello world middleware." + Environment.NewLine));
    
            }
    


    Как видим, при конфигурации middleware мы имеем поведение во многом схожее с Delegating Handlers Web Api, где мы можем гибко контролировать последовательность выполнения из текущего модуля всего дальнейшего pipeline (параметр next). Достаточно просто добавить обработку Http запроса внутри лямбда-выражений передаваемых в Use.



    Что же касается непосредственно OWIN, vNext является полностью совместимым с данным интерфейсом. В пространстве имен Microsoft.AspNet.Builder находится класс статических методов расширений для IBuilder, которые создают адаптеры перехода от Owin Application Delegate к vNext RequestDelegate.

    using AddMiddleware = Action<Func<Func<IDictionary<string, object>, Task>,  Func<IDictionary<string, object>, Task>>>;
    
            public static AddMiddleware UseOwin(this IBuilder builder)
            {
              ....
            }
    


    В своем приложении мы можем использовать AddMiddleware для взаимодействия между OWIN Environment dictionary и vNext HttpContext, полагаясь на внутреннею реализацию платформы. Расширение позволит достаточно легко использовать OWIN-компоненты в новой версии фреймворка.

    Из важных особенностей стоит отметить, что в отличие от OWIN AppBuilder’a, vNext IBuilder интерфейс содержит и встроенный сервис-локатор ApplicationServices инициализируемый приложением веб-сервером. В данном свойстве предоставляется доступ Web Host Application Level Services.

    vNext HttpContext


    Со структурой приложения немного разобрались, что же представляет из себя обновленный vNext HttpContext. Как и ожидалось, сам класс контекста, Request и Response объявлены абстрактными. HttpContext в реализации поставляемого «из кробки» хоста Microsoft.AspNet.Hosting инстанцируется объектом DefaultHttpContext перед каждым вызовом цепочки middleware. Контекст имеет метод Abort, реализует интерфейс IDisposable и предоставляет два сервис локатора ApplicationServices и RequestServices с соответствующим жизненным циклом контейнеров, что явно говорит в пользу более удобного формирования Structure Map на уровне приложения по сравнению с предыдущими версиями ASP.NET MVC.

    В vNext добавлен новый механизм расширяемости контекста путем использования HttpFeatures. На уровне интерфейса контекста он предусматривает два набора методов для получения и добавления расширений (через запаковку в object и generic wrapper):

          public abstract object GetFeature(Type type);
    
            public abstract void SetFeature(Type type, object instance);
    
            public virtual T GetFeature<T>()
            {
                return (T)GetFeature(typeof(T));
            }
    
            public virtual void SetFeature<T>(T instance)
            {
                SetFeature(typeof(T), instance);
            }
    


    В обновленной версии ASP.NET данный подход применяется для динамического формирования контекста начиная от первого обращения к HttpContext, где инициализируются Host Application/Server Specific Features и вплоть до уровня использования отдельными middleware компонентами параметров запроса, аутентификации, кеширования, работы с веб-сокетами. В базовой реализации Request практически полностью использует интерфейсы, определенные в Microsoft.AspNet.Builder, для получения составляющих именно из HttpFeatures. Формирование контекста таким образом позволяет скрывать за конкретным интерфейсом отдельного компонента специфическую для веб-сервера реализацию функциональности на уровне хоста не ограничиваясь базовой структурой HttpContex.

    vNext MVC


    Наиболее ожидаемым нововведением с точки зрения построения самого веб-приложения безусловно есть объединение функциональности ASP.NET MVC и Web Api в рамках одного фреймворка, что позволит использовать общий pipeline для обработки Http запросов.

    Добавление поведения MVC в vNext предполагает подключение и конфигурацию двух модулей middleware:
    • vNext Dependency Resolver с перечнем сервисов формирующих стек vNext MVC.
    • Router middleware — модуль MVC роутера.


        public void Configure(IBuilder app)
            {
                app.UseServices(services => services.AddMvc());
    
                app.UseMvc(router =>
                    router.MapRoute("DefaultHome", 
                    "{controller}/{action}/{id?}", 
                    defaults: new { Controller = "Home", Action = "Index" }));
            }
    


    Первый из них — набор сервисов, предоставляющий реализацию стандартных MVC компонентов и используемый на протяжении всего pipeline для обработки запроса на уровне отдельных абстракций. Речь идет о поставщиках Action контекста, фабрики контроллеров, привязки модели, предоставления View Engine и т.д. Описание сервисов с маппингами DI доступно для ознакомления в классе Microsoft.AspNet.Mvc.MvcServices.cs.

    Второй — RouterHandler, который представлен в vNext интерфейсом IRouter с асинхронным методом RouteAsync:

      public interface IRouter
      {
            Task RouteAsync(RouteContext context);
    
            string GetVirtualPath(VirtualPathContext context);
      }
    
    


    По умолчанию интерфейс реализует класс MvcRouteHandler. В отличии от предыдущих версий роутинга основанных на специфической для фреймворка функциональности (в MVC – HttpHandler, Web Api – DelegatingHandler), в этот раз в нем предусмотрен только вызов отдельных методов интерфейсов полученных из сервис локатора с набором компонентов MVC. Именно этот класс получает ActionContext и запускает дальнейший pipeline обработки запроса, используя IActionInvoker сервис в связке с ControllerFactory. Основное преимущество от применения такого подхода очевидно, он предоставляет необходимую универсальность для слияния фреймворков, которая отсутствовала прежде.

    Еще одним положительным изменением в новой редакции MVC стал полностью асинхронный режим выполнения методов сервисов. Подобным образом был реализован pipe в Web Api и позволил полностью вынести из рабочего пула потока веб-сервера операции связанные с ожиданием ресурсов. MVC до текущего момента предусматривал «из коробки» только асинхронные контроллеры.

    За основную рабочую единицу обработки Http запроса в vNext был взят Controller из MVC. Для пост-процессинга и сериализации результатов выполнения действий используется интерфейс IActionResult. Функционал MVC в этом отношении концептуально остался прежним. Что же касается основных расширений, хорошо зарекомендовавших себя в Web Api, то они на данный момент не были добавлены в pipeline vNext. Как например механизм определения форматера путем использования Content Negotiation сервисов. В случае возвращения экземпляра класса не реализующего IActionResult из действия контроллера используется JSON-форматер.

    Механизм конфигурации приложения был сильно модифицирован в связи с переходом на обновленный шаблон проекта. Теперь вместо прежнего web.config применяется config.json, представляющий иерархическую структуру пар ключ-значение.



    Непосредственно на уровне кода, предоставлен набор утилит из пространством имен Microsoft.Framework.ConfigurationModel, производящий слияние ключей из различных источников конфигурации, например, параметров запуска приложения-хоста, переданных в консоли K; пар определенных в файлах project.json, config.json веб-приложения.

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

    Итоги


    После ознакомления с alpha версией ASP.NET MVC vNext можно действительно говорить, что перемены разработчиков ожидают достаточно кардинальные. Cвязанные они не только с основательным рефакторингом ASP.NET, но и с адаптацией фреймворка под обновленный Runtime.

    На уровне приложения изменение внутренних концепций достаточно ограниченное и будет интуитивно понятным для разработчиков, имевших дело с OWIN и предыдущими версиями ASP.NET MVC.

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

    Полезные ресурсы:

    www.asp.net/vnext
    github.com/aspnet
    blogs.msdn.com/b/webdev/archive/2014/06/03/asp-net-vnext-in-visual-studio-14-ctp.aspx
    www.asp.net/aspnet/overview/owin-and-katana
    blogs.msdn.com/b/dotnet/archive/2014/05/12/the-next-generation-of-net-asp-net-vnext.aspx
    Инфопульс Украина
    Creating Value, Delivering Excellence
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 39

      –10
      Никто до сих пор не сказал зачем и кому все это реально нужно, кроме гипотетического желания запустить веб-приложение в других ОС.
        +13
        А разве это уже не плюс? Также теперь не надо зависеть от установленной версии .Net у хостера (не все используют для этого vps еще)
          +1
          Когда же будет можно подружить ubuntu+nginx+Mono(ASP vNext?)+PostgreSQL.
          Видимо мечты скоро сбудутся.
            0
            Хм, я кстати это момент не понял. Потому что я и раньше ASP.NET приложения запускал на линуксе(отладочный сервер xsp + nginix). Возможно имеется ввиду что теперь это можно будет делать без mono(с Core CLR)
              0
              Нет, это всё равно надо будет делать с mono, просто теперь новые версии фреймворка будут тестироваться на работоспособность в mono самим Майкрософтом.
                +2
                Пока с этим не все до конца понятно. Но на текущий момент ситуация такова.
                KLR запустить полностью в режиме Core CLR можно под Win 8.
                Во всех остальных случаях приложения запускаются поверх .net desktop, либо mono и это не Core CLR.
                Убедиться в этом можно распаковав любой klr проект коммандой — kpm restore. В обоих случаях грузиться «десктопный» mscorlib.

                Реализация Core CLR Native Host пока отсутствует для Linux/OSX.

          +7
          Кто-нибудь знает/понимает зачем разработчики решили отказаться от старого доброго web.config'a(и заодно мощного XML'a) в пользу config.json(c менее мощным JSON)?
          • НЛО прилетело и опубликовало эту надпись здесь
              +5
              Причем здесь фатальный недостаток?

              Насколько я понимаю, package.json это в некотором смысле калька с NodeJS.

              Но мне действительно интересно, почему решили отказаться от XML-based конфигов. Они повсеметно распространены в мире .NET. Зарекомендовали себя неплохо(возможно только излишне многословны). И причин отказа от них я не вижу, потому и спрашиваю.
              • НЛО прилетело и опубликовало эту надпись здесь
                  +9
                  Довольно таки жуткое детище, я вам скажу. У меня при каждом открытии глаза вытекают от количества элементов. Json же более лаконичный и его проще редактировать в %favorite_editor%, на чем MS акцентировало внимание. Мне лично это все кажется хорошим шагом. Давно мечтаю удаляить студию и пересесть на легковесный редактор. Сейчас же этот процесс во много затруднен, без толпы утилит для правки web.config/csproj/etc.
                    +1
                    А какие «легковесные редакторы» подойдут для разработки .Net приложений? Я так понимаю, что они будут уже без подсветки кода, быстрой навигации и других «сладких плюшек» (см фичи решарпера)?!
                      0
                      Да я писал в Sublime Text, но без интеллисенса(автокомплита) на шарпе писать издевательство. Слишком много стал ошибок допускать.
                      Еще есть SharpDevelop, но как у него с поддержкой C# 5 не знаю.
                      Или Monodevelop (но назвать его легковесным язык не поворачивается)
                    +10
                    Понимаете… фатальный недостаток — это про велосипеды, это если вместо json был бы mson (ну, например, Microsoft Object Notation).
                      0
                      новый формат конфигурации обусловлен как минимум тем, что полностью изменили концепцию, рантайм. старый был уже давно перегружен, с ужасными классами для работы со стандартной конфигурацией. а поскольку все-равно необходимо делать что-то новое — вот и решили заодно и выбрать подходящий формат, минималистичный.
                      +4
                      > Но мне действительно интересно, почему решили отказаться от XML-based конфигов.
                      Потому что в отличие от yaml и json назвать XML человекочитаемым можно лишь условно.
                        +4
                        >>почему решили отказаться от XML-based конфигов
                        То чувство, когда ты не знаешь что выбрать: аттрибут или вложенный элемент…
                          +2
                          И так каждый чёртов раз… Набросаешь оба варианта, расположишь их рядом и медитируешь… какой же смотрится краси́вее?
                            0
                            Конечно атрибут!

                            Let the holywar begin )
                      +5
                      Могу предположить, что дело в новом подходе к конфигурации приложения, который будет более ориентирован на Fluent стиль в Startup.cs.
                      С Roslyn у разработчиков теперь не IL библиотеки, а исходные cs файлы — редактируем код с полной поддержкой intellisense, строгим контролем типов, после просто сохраняем и перезапускаем веб-приложение, без промежуточной компиляции в сборку всего проекта и передиплоя.
                      В отличии от xml конфигурации — без надобности добавления Config Sections. Добавить reference все же проще.
                      json конфигурация поддерживает json-схему, спец символы. Новая ConfigurationModel поддерживает и xml источники.
                        0
                        давным-давно кодил на php, в последнее время занимаюсь разработкой на asp.net и вот несколько удивил подход нового компилятора.
                        В php я имел дело с файлами исходного кода, в asp.net имею дело со сборками. И тут тебе как гром среди ясного неба: в asp.net тоже теперь исходники безо всяких сборок благодаря новому компилятору Roslyn. Даже не знаю, шаг ли это вперед или просто такое забавное совпадение, ограничивающееся только поверхностым сходством.
                        И тут сразу же вопрос: как дела обстоят с совместимостью с обычными сборками? Связывание с ними происходит перед построением IL-кода новым компилятором? Т.е. как в случае с View в MVC: тоже имеем дело сперва с исходниками, которые потом самим IIS преобразуются в сборку?

                        и ещё один вопрос не в этой ветке: такие гибкие механизмы как трансформации нам дадут сразу же или придётся ждать следующей версии?
                          +1
                          По факту компиляция в .NET так и остались на месте, просто компиляция происходит «на лету» и ждать пересборки всех dll'ок не нужно.
                          Фишка с пересборкой по F5 (без передеплоя), как я понял, это фишка 14ой студии, потому что «в блокноте» у меня такой фокус провернуть не получилось.
                            +1
                            Это не совсем фиша студии, просто сборка уже собрана в памяти K Native Host — KLR.exe.

                            В зависимости от того насколько серьезны изменения в коде(в частности Reference), может потребовать от обычного перезапуска проекта в текущем процессе приложения хоста K
                            И аж до запуска нового процесса k.exe, выбора активной KRE, распаковки приложения и его запуска.
                            Больше информации тут:
                            github.com/aspnet/Home/wiki/KRuntime-structure
                            +1
                            И тут сразу же вопрос: как дела обстоят с совместимостью с обычными сборками?


                            Обратная совместимо имеется, проект можно билдить и запускать в режиме .NET Desktop, с текущим фреймворком установленым на системе, указывая referenсe в project.json. Кроме того в project.json можно указывать не только сборки, но и просто cs файлы, что будут включены и скомпилированы в рамках построения текущего проекта.

                            С View все было несколько по-другому, сейчас не надо придумывать механизма кеширования динамически скомпилированных razor view — все в памяти происходит.

                            Не совсем понял последний вопрос про трансформации.
                              +1
                              В случае с asp.net проектами можно создать несколько трансформаций Web.config для каждой конфигурации. При деплое трансформация применялась к исходному Web.config (анпример, prod-база вместо dev) и уже в таком виде он публиковался на сервер/в пакет.
                                0
                                Это уже больше к новой версии студии вопрос, нежели к ASP.NET или K — гибкие механизмы трансформации конфигов под целевую среду.
                                Учитывая, что пока даже свойства проекта и поддержка через gui project.json не реализована полноценно, пока еще рано говорить об этом.

                                  0
                                  С учетом того, что я увидел здесь: www.asp.net/vnext/overview/aspnet-vnext/getting-started-with-aspnet-vnext-and-visual-studio.
                                  Json-конфиги добавляются ручками в коде. Соответственно можно на уровне директив препроцессора добавлять разные JSON-файлы которые будут перезаписывать данные из основного. Но это чисто предположения.
                                  Скорее всего сделают и механизм трансформаций
                                    +2
                                    На уровне кода это было реализовано еще проще и гибче чем использование директив компилятора.

                                    Startup.cs — условная конвенция.
                                    В config.json веб-хоста(Microsoft.AspNet.Hosting) мы можем указать ключ:
                                    env: 'Dev'
                                    При запуске приложения сервер сначала будет искать класс StartupDev.cs и только потом Startup.cs для построения веб-приложения.

                                    Если ключ будет переопределен в консоли при передаче параметров в запуска приложения хоста, например 'env:QA'
                                    он будет приоритетней чем config.json. Соотвественно сначала будет произведен поиск StartupQA, если его нету, Startup.cs.

                                    Для каждой среды надо создать свой Startup.cs класс, в котором и будет идти специфическая для среды конфигурация для веб приложения.

                            0
                            Мне кажется json читается человеком легче, чем XML. Системой он читается (обрабатывается) также быстрее.
                            +5
                            vNext — маленькая эволюция.
                            Рекомендую к просмотру (на англ.):
                            1. Обзор vNext на TechEd channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DEV-B385#fbid.
                            2. Как устроено внутри vNext на TechEd channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DEV-B411
                              +1
                              Какие то инструменты для миграции существуют?
                              Текущий проект написан на ASP.NET MVC 3 но очень хотелось бы на vNext перейти.
                                +1
                                We will provide with a migration tool which will help you to migrate your existing applications to ASP.NET vNext for both .NET vNext and cloud optimized .NET vNext

                                blogs.msdn.com/b/webdev/archive/2014/06/03/asp-net-vnext-in-visual-studio-14-ctp.aspx
                                Там же список совместимости.

                                Если используете extensibility points в текущем ASP.NET, то скорее всего придется переносить что-то и руками, особенно если используете возможности отсутствующие в новой редакции. Пока деталей по тулзам нету, но сам факт их наличия положительный момент.
                                +4
                                Конечно, непривычно, но по сути в написании MVC проектов ничего серьезного не изменилось.

                                Только вот JSON выглядит как-то не так, есть у MS такая особенность забивать и резко переходить на что-то другое — так гляди еще и в XAML заменят на что-то json подобное в WPF.
                                  0
                                  >>MS такая особенность забивать и резко переходить на что-то другое

                                  Тут на самом деле довольно таки двубокая ситуация, на мой взгляд…
                                  Плюсы:
                                  — Никакого legacy
                                  — Всякие плюшки
                                  — Обычно (!) становится лучше\проще
                                  Минусы:
                                  — Никакого legacy
                                  — Ничего не понятно, приходится читать (не всегда)

                                  Я в коей мере даже за замену XAML на JSON, слишком он многословен и выглядит не очень (расставлять переносы для с десяток аттрибутов меня задолбало). Переучиваться в общем то и не надо, да и, уверен, всегда будет возможность использовать XAML, парсер ведь отделен от WPF.
                                  0
                                  В примерах все весело запускают k web а вот как его запустить на IIS информации ноль.
                                    –1
                                    +1
                                      0
                                      Ну так установите студию 15-ю и запускайте на IIS, основное преимущество что во время разработки нет необходимости держать тот же IIS. До релиза все может поменяться еще.
                                      Кстати, теперь все переименовали:
                                      k -> dotnet
                                      kre -> xre (.Net cross-platform runtime engine)
                                      kvm -> dotne sdk
                                      kpm -> nuget

                                      www.youtube.com/playlist?list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF (последнее видео от 12-01-2015).

                                      В том же видео рассказывают как оно внутренне будет работать на IIS — стандартно либо через нативный модуль.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое