Из вышеприведённого изображения видно, что существует целых две категории шаблонов для ASP.NET приложений, для новейшей версии ASP.NET Core 1.0 и обновлённой – ASP.NET 4.5.1, которая официально получила номер ASP.NET 4.6. Насчёт последней цифры в версии было много споров, выбор был между номерами 4.5.3 и 4.6, в конце, на основе мнений большинства, остановились на последней. Разработчик, имеющий опыт работы с предыдущими версиями платформы наверняка в первую очередь продумает, что данный шаблон сделан для совместимости и для сопровождения предыдущих версий технологии. По крайней мере так было всегда, вспомним Visual Studio 2010/2012/2013. Так ли это? Отчасти, да. Но, с большими оговорками: помните рисунок из предыдущей статьи? Если оставить только содержимое для веба, то получи примерно следующее:

Получается, что существует целых две актуальных технологии для разработки веб-приложений сегодня: ASP.NET 4.6 и ASP.NET Core 1.0, которые нам предлагает Microsoft. Детальное описание новейшей версии – ASP.NET Core будет дано в последующих статьях, в данной сравним обе  друг с другом. Для начала посмотрим что нам может предложить обновлённая версия ASP.NET 4.5.1? Давайте переместимся немного назад, а именно в год 2013-ый, когда состоялся релиз Visual Studio 2013. Если кто помнит, тогда мы не получили ничего абсолютно нового в плане глобальных изменений. Да, была реализована так называемая идея объединения технологий Web Forms, MVC и Web API, получившая официальное название «Единый ASP.NET» (“One ASP.NET”), но она немножко припозднилась, точнее могли раньше сделать, ничего этому не мешало, но не делали. Конечно, технологии и библиотеки были обновлены, но в глобальном плане ничего революционного не было, за исключением новой идеи – «OWIN» и её реализации «Katana». Для получения большей информации насчёт последних рекомендую ознакомиться с циклом статей «Microsoft OWIN и конвейер обработки запросов ASP.NET». А что по сути дал нам OWIN в ASP.NET 4.5.1, ровным счётом ничего полезного. Единственное – конвейер усложнился ещё больше, хотя и без того был сложным. А сложность не является оправданной, если не приносит никакой пользы. В нижнем рисунке видна схема конвейеров, поставленная рядышком: слева – обычный конвейер ASP.NET/IIS, посередине тот же конвейер, но уже по спецификации OWIN, по сути их там два и правый – конвейер без IIS и ASP.NET.В частности можно увидеть насколько конвейер OWIN без IIS простой и легковесный (файл рисунка в более высоком разрешении можно взять отсюда).

Но почему спецификация OWIN была бесполезной и не принесла ничего нового и существенного. Просто её реализация тогда ещё была далека от совершенства, это же было началом конца монополии IIS для ASP.NET (Нужны ли нам ASP.NET и IIS?). Применение данной спецификации на IIS, как уже отметил выше не было полезным, а использование вне – затруднительным. Почему затруднительным? Да, потому, что насколько хорошей бы не была идея, её ещё нужно реализовать и «обкатить» как следует. Конечно, появилась возможность хостинга приложения вне IIS, но использовать свой сервер или хост (Self-Host) уровня обычного консольного приложения попросту неразумно для серьёзных приложений. Может мы чем-то не довольны в IIS, но все те средства администрирования (управление, диагностика, логирование и т.п.) сервера, весь тот опыт (багаж знаний) который есть уже, с этим нельзя не считаться. Всё же, именно дальнейшее развитие спецификации OWIN легло в основу ASP.NET Core. Несмотря на всё это ASP.NET 4.5.1 была обновлена и получила новую версию – ASP.NET 4.6. Следует отметить, что под ASP.NET 4.6 подразумевается весь следующий спектр технологий: Web Forms, MVC 5.x, Web API 2.x и SignalR 2.x. И на этот раз Microsoft не прекратила поддержку уже «устаревшей» технологии, а наоборот добавила очень много всего интересного и полезного. Ниже перечислен список самых важных нововведений.

Поддержка протокола HTTP/2.

Новая версия протокола HTTP добавлена в ASP.NET и в .NET Framework 4.6. Для использования HTTP/2 с ASP.NET приложение должно выполняться в Windows 10 или Windows Server 2016, важен не номер ОС, а версия IIS нужен IIS 10 или выше. Важно отметить, что пока ещё, на момент написания статьи, поддержка HTTP/2 не добавлена в ASP.NET Core, в будущем появится обязательно. HTTP/2 — это новая версия протокола HTTP, которая обеспечивает более эффективную коммуникацию (меньшее число циклов передачи-подтверждения между клиентом и сервером) и уменьшение задержки при загрузке веб-страницы для пользователей. HTTP/2 обеспечивает максимальное преимущество для веб-страниц (по сравнению со службами), так как оптимизирует запрос различных артефактов в ходе одной операции. Всю работу выполняют браузер и веб-сервер (IIS в Windows). Нет необходимости перекладывать нагрузку на пользователей. Большинство основных браузеров (новые версии) поддерживают HTTP/2, поэтому вполне вероятно, что пользователи смогут воспользоваться преимуществами протокола HTTP/2, если его поддерживает сервер. Более подробно о новом протоколе, к примеру, можно узнать по этой ссылке на Channel 9. На мой взгляд это очень существенное обновление для ASP.NET 4.6.

