У каждого свой путь знакомства с ASP.NET 5. И чем раньше его начать, тем лучше. Разобраться в «ASP.NET 5» необходимо всем, кто занимается разработкой на платформе .NET. Т.к. «ASP.NET 5» это не совсем о веб. Точнее не только о веб. Просмотрев N-ое количество видео и прочитав еще больше количество блогов (документация еще не готова) возникло непреодолимое желание где-то что-то написать.
ASP.NET 5 — это не просто очередная версия ASP.NET в рамках .NET Framework. На самом деле, это новый Framework без CLR (которая ставится отдельно) и без BCL (которая превратилась в набор NuGet-пакетов, которые ставятся из nuget.org).
Отделение CLR от Framework сделано через хитрую штуку под названием DNX — .NET Execution Environment. Больше нет разделения на design-time и run-time. Больше нет отдельных зависимостей в сборках, между проектами и между nuget-пакетами. Теперь есть просто зависимость. Это может быть проект (в исходниках), сборка (dll) или Nuget-пакет. Для проекта в исходниках его зависимости указываются в файле project.json, который не зависит от платформы и используемой IDE. При разрешении зависимости (не важно в runtime или в design-time) она либо просто загружается (сборка), либо скачивается (nuget), либо компилируется Roslyn’ом (исходники). Т.о. с помощью Roslyn поддерживается компиляция “на лету”. Например, можно в развернутом приложении заменить зависимый проект на его исходники.
В системе может быть несколько dnx. Для управления ими есть набор скриптов (PowerShell) dnvm — .NET Version Manager. Явно некий аналог NVM (Node Version Manager).
Есть DNX, использующая CLR из полного .NET Framework, есть для Mono и есть для CoreCLR (кросс-платформенной CLR, которая в скором времени помимо Windows будет работать на Linux и MacOS). DNX для CoreCLR включает CLR внутри себя.
Ситуация несколько запутана из-за того очень много новых абревиатур, плюс недавно (накануне dotnetConf) был мощный ребрендинг (последний ли?). Ранее DNX назывался KRE (а хост процесс klr.exe) (в VS CTP6 это все еще так), DNVM — KVM. Был еще KPM (K Package Manager), теперь это просто Nuget.
Поняв, что AspNet5 это не Asp.Net, а новый .NET, шаблон проекта “ASP.NET 5 Console Application” уже не шокирует. Это действительно Console Application под инфраструктурой DNX.
Забавно, что Build проекта в VS по умолчанию не создает никаких dll в папке bin, как раньше. Можно включить опцию “Produce outputs on build” в настройках проекта VS (да, файл проекта VS все же есть — .kproj, но он теперь опциональный), тогда Build будет создавать dll в папке $solutionDirartifactsbinConsoleApp1Debugaspnet50. Где “aspnet50” — это имя фрейворка или runtime flavor. Помимо aspnet50 есть еще aspnetcore50. Что такое “фреймворк” в контексте DNX не до конца мне понятно. Но, грубо говоря, это множество DNX одного вида: либо на основе CLR из .NET Framework, либо на основе CoreCLR.
Все DNX хранятся в профиле юзера: C:UsersShrike.dnxruntimes
В старых версиях (для VS CTP6 по-прежнему): C:UsersShrike.kruntimes
Там же, кстати, и хранится кэш всех пакетов — .dnxpackages
Видимо, благодаря этому кэшу при редактировании project.json в VS поддерживается intelliSence при редактировании зависимостей:
Увидеть все установленные в системе DNX можно с помощью команды dnvm list. Одна из DNX является “по умолчанию”, ее использует VS, если для проекта явно не задан тип runtime.
Обратим внимание, что билд консольного приложения создает dll, а не exe. А как же его теперь запустить (не из VS)?
Чтобы запустить приложение, его надо опубликовать — делаем Publish из VS. Также это можно сделать из командной строки с помощью dnu publish. При публикации мы указываем publish target. Для консольного приложения сейчас доступен только таргет “File System”. Набор publish targets будет расширяться. Например, для Web-приложения уже доступен Azure Websites. При публикации в File System мы выбираем папку, в которую будет помещен дистрибутив. В ней будет создано:
- bash-скрипт для Linux: ConsoleApp1
- cmd-скрипт для Windows: ConsoleApp1.cmd
- папка approot, внутри папка packages, а внутри:
- папка ConsoleApp1 с приложение
- папка kre-clr-win-x86.1.0.0-beta3 с исполняемой средой (DNX)
Скрипт ConsoleApp1.cmd запускает наше приложение с помощью команды:
@”%~dp0approotpackageskre-clr-win-x86.1.0.0-beta3binklr.exe” — appbase “%~dp0approotsrcConsoleApp1” Microsoft.Framework.ApplicationHost ConsoleApp1 %*
Это что же получается. Дистрибутив программы содержит саму .NET в себе. Точнее содержит DNX. В данном случае используемая DNX использует CLR из глобального .NET на машине. Но приложение можно опубликовать, используя DNX для CoreCLR. И тогда, в дистрибутиве будет вообще всё (т.к. DNX для CoreCLR содержит саму CLR), что требуется приложению.
Подробней про DNX и прочий ужас рантайм в MSDN Mag.
После всего этого, утверждение, что ASP.NET 5 не зависит от System.Web, вообще кажется очевидным. ASP.NET 5 не зависит ни от чего. ASP.NET 5 это новый runtime и огромное количество NuGet-пакетов, содержащих все то, что было в BCL Framework’а (только переписанное начисто). Множество пакетов Microsoft.AspNet.* можно условно объединить в “ASP.NET 5”.
Автор: Shrike