Добавлена поддержка .NET Compiler Platform (“Roslyn”) в ASP.NET.

По мне, ещё одно существенное улучшение. Чтобы не быть многословным, отмечу самое ванное преимущество, которое мы получаем, используя Roslyn это – скорость компиляции. Вдобавок ко всему и новые возможности языков программирования, хотя я их считаю пока ещё мало полезными. Для получения больших сведений на данный счёт можете взглянуть, например, сюда.

Прочие улучшения и обновления в ASP.NET 4.6.

Далее перечислен список менее значимых, хотя вполне себе полезных улучшений и обновлений. Были обновлены MVC 5 и Web API 2 до версии 5.2.3, сделаны мелкие улучшения и исправления ошибок. Добавлена асинхронная модель привязки в Web Forms, были обновлены элементы управления для поддержки Entity Framework 6 и обновлена библиотека Ajax Control Toolkit. Полный перечень всего вышесказанного можно найти в данной статье.Также следует отметить ещё одно улучшение, не относящееся непосредственно к платформе ASP.NET 4.6, но используемое ею, это – новый 64-разрядный JIT компилятора. В .NET Framework 4.6 представлена новая версия компилятора JIT, который имеет значительно большую производительность, чем существующий 64-разрядный компилятор JIT. Из всего вышеперечисленного видно, что изменений и улучшений не мало, что делает платформу ASP.NET 4.6 вполне себе актуальной на сегодняшний день. И конечно, улучения будут и в будущем.

А что насчёт новейшей версии – ASP.NET Core?

Кратко перечислю основные значимые особенности, которые более детально будут описаны в последующих статьях. Намного более быстрая и легковесная среда выполнения. Возможность хостинга приложений где и как вам удобно, больше нет жёсткой привязки к IIS, хотя данная возможность появилась немного раньше, но была не совсем удобной и доработанной, как уже отметил выше. Полная модульность благодаря ключевым изменениям и .NET Core. Кроссплатформенность (возможность хостинга приложений вне Windows, а в данном случае это Linux и Mac OS), как бы широко не рекламировалась, лично по мне это не ключевое изменение, хотя могу ошибаться. Трудно представить разработчика, использующего всё, и вся от Microsoft переходящего с ASP.NET на другую ОС. Хотя вполне реально, что разработчики использующие другие платформы будут использовать ASP.NET Core вне Windows. Конечно есть альтернативные и не мене достойные веб-технологии и там. Далее, возможность конфигурирования и развёртывания намного упрощена, но разработчику долгое время работавшему с XML трудно и непривычно переходить на JSON. Хотя JavaScript библиотеки и платформы уже вовсю используют подход на основе JSON и поэтому иметь подобное на серверной стороне всё же намного удобней. Иметь единый стек как для интерфейса пользователя (Web UI), так и для API намного разумней, нежели два. Правда, на мой взгляд, задача была тогда отвязать и сделать отдельную технологию для создания служб HTTP, которую можно было бы развивать отдельно от ASP.NET/IIS, но это как видно не очень-то получилось. Также были добавлены новые средства, которые упрощают процесс диагностики приложения (об этом будет отдельная статья). Всё перечисленное выше делает приложения на ASP.NET Core более «дружественным к облаку» (Cloud Optimized ASP.NET), а как известно облачные технологии уже сегодня имеют большую роль и будут иметь ещё большую в будущем. И наконец отмечу, что все перечисленные изменения появились благодаря тому, что платформа была переписана почти с нуля, благодаря уже имеющемуся опыту и сегодняшним требованиям, а это уже о многом говорит.

Название моей прошлогодней статьи «Microsoft ASP.NET vNext: эволюция или революция?» звучит слишком громко, но это вполне оправдано, если смотреть с точки зрения проделанной работы (которая на мой взгляд могла быть сделана и намного раньше), т.е. разницы с предыдущей. Да всё хорошо и замечательно, у нас много всего нового, но что нам, всем тем, кто использует данную платформу, даст новейшая технология? Ведь опыт показывает, что для построения «правильных» приложений технология уходит на второй план и в большинстве случаем не играет ключевую роль. То есть, если разработанное приложение не решает или решает плохо поставленные задачи, тогда никакая супер-мега технология, в подавляющем большинстве случаев, легко и просто не поможет кардинально исправить ситуацию. Если лет пять назад на так называемых «front-end» (замечу что под данным термином в данном случае я подразумеваю не верстальщика, а разработчика, уверенно владеющего JavaScript и разного рода библиотеками и технологиями на JavaScript) разработчиков смотрели косо, то ситуация сегодня совсем другая. Разрабатывать на JavaScript ничуть не легче и проще, а порой и ещё сложнее. JavaScript– это «душа» веба сегодня, нельзя с этим не считаться. Хотим мы того или нет, но подход, при котором HTML генерировался на сервере с помощью серверных технологий всё больше становится менее популярным, и это неизбежно и тому есть причина. Веб-приложение сегодня – это нечто намного и намного большее, чем было скажем лет десять назад. В свою очередь это влечёт за собой сложность, которая становится неоправданно высокой, если использовать серверные технологии, такие как ASP.NET Web Form или ASP.NET MVC для реализации логики работы сложного и интерактивного приложения на клиенте, вместо того же JavaScript. До сегодняшнего дня Visual Studio ничего близкого не могла предложить по сравнению, например, с тем же WebStorm (разработчики у кого есть опыт работы с WebStorm меня поймут) с точки зрения «front-end» разработки. А использовать приложение ASP.NET исключительно как сервисный слой не всегда разумно, учитывая альтернативные технологии. С приходом ASP.NET Core ситуации меняется, жаль, что не раньше, хотя функционал по работе с SPA и не только, по сравнению с WebStorm, на мой взгляд, пока ещё ограничен. Да, может я слишком критичен в последних приложениях, можно было бы обойтись существующими возможностями Visual Studio, но это жутко неудобно. К примеру, если взять тот же Gulp или Grunt, до Visual Studio 2015 и ASP.NET Core встроенных средств для работы с ними не было. Поэтому не может не радовать факт наличия много всего нового в ASP.NET Core. И так, будем прагматичны, имея две технологии для веб-разработки неизбежно возникнет вопрос:

Что нам следует сделать, каков наш выбор?

Выбор в данном случае не простой. Если у вас классическое приложение ASP.NET Web Forms и много свободных ресурсов (денег) – мигрируйте на ASP.NET Core. В случае ограниченных ресурсов, советую вам проделать постепенную миграцию до ASP.NET 4.6. Используя идею «Единый ASP.NET» это можно сделать поэтапно, где-то оставить старый код, где-то MVC, а в частях где производительность критична на клиенте и сервере тоже – подход с одностраничным приложением (SPA), например, используя AngularJS. Я со своими разработчиками делал подобное, есть опыт миграции корпоративных веб-порталов с ASP.NET 3.5 на ASP.NET 4.6. И скажу вам, что это не так просто, как вначале казалось, слишком много подводных камней (вот один из многих) было, отчасти зависящих также и от качества кода. Ну а если ваш код не удовлетворяет вашим потребностям, то тут стоит задуматься именно над этим, а не о технологии или платформе. В том случае, если у вас приложение ASP.NET MVC, переходить на ASP.NET Core стоит в двух случаях: у вашего приложения проблемы с производительностью (вы сделали всё, дальше ничего оптимизировать невозможно) или у вас много денег свободного времени. В противном случае нужно улучшать свой код. Бывают случаи, когда код сильно завязан на System.Web.dll и IIS, это тоже весомый повод ничего не трогать. Ну и последний случай, если ASP.NET используется исключительно в виде веб-сервисов, например, в случае с Web API. Примером тому могут быть одностраничные приложения (SPA) или распределённые, которые могут и не иметь отношения к HTML. В подобном случае перейти на новую версию будет намного легче, чем в предыдущих. Опять-таки, если вас всё устраивает, то переходить на ASP.NET Core незачем. Почти во всех случаях, достаточно легко и быстро обновить .NET Framework до версии 4.6 и жить спокойно. Я знаю приложения и людей, которые используют всё ещё классический ASP и пока ещё их это устраивает. Если вы не довольны производительностью Web API и IIS, то это тоже повод для обновления на ASP.NET Core.

Теперь осталось попытаться дать однозначный ответ на главный вопрос, так каков же наш выбор: ASP.NET 4.x или ASP.NET Core? Однозначного ответа нет, зависит от... И выбор за вами, однако, нужно помнить, что будущее за ASP.NET Core и рано или поздно оно наступит.

Одновременно с запуском .NET Framework 4 была обновлена и ASP.NET до четвёртой версии. Ещё одно крупное обновление платформы было выпущено с выходом ASP.NET 4.5. Появились такие средства как Web API и SignalR. С выходом Visual Studio 2013 появилась новая концепция – «Единый ASP.NET». Были обновлены все компоненты платформы, а также появилась новая спецификация OWIN – открытый интерфейс веб-сервера для .NET (Open Web Server Interface for .NET), которая стала основой ASP.NET vNext. А уже в прошлом году была выпущена предварительная версия кардинально переработанной технологии для разработки веб-приложений от Microsoft, которая получила официальное название – ASP.NET 5. Помимо прочего, также доступно очень большое количество обновленных и новых технологий и продуктов от Microsoft, финальные версии которых выйдут уже в этом году. А теперь обо всём этом по порядку. Начну с самого крупного и значимого события – обновления и улучшения .NET Framework. Прежде чем начать, вспомним историю развития .NET Framework:

Платформа .NET была представлена в 2002 году и очень быстро завоевала популярность, став одной из основных современных средств разработки программного обеспечения. Её основными преумуществами перед предшественницей – технологией COM, которую она заменила, являются гибкость, более простая и надёжная модель программирования. Платформа равивалась, выходили всё новые версиии, библиотеки и технологии, для удовлетворения всё новых потребностей бысто развивающегося мира информационных технологий. Ну и конечно, Microsoft не сидит сложа руки, для того, чтобы идти в ногу со временем, продолжает улучшать платформу .NET. Совсем недавно платформа, представленная в прошлом году, была обновлена до версии .NET Framework 4.6.2. И так,  какое же будущее ожидает .NET? А будущее действительно очень интересное и многообещающее.

Как видно из рисунка показанного выше, есть по сути две версии .NET Framework. Первая является логическим продолжением существующей версии .NET 4.5.2, которая получила официальное название – .NET 4.6 (обновлённые версии: .NET Framework 4.6.1 – 4.6.2). Вторая именуется теперь уже как .NET Core 1.0 (до этого известная как .NET Core 5) и является упрощённой версией обычного .NET Framework. Если с первым всё предельно ясно и понятно, то в случае со вторым возникает много вопросов. Самый главный – зачем он нам? Для удовлетворения быстрорастущих потребностей современного цифрового мира, который развивается стремительными темпами. Если взглянуть на шкалу развития платформы .NET приведённую выше, то можно увидеть, что цикл выпуска новых версий платформы составляет примерно пару лет, а то и больше, что является очень большим сроком при нынешнем положении дел. Нужно как то исправить ситуацию,  решение – .NET Core 1.0. Последний должен удовлетворять современным требованиям разработки, для этого были установлены новые тентенции для продвижения и развития платформы: быстрый цикл разработки и участие сообщества. Для этих целей специально была создана независимая организация ­.NET Foundation­, которая будет заниматься развитием экосистемы .NET. По данной ссылке перечислены все текущие проекты, которые будут развиваться под руководством последней. То есть получается платформа .NET становится открытой. Полная модульность – вот одна из главнейших возможностей, которая мне нравится больше всех. Особенно это полезно для веб-приложений, позже напишу почему.

Следующий рисунок показывает общую модель приложения, которая будет использовать платформу .NET Core. Модульность .NET Core означает, что фреймворк будет поставляться по частям через NuGet, тогда можно будет вместе с приложением поставлять саму платформу, которая будет изолирована от остальных. Т.е. не будет одной общей версии .NET на всю машину.

Больше сведений про .NET 2015 и .NET Core можно узнать на Channel 9. Также советую почитать данную статью на хабре и изучить курс на сайте Microsoft Virtual Academy. А что нас ожидает в ближайшем будущем, каким будет .NET завтра?

Больше сведений относительно настоящего и будущего платформы можно узнать из докладов dotnetConf 2016. Теперь, поговорим об ASP.NET Core, ниже показана изображение общей схемы платформы.

Как можно видеть из рисунка, ключевыми свойствами новой технологии являются полная модульность и кроссплатформенность. То есть используя фреймворк как часть пакета развёртывания, больше не будет проблем конфигурации среды хостинга для приложения. Каждое приложение будет иметь свою, независимую версию платформы. Почти вся платформа написана с нуля и на управляемом коде, старого кода тут нет. Весь исходный код новейшей версии веб-платформы открыт и доступен на GiHub. Технологии ASP.NET MVC и Web API объеденены в одну, а Web Forms больше не используется в версии ASP.NET Core. Новая версия ASP.NET в ОС Windows будет работать используя одну из двух версий .NET Framework: .NET 4.6 и .NET Core 1.0. На Linux и Mac OS X будет использоваться только .NET Core. Больше сведений по ASP.NET Core можно получить на Channel 9 ­«What's ­New with ASP.NET 5»­, тот же курс доступен на сайте Microsoft Virtual Academy (ASP.NET 5 была переименована в ASP.NET Core 1.0).­­ Также советую посмотреть курс «ASP.NET Core 1.0 Fundamentals» от Pluralsight. Много очень интересного и полезного для себя я почерпнул из доклада «ASP.NET vNext: What it means to you and what it means to Microsoft», который я пересмотрел не раз. В следующей части будет рассморено всё то, что предлагает нам новейшая версия .NET Framework в плане веб-разработки.

Релиз – Дата: Beta5 – 30.06.2015 => Beta6 – 27.07.2015 => Beta7 – 02.09.2015

Релиз – Дата: Beta8 – 15.10.2015 => RC1 – 18.11.2015 => RC2 – 02.2016 => RTM – первый квартал 2016

Из вышеприведённого графика видно, что релизы выходили достаточно часто ну и критических обновлений тоже было много. Последняя версия SignalR 3 – Beta5 уже не работает с версией ASP.NET 5 Beta7, не говоря уже о текущей RC1. И наконец в конце официального расписания релизов сказано, что поддержка Visual Basic, SignalR 3, Web Pages 4 в ASP.NET 5 появится после выхода RTM, где-то в третьем квартале 2016. Отсюда уже ясно, что, обновив пример из галереи до ASP.NET 5 RC 1, он перестанет работать. Так ка же быть? Временно использовать SignalR 2. Приложение «Real-Time Data Editing» в последний раз было обновлено используя Visual Studio 2015 RTM и ASP.NET Beta5. Я сделал так, чтобы в решении Visual Studio сохранялись предыдущие версии приложения:

их можно скачивать и запускать также (детальное описание о том, как это сделать приведено на странице приложения). Для начала скачаем и обновим приложение из архива RealTimeDataEditorVS2015RTM-ASP5BETA5. Процесс обновления не буду приводить дабы не загромождать статью, да и сложного в этом ничего нет. После обновления имеем следующее:

приложение компилируется и запускается, но не показывает данные, так как нет SignalR 3. А что если подключить текущую dev-ветку кода SignalR 3 в проект? Приложение скомпилируется без ошибок, но вот работать не будет, как показано ниже.

Далее нужно освежить знания о конвейере ASP.NET и вспомнить про модули OWIN. В добавок нужно изучить все те изменения, которые были сделаны при реализации OWIN в ASP.NET 5. На основе этих знаний получаем один единственный тип:

namespace RealTimeDataEditor
{
    using AppFunc = Func<IDictionary<string, object>, Task>;

    public static class BuilderExtensions
    {
        public static IApplicationBuilder UseAppBuilder(
            this IApplicationBuilder app, 
            Action<IAppBuilder> configure)
        {
            app.UseOwin(addToPipeline =>
            {
                addToPipeline(next =>
                {
                    var appBuilder = new AppBuilder();
                    appBuilder.Properties["builder.DefaultApp"] = next;

                    configure(appBuilder);

                    return appBuilder.Build<AppFunc>();
                });
            });

            return app;
        }

        public static void UseSignalR2(this IApplicationBuilder app)
        {
            app.UseAppBuilder(appBuilder => appBuilder.MapSignalR());
        }
    }
}

Используем старый модуль SignalR 2 в новой версии,

public void Configure(IApplicationBuilder app, IHostingEnvironment env,
    ILoggerFactory loggerFactory)
{
    app.UseStaticFiles();
    app.UseSignalR2();

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
} 

и видим, что всё работает нормально.

Запускаем веб-браузер на виртуальной машине и скачиваем установочный пакет HttpPlatformHandler v1.2 для x64.

Прежде чем произвести установку посмотрим список установленных по умолчанию модулей при помощи диспетчера IIS (IIS Manager).

После окончания установки HTTP Platform Handler

смотрим на список модулей IIS ещё раз.

Видно, что раздел неуправляемых HTTP-модулей IIS пополнился ещё одним модулем под названием httpPlatformHandler. Открываем Visual Studio 2015 и создаем приложение ASP.NET 5 (на момент написания статьи используется Visual Studio 2015 Update 1 с ASP.NET 5 RC1).

Публикуем приложение в файловой системе.

Каталоги approot и wwwroot, которые создаются при публикации приложения ASP.NET 5, копируем в стандартную директорию IIS. В данном случае каталог wwwroot заменяет собой присутствующий по умолчанию каталог wwwroot в inetpub. Напомню, что wwwroot содержит только статические файлы приложения (файлы JavaScript тоже таковыми являются), всё остальное находится в папке approot.

После копирования, или перед, нам нужно поменять настройки пула приложения, в данном случае он сам непосредственно не будет загружать никакую версию CLR, то есть будет по сути обычным процессом. Это возможно благодаря тому, что, приложения ASP.NET 5 имеют собственный процесс, в котором выполняются. До ASP.NET 4.6, как вы знаете в качестве хоста приложения выступали непосредственно процессы пулов IIS. В конце мы посмотрим на список процессов.

Нужно также убедиться, что секция обработчиков HTTP-данных разблокирована в настройках IIS, по умолчанию это так и есть.

Вот так это будет выглядеть: Lock Section (секция разблокирована, активна кнопка блокировки).

Ну и после вышеописанного останется только запустить приложение и убедиться, что всё работает.

Получается, что в настоящее время всё же, кое-что нужно выполнять вручную, но как видно всё просто. Теперь давайте запустим Process Explorer и посмотрим на список процессов, созданных для работы приложения, про которые я упомянул выше. Действительно, если посмотреть на выделенное дерево процессов, то можно увидеть, что у процесса пула w3wp.exe нет вкладок с информацией о .NET, так как CLR не загружена. Ну а в качестве нового хоста для приложения ASP.NET 5 выступает DNX.

Назревает вполне себе логичный вопрос: если всю работу, ну или почти всю на себя берёт DNХ, то зачем нам вообще процесс пула и сам IIS? Тут нужно вспомнить, что IIS это не только процесс пула W3WP, как многим кажется на первый взгляд, а целый комплекс компонент, взаимодействующих между собой, как показано в статье по ссылке. И в данном конкретном случае, часть работы по обработке запросов (прием и передача, хостинг файлов, управление и мониторинг процессов и т.п.) IIS берет на себя. Ну и наконец ниже приведен список ссылок по HTTP Platform Handler, их не много, да и информации тоже:

https://www.iis.net/learn/extensions/httpplatformhandler https://www.hanselman.com/blog/AnnouncingRunningRubyOnRailsOnIIS8OrAnythingElseReallyWithTheNewHttpPlatformHandler.aspx https://azure.microsoft.com/en-us/blog/announcing-the-release-of-the-httpplatformhandler-module-for-iis-8

<authentication mode="Forms">
  <forms path="/" loginUrl="~/Default.aspx" protection="All"
 domain=".mydomain.com" timeout="2000"
 name=".ASPXAUTH"
 slidingExpiration="true">
  </forms>
</authentication>
<machineKey 
 validationKey="A2734932DA6EE8B5917A35C2BA8536DE3E14074C415EE45417CD7"
 decryptionKey="4171F954D13C3C2DDF7C3551283C4"
 validation="SHA1"
></machineKey>
 

Обратите внимание, что в примере, для экономии места, приведены фиктивные значения validationKey и decryptionKey, реальные же намного длинее. Убедившись что всё идентично, запускаем приложения, не работает аутентификации. Разница платформ, однозначно да. Смотрим логи сервера, находим: Event code: 4005 Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid. Нужно проверить настройки IIS, не была ли включена генерация случайных ключей на уровне IIS, также нужно проверить аккаунты от имени которых работают пулы, на идентичность. Была и такая проблема с приложениями C и D, решение описано здесь. Те кто регулярно наблюдал и наблюдает за изменениями в платформе .NET наверняка помнят, что в .NET 4.5 были внесены криптографические улучшения остальным пришлось бы потрать больше времени в поисках. Прочитав все три части становится понятно, откуда может быть проблема, дело в арибуте targetFramework узла <httpRuntime targetFramework="4.5.1" />. Он попросту отсутствует в старых версиях web.config, хотя присутствует по умолчанию в новых. Как и почему, всё описано здесь. А что касается приложения E, его по тем или иным причинам невозможно перенести на новую платформу. В этом случае возникает другая проблема, проблема разных механизмов шифрования, котрая решается добавлением атрибута compatibilityMode в тег <machineKey compatibilityMode="Framework20SP1" />. Также была проблема и с requestValidationMode, решается удалением этого атрибута из <httpRuntime requestValidationMode="2.0" />. Значения атрибутов и элементов конфигураций не были описаны детально, более подробное описание можно найти в MSDN или по приведённым ссылкам. В итоге получаем, что общие решения не всегда работают, каждое приложени в своём роде уникально. Надеюсь, что данная статья окажется полезной, если вы сталкнётесь с подобным.

public class ProductsRepository : IProductsRepository
{
    private readonly Stopwatch stopwatch;
 
    public ProductsRepository()
    {
        this.stopwatch = new Stopwatch();
    }
 
    #region IProductsRepository Members
 
    public IList<Product> GetAllProducts()
    {
        try
        {
            this.stopwatch.Start();
            return ProductsDataStore.Products;
        }
        finally
        {
            this.stopwatch.Stop();
            Trace.WriteLine(string.Format(
                "ProductsRepository.GetAllProducts execution time: {0} ms.",
                this.stopwatch.ElapsedMilliseconds));
            this.stopwatch.Reset();
        }   
    }
 
    public void Insert(Product product)
    {
        ProductsDataStore.Insert(product);
    }
 
    public void Update(Product product)
    {
        ProductsDataStore.Update(product);
    }
 
    public void Delete(int productId)
    {
        ProductsDataStore.Delete(productId);
    }
 
    #endregion
}
 

Результат будет таким, как показано ниже:

В Visual Studio 2015 появилась новая особенность, которая называется "PerfTips". Своего рода подсказки показывающие производительность, то есть время выполнения кода во время отладки:

Что нужно сделать, чтобы увидеть время выполнения кода? Почти ничего, достаточно пройтись по строке кода во время отладки (Step Over (F10)) и подсказка будет выводиться автоматически. Не придётся больше писать рутинный код. Конечно, никто не говорит отказываться от Stopwatch, так как данная особенность работает в отладчике, а если нужно получить трассировку выполнения разных участков кода без отлаки и отладчика, то тут без Stopwatch не обойтись. Больше сведений о PerfTips можно получить отсюда.

Примером такого проекта служит обычная библиотека классов.

Напомню, что в предыдущих предварительных версиях ASP.NET 5 подобного не было. Также появилась возможность запуска приложений в режиме отладки в различных браузерах, в том числе и на браузерах эмуляторов.

Вот только тут отмечу, что использовать возможность на виртуалках Azure нет возможности, так как там недоступна технология Hyper-V. Была также добалена возможность использования собственных команд в файле project.json, а также возможность запуска и отладки последних.

Больше сведений касательно изменений в версии Beta2 можно получить отсюда. Более детально новые возможности Visual Studio 2015 и ASP.NET будут описаны в будущем. Чтобы опробовать новые возможности продукта можно использовать готовые образы в Microsoft Azure

или скачать отсюда и установить на локальной машине.

namespace UnityDIExample
{
    public class UnityDependencyResolver : IDependencyResolver
    {
        private readonly IUnityContainer unityContainer;
 
        public UnityDependencyResolver()
        {
            unityContainer = new UnityContainer();
            unityContainer.RegisterType<ITestService, TestService>();
        }
 
        public object GetService(Type serviceType)
        {
            return unityContainer.IsRegistered(serviceType) ? 
                unityContainer.Resolve(serviceType) : null;
        }
 
        public IEnumerable<object> GetServices(Type serviceType)
        {
            throw new NotImplementedException();
        }
    }
}

Добавим зависимость ITestService

namespace UnityDIExample.Controllers
{
    public class HomeController : Controller
    {
        private readonly ITestService testService;
 
        public HomeController(ITestService testService)
        {
            this.testService = testService;
        }
 
        public ActionResult Index()
        {
            return View();
        }
 
        public ActionResult About()
        {
            ViewBag.Message = "Your application description page.";
 
            return View();
        }
 
        public ActionResult Contact()
        {
            ViewBag.Message = "Your contact page.";
 
            return View();
        }
    }
}

в конроллер и запустим приложение, предварительно задав Dependency resolver в Global.asax.

namespace UnityDIExample
{
    public class MvcApplication : System.Web.HttpApplication
    {
        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);
            DependencyResolver.SetResolver(new UnityDependencyResolver());
        }
    }
}

Видим, что приложение выбрасывает исключение: "No parameterless constructor defined for this object".



Дело в том, что стандартный активатор контроллера не может создать экземпляр контроллера без параметров. Чтобы полностью настроить и установить Unity нужен ещё один пакет NuGet, так называемый загрузчик (bootstraper). Установим его используя менеджер пакетов NuGet.



Как видно из нижнего рисунка в проект добавилось два файла: UnityConfig.cs и UnityMvcActivator.cs.



Первый содержит класс реализующий шаблон – "Одиночка (Singleton)", для конфигурации контейнера. Именно сюда нужно добавить метод регистрации зависимости ITestService, а именно – RegisterType<ITestService, TestService>(). Код показан ниже (оригинальные комментарии удалены в целях экономии места в листинге, их можно будет увидеть в проекте, когда создаются данные файлы).

namespace UnityDIExample.App_Start
{
    public class UnityConfig
    {
        #region Unity Container
 
        private static Lazy<IUnityContainer> container =
            new Lazy<IUnityContainer>(() =>
            {
                var container = new UnityContainer();
                RegisterTypes(container);
                return container;
            });
 
        public static IUnityContainer GetConfiguredContainer()
        {
            return container.Value;
        }
        #endregion
 
        public static void RegisterTypes(IUnityContainer container)
        {
            // TODO: Register your types here
            container.RegisterType<ITestService, TestService>();
        }
    }
}

Втрой файл – UnityMvcActivator.cs содержит методы Start и Shutdown, которые запускаются на старте приложения уже не через Global.asax, а при помощи атрибутов из сборки WebActivatorEx. Некоторые оригинальные коментарии в коде ниже, также были удалены.

using System.Linq;
using System.Web.Mvc;
using Microsoft.Practices.Unity.Mvc;
 
[assembly: WebActivatorEx.PreApplicationStartMethod
    (typeof(UnityDIExample.App_Start.UnityWebActivator), "Start")]
[assembly: WebActivatorEx.ApplicationShutdownMethod
    (typeof(UnityDIExample.App_Start.UnityWebActivator), "Shutdown")]
 
namespace UnityDIExample.App_Start
{
    public static class UnityWebActivator
    {
        public static void Start() 
        {
            var container = UnityConfig.GetConfiguredContainer();
 
            FilterProviders.Providers
                .Remove(FilterProviders.
                    Providers.
                    OfType<FilterAttributeFilterProvider>().First());
            FilterProviders.Providers
                .Add(new UnityFilterAttributeFilterProvider(container));
 
            DependencyResolver.
                SetResolver(new UnityDependencyResolver(container));
 
            // TODO: Uncomment if you want to use PerRequestLifetimeManager
            // Microsoft.Web.Infrastructure.DynamicModuleHelper.
            // DynamicModuleUtility.RegisterModule
            // (typeof(UnityPerRequestHttpModule));
        }
 
        public static void Shutdown()
        {
            var container = UnityConfig.GetConfiguredContainer();
            container.Dispose();
        }
    }
}

Можно увидеть, что и тут добавляется UnityDependencyResolver, но он уже не наш, а поставляется вместе с сборкой загрузчика (Unity bootstrapper for ASP.NET MVC).



Код UnityDependencyResolver можно увидеть ниже. Если покапаться в коде сборки, то можно найти очень много интересного, например HTTP-модуль UnityPerRequestHttpModule. Это уже оставляю вам, дорогой читатель.

public class UnityDependencyResolver : IDependencyResolver
{
    private readonly IUnityContainer container;
 
    public UnityDependencyResolver(IUnityContainer container)
    {
        this.container = container;
    }
 
    public object GetService(Type serviceType)
    {
        if (typeof(IController).IsAssignableFrom(serviceType))
        {
            return UnityContainerExtensions
                .Resolve(this.container,
                    serviceType, new ResolverOverride[0]);
        }
        try
        {
            return UnityContainerExtensions
                .Resolve(this.container,
                    serviceType, new ResolverOverride[0]);
        }
        catch (ResolutionFailedException)
        {
            return null;
        }
    }
 
    public IEnumerable<object> GetServices(Type serviceType)
    {
        return this.container.
            ResolveAll(serviceType, new ResolverOverride[0]);
    }
}
 

Теперь если запустить приложение, то всё будет работать.



И если вы решите использовать Unity в своём приложении (рекомендую почитать данный раздел в MSDN, доступна и PDF версия руководства), надеюсь, что данная статья поможет вам быстро сконфигурировать DI-контейнер.

Из рисунка (ссылка на pdf файл высокого качества) видно, что ключевую роль здесь играет обычный HTTP-модуль, который подключает конвейер OWIN.

namespace Microsoft.Owin.Host.SystemWeb
{
    using AppFunc = Func<IDictionary<string, object>, Task>;
 
    internal sealed class OwinHttpModule : IHttpModule
    {
        private static IntegratedPipelineBlueprint _blueprint;
        private static bool _blueprintInitialized;
        private static object _blueprintLock = new object();
 
        public void Init(HttpApplication context)
        {
            IntegratedPipelineBlueprint blueprint =
                LazyInitializer.EnsureInitialized(
                    ref _blueprint,
                    ref _blueprintInitialized,
                    ref _blueprintLock,
                    InitializeBlueprint);
 
            if (blueprint != null)
            {
                var integratedPipelineContext =
                    new IntegratedPipelineContext(blueprint);
                integratedPipelineContext.Initialize(context);
            }
        }
 
        public void Dispose()
        {
        }
 
        private IntegratedPipelineBlueprint InitializeBlueprint()
        {
            IntegratedPipelineBlueprintStage firstStage = null;
 
            Action<IAppBuilder> startup = OwinBuilder.GetAppStartup();
            OwinAppContext appContext = OwinBuilder.Build(builder =>
            {
                EnableIntegratedPipeline(builder, stage => firstStage = stage);
                startup.Invoke(builder);
            });
 
            string basePath = 
                Utils.NormalizePath(HttpRuntime.AppDomainAppVirtualPath);
 
            return new IntegratedPipelineBlueprint(
                appContext, firstStage, basePath);
        }
 
        private static void EnableIntegratedPipeline(IAppBuilder app,
            Action<IntegratedPipelineBlueprintStage> onStageCreated)
        {
            var stage =
                new IntegratedPipelineBlueprintStage
                {Name = "PreHandlerExecute"};
            onStageCreated(stage);
            Action<IAppBuilder, string> stageMarker = (builder, name) =>
            {
                Func<AppFunc, AppFunc> decoupler = next =>
                {
                    if (string.Equals(name, stage.Name, 
                        StringComparison.OrdinalIgnoreCase))
                    {
                        // no decoupling needed when 
                        // pipeline is already split at this name
                        return next;
                    }
                    if (!IntegratedPipelineContext.VerifyStageOrder(
                        name, stage.Name))
                    {
                        // Stage markers added out of order will be ignored.
                        // Out of order stages/middleware 
                        // may be run earlier than expected.
                        // TODO: LOG
                        return next;
                    }
                    stage.EntryPoint = next;
                    stage = new IntegratedPipelineBlueprintStage
                    {
                        Name = name,
                        NextStage = stage,
                    };
                    onStageCreated(stage);
                    return (AppFunc)IntegratedPipelineContext.ExitPointInvoked;
                };
                app.Use(decoupler);
            };
            app.Properties[Constants.IntegratedPipelineStageMarker] 
                = stageMarker;
            app.Properties[Constants.BuilderDefaultApp] =
                (Func<IDictionary<string, object>, Task>)
                IntegratedPipelineContext.DefaultAppInvoked;
        }
    }
}

Как видно из вышеприведённого кода, модуль не подписывается на события приложения HttpApplication, а инициализирует конвейер на стадии загрузки и инициализации модулей.

for (int i = 0; i < this._moduleCollection.Count; i++)
{
    this._currentModuleCollectionKey = this._moduleCollection.GetKey(i);
    IHttpModule module = this._moduleCollection.Get(i);
    ModuleConfigurationInfo info = _moduleConfigInfo[i];
    module.Init(this);
    this.ProcessEventSubscriptions(out notification, out notification2);
    if ((notification != 0) || (notification2 != 0))
    {
        this.RegisterIntegratedEvent(appContext, info.Name, notification,
			notification2, info.Type, info.Precondition, false);
    }
}

А поскольку экземпляры HttpApplication создаются фабрикой HttpApplicationFactory и переиспользуются, то и повторное подключение конвейера OWIN не нужно, да и к тому же экземпляр основного типа IntegratedPipelineBlueprint (который и есть, грубо говоря, конвейер OWIN) один единственный на домен приложения (используется статическая ссылка и отложенная инициализация с проверкой на наличие экземпляра последней). Метод InitializeBlueprint

private IntegratedPipelineBlueprint InitializeBlueprint()
{
    IntegratedPipelineBlueprintStage firstStage = null;
    Action<IAppBuilder> startup = OwinBuilder.GetAppStartup();
    OwinAppContext appContext = OwinBuilder.Build(delegate (IAppBuilder builder) {
        EnableIntegratedPipeline(builder, stage => firstStage = stage);
        startup(builder);
    });
    return new IntegratedPipelineBlueprint(appContext, firstStage,
		Utils.NormalizePath(HttpRuntime.AppDomainAppVirtualPath));
}

создаёт экземпляр построителя приложения на основе метода конфигурации.

[assembly: Microsoft.Owin.OwinStartup(typeof(Startup))]
 
namespace SignalROwinIISApplication
{
    public class Startup
    {
        public void Configuration(IAppBuilder appBuilder)
        {
            appBuilder.MapSignalR();
 
            var httpConfiguration = new HttpConfiguration();
 
            httpConfiguration.Formatters.Clear();
            httpConfiguration.Formatters.Add(new JsonMediaTypeFormatter());
 
            httpConfiguration.Formatters.JsonFormatter.SerializerSettings = 
                new JsonSerializerSettings
            {
                ContractResolver = new CamelCasePropertyNamesContractResolver()
            };
 
            httpConfiguration.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional });
 
            appBuilder.UseWebApi(httpConfiguration);
        }
    }
}

Тем самым подключаются два Модуля OWIN: SignalR и WebAPI. Именно они будут обрабатывать запросы поступающие к этим двум фреймворкам.

Ну а остальные запросы, например к Web Forms или MVC, будут идти как обычно, в обход спецификации OWIN, так как они эту спецификацию не реализуют. В данной статье я попытался показать насколько усложняется конвейер IIS/ASP.NET при использовании спецификации OWIN. А он как уже известно, и так устроен очень непросто.