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 в папке $solutionDir\artifacts\bin\ConsoleApp1\Debug\aspnet50\. Где “aspnet50”?—?это имя фрейворка или runtime flavor. Помимо aspnet50 есть еще aspnetcore50. Что такое “фреймворк” в контексте DNX не до конца мне понятно. Но, грубо говоря, это множество DNX одного вида: либо на основе CLR из .NET Framework, либо на основе CoreCLR.
Все DNX хранятся в профиле юзера: C:\Users\Shrike\.dnx\runtimes
В старых версиях (для VS CTP6 по-прежнему): C:\Users\Shrike\.k\runtimes
Там же, кстати, и хранится кэш всех пакетов?—?\.dnx\packages\
Видимо, благодаря этому кэшу при редактировании 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 запускает наше приложение с помощью команды:
@”%~dp0approot\packages\kre-clr-win-x86.1.0.0-beta3\bin\klr.exe” — appbase “%~dp0approot\src\ConsoleApp1” Microsoft.Framework.ApplicationHost ConsoleApp1 %*
Это что же получается. Дистрибутив программы содержит саму .NET в себе. Точнее содержит DNX. В данном случае используемая DNX использует CLR из глобального .NET на машине. Но приложение можно опубликовать, используя DNX для CoreCLR. И тогда, в дистрибутиве будет вообще всё (т.к. DNX для CoreCLR содержит саму CLR), что требуется приложению.
Подробней про DNX и прочий
После всего этого, утверждение, что ASP.NET 5 не зависит от System.Web, вообще кажется очевидным. ASP.NET 5 не зависит ни от чего. ASP.NET 5 это новый runtime и огромное количество NuGet-пакетов, содержащих все то, что было в BCL Framework’а (только переписанное начисто). Множество пакетов Microsoft.AspNet.* можно условно объединить в “ASP.NET 5”.
Комментарии (30)
kekekeks
17.04.2015 16:36+2утверждение, что ASP.NET 5 не зависит от System.Web, вообще кажется очевидным
Проблема с «зависимостью» от System.Web была не в том, что подключается сборка из GAC, а в том, что весь код был завязан на System.Web.HttpRuntime, который в плане замены веб-сервера и вообще контроля над происходящим убог донельзя. Сейчас там OWIN. Переход с HttpRuntime на OWIN ортогонален всему остальному.
Shrike Автор
17.04.2015 17:03+1Строго говоря OWIN в AspNet5 нет. OWIN это интерфейс, на котором основывался проект Katana в частности, легший в основу AspNet5. Все очень похоже безусловно.
Я не говорил, что проблема зависимости от System.Web в GAC. Конечно, проблема в зависимости от IIS. Но в рамках AspNet5 (о чем я и питался написать) сделано намного больше, чем просто «отвязать asp.net от IIS». Фактически товарищи испекли новый .NET.kekekeks
17.04.2015 17:10Строго говоря OWIN в AspNet5 нет
- Можно использовать OWIN-middleware
- Можно использовать OWIN-сервера (пример прослойки для NOwin)
Внутри всех этих строго типизированных штук совместимость с OWINShrike Автор
17.04.2015 17:16Да, есть адаптеры OWIN к AspNet5. И AspNet5 к OWIN. Но по факту это разные вещи.
Dim0FF
17.04.2015 18:00Выглядит интересно.
Есть (будут ли) какие-то автоматические способы перевода текущих приложений c ASP.NET MVC 5 на ASP.NET 5?
Или там и текущая реализация заведётся без проблем?Shrike Автор
17.04.2015 18:10+4Есть пакет Microsoft.AspNet.Mvc.WebApiCompatShim, который облегчает портацию WebApi. Подробней тут.
Майкрософт говорит, что все очень легко портируется с MVC5 на MVC6. По факту все сильно зависит от приложения. Чем больше инфраструктурных вещей в нем, тем сложнее. Я вторую неделю портирую и ни конца ни края. Вообще номер версии 6 не должен обманывать. Фактически это другой фреймворк. Там все по-другому. Очень похоже, но по-другому.
Начать стоит отсюда: aspnet.readthedocs.org/en/latest/index.html
Самое печально, что берешь какой-то тип, типа FormDataCollection или HttpCookieCollection (который напрямую не связан с изменившимися концепциями — там хоть понятно куда бежать), а его нет. И что вместо него не понятно. Правда когда разбираешь, понимаешь, что теперь все лучше. Но от этого не легче ))
Scratch
17.04.2015 18:07+2Чет мне кажется не успеют они все это запилить к релизу 15й студии. Судя по количеству багов в проекте Roslyn на гитхабе и вообще активности, еще годик-другой придется фигачить, уж больно кардинально все поменяли.
Shrike Автор
17.04.2015 18:13+1Ну в принципе не страшно, если не успеют. Теперь всё идет как отдельные nuget-пакеты, которые обновляются независимо от студии. Но вообще да, фундаментальность изменений поражает.
kekekeks
17.04.2015 18:18У меня сейчас на CTP6/vnext_beta3 небольшой пилотный проектик, в принципе, уже вполне можно жить, если с нуля писать сразу на нём.
Scratch
17.04.2015 18:51А мы попробовали и поняли, что не выйдет пока у нас с vnext любви. Слишком мало пока либ эту штуку поддерживают, а докер контейнеры слишком часто падают. Поэтому пока на 4.6 с верой в будущее
firestarter
17.04.2015 20:02Так ведь если не использовать aspnetcore50, а использовать полный .NET(aspnet50) то можно использовать любые либы, разве не так?
Scratch
17.04.2015 20:05Там все равно по-моему не все гладко, у нас не заработал LightInject, еще что то. В общем пока в продакшн мы это не потащим
firestarter
17.04.2015 20:07Любопытно, я думал все будет запускаться с полпинка на полном фрейморке. Свое приложение пока не пробовал. И, да, для продакшена еще рано.
foxmuldercp
17.04.2015 23:35А расскажете ли с нуля для новичков?
А то я студию поставил, посмотрел, понял что все изменилось кардинально, испугался и убег ждать релиза и официального нового гайда, хоть по блиотеке книг, хоть дисков…
Krey
17.04.2015 19:15Удалось кому-нибудь уже запустить на линуксе?
PS: Название ASP NET 5 конечно совершенно дурацкое.Shrike Автор
17.04.2015 19:24Да, народ во всю запускает на Mono.
Вот на dotnetConf сессия хорошая была: channel9.msdn.com/Events/dotnetConf/2015/ASPNET-5-Deep-Dive
Собственно уже есть официальный Docker контейнер с AspNet5: blogs.msdn.com/b/webdev/archive/2015/01/14/running-asp-net-5-applications-in-linux-containers-with-docker.aspx
Хорошие посты были у чувака тут: blog.markrendle.net/fun-with-asp-net-5-linux-docker-part-3/ (но сейчас блог засуспенжен — кончился триал на ghost.org )) )Krey
17.04.2015 19:29Mono не считается, он давно работает. Я имел ввиду coreclr.
Shrike Автор
17.04.2015 19:53А. Без Mono пока кажется еще не пашет.
Хотя в репозитории coreclr уже видно, что билд под Linux проходит…Krey
17.04.2015 20:05+1Там мало что на линуксе собирается, mscorlib и corefx (собственно BCL) пока собирается на винде и копируется в линукс.
Проблема в том что собранный хеловорд сыпет ошибками и в винде и в линуксе Unable to load DLL 'api-ms-win-core-processenvironment-l1-1-0.dll'. Это т.н. api sets, которые появляются только с Win8.
Видимо пока не сделали полный билд на линуксе где то все застревает в зависимостях от OS и студии, хотя об этом не написано и это совсем не очевидно.
Зато ошибка и колстэк эквиваленты в разных ОС :)Shrike Автор
17.04.2015 20:11+9Одна и та же ошибка на разные ОС — не это ли обещанная кросс-платформенность! ))
Krey
18.04.2015 00:42Листинг состава пакета «hello world» pastebin.com/RkHhTUCw
~300 файлов 50МБ и это не линки
Fduch
23.04.2015 02:23Как-то странно ты считаешь. Я вижу 15-мегабайтный пакет KRE-CoreCLR-amd64.1.0.0-beta1.nupkg, а почти всё остальное — он же, но распакованный.
Проверил сам:
35 файлов. 12 мегабайт.
>ls -ltR
.:
total 2
drwxr-xr-x 4 Ark Administrators 0 Apr 23 02:18 approot
-rwxr-xr-x 1 Ark Administrators 621 Apr 23 02:18 ConsoleApp2
-rw-r--r-- 1 Ark Administrators 160 Apr 23 02:18 ConsoleApp2.cmd
./approot:
total 1
drwxr-xr-x 3 Ark Administrators 0 Apr 23 02:18 src
drwxr-xr-x 3 Ark Administrators 0 Apr 23 02:18 packages
-rw-r--r-- 1 Ark Administrators 147 Apr 23 02:18 global.json
./approot/src:
total 4
drwxr-xr-x 3 Ark Administrators 4096 Apr 23 02:18 ConsoleApp2
./approot/src/ConsoleApp2:
total 5
drwxr-xr-x 3 Ark Administrators 0 Apr 23 02:18 Properties
-rw-r--r-- 1 Ark Administrators 310 Apr 23 02:18 ConsoleApp2.kproj.user
-rw-r--r-- 1 Ark Administrators 1493 Apr 23 02:18 ConsoleApp2.kproj
-rw-r--r-- 1 Ark Administrators 232 Apr 23 02:15 Program.cs
-rw-r--r-- 1 Ark Administrators 322 Apr 23 02:15 project.json
./approot/src/ConsoleApp2/Properties:
total 4
drwxr-xr-x 2 Ark Administrators 4096 Apr 23 02:18 PublishProfiles
./approot/src/ConsoleApp2/Properties/PublishProfiles:
total 6
-rw-r--r-- 1 Ark Administrators 995 Apr 23 02:18 FS.pubxml
-rw-r--r-- 1 Ark Administrators 488 Apr 23 02:18 FS.pubxml.user
-rw-r--r-- 1 Ark Administrators 3239 Apr 23 02:18 FS-publish.ps1
./approot/packages:
total 4
drwxr-xr-x 3 Ark Administrators 4096 Apr 23 02:18 kre-clr-win-x86.1.0.0-beta3
./approot/packages/kre-clr-win-x86.1.0.0-beta3:
total 3070
drwxr-xr-x 3 Ark Administrators 8192 Apr 23 02:18 bin
-rw-r--r-- 1 Ark Administrators 3134418 Feb 5 16:53 kre-clr-win-x86.1.0.0-beta3.nupkg
-rw-r--r-- 1 Ark Administrators 724 Feb 5 16:23 kre-clr-win-x86.1.0.0-beta3.nuspec
./approot/packages/kre-clr-win-x86.1.0.0-beta3/bin:
total 7566
drwxr-xr-x 5 Ark Administrators 4096 Apr 23 02:18 lib
-rwxr-xr-x 1 Ark Administrators 61920 Feb 5 16:14 Microsoft.Framework.ApplicationHost.dll
-rwxr-xr-x 1 Ark Administrators 23008 Feb 5 16:14 Microsoft.Framework.Runtime.Loader.dll
-rwxr-xr-x 1 Ark Administrators 33760 Feb 5 16:14 Microsoft.Framework.Runtime.Roslyn.Common.dll
-rwxr-xr-x 1 Ark Administrators 117728 Feb 5 16:14 Microsoft.Framework.Runtime.Roslyn.dll
-rwxr-xr-x 1 Ark Administrators 367072 Feb 5 16:14 Microsoft.Framework.Runtime.dll
-rwxr-xr-x 1 Ark Administrators 42464 Feb 5 16:14 Microsoft.Net.Http.Client.dll
-rwxr-xr-x 1 Ark Administrators 118240 Feb 5 16:14 klr.exe
-rwxr-xr-x 1 Ark Administrators 113120 Feb 5 16:14 kre.clr.dll
-rwxr-xr-x 1 Ark Administrators 52192 Feb 5 16:14 kre.clr.managed.dll
-rwxr-xr-x 1 Ark Administrators 52704 Feb 5 16:14 kre.host.dll
-rwxr-xr-x 1 Ark Administrators 59592 Feb 5 14:59 Microsoft.CodeAnalysis.CSharp.Desktop.dll
-rwxr-xr-x 1 Ark Administrators 3975352 Feb 5 14:59 Microsoft.CodeAnalysis.CSharp.dll
-rwxr-xr-x 1 Ark Administrators 191160 Feb 5 14:59 Microsoft.CodeAnalysis.Desktop.dll
-rwxr-xr-x 1 Ark Administrators 1529512 Feb 5 14:59 Microsoft.CodeAnalysis.dll
-rwxr-xr-x 1 Ark Administrators 507392 Feb 5 14:59 Newtonsoft.Json.dll
-rwxr-xr-x 1 Ark Administrators 230624 Feb 5 14:59 System.Collections.Immutable.dll
-rwxr-xr-x 1 Ark Administrators 256216 Feb 5 14:59 System.Reflection.Metadata.dll
-rw-r--r-- 1 Ark Administrators 471 Feb 5 14:59 k.cmd
-rw-r--r-- 1 Ark Administrators 188 Feb 5 14:59 kpm.cmd
-rw-r--r-- 1 Ark Administrators 289 Feb 5 14:59 kre.clr.config
./approot/packages/kre-clr-win-x86.1.0.0-beta3/bin/lib:
total 0
drwxr-xr-x 2 Ark Administrators 0 Apr 23 02:18 Microsoft.Framework.DesignTimeHost
drwxr-xr-x 2 Ark Administrators 0 Apr 23 02:18 Microsoft.Framework.PackageManager
drwxr-xr-x 2 Ark Administrators 0 Apr 23 02:18 Microsoft.Framework.Project
./approot/packages/kre-clr-win-x86.1.0.0-beta3/bin/lib/Microsoft.Framework.DesignTimeHost:
total 115
-rwxr-xr-x 1 Ark Administrators 117728 Feb 5 16:14 Microsoft.Framework.DesignTimeHost.dll
./approot/packages/kre-clr-win-x86.1.0.0-beta3/bin/lib/Microsoft.Framework.PackageManager:
total 536
-rwxr-xr-x 1 Ark Administrators 548320 Feb 5 16:14 Microsoft.Framework.PackageManager.dll
./approot/packages/kre-clr-win-x86.1.0.0-beta3/bin/lib/Microsoft.Framework.Project:
total 50
-rwxr-xr-x 1 Ark Administrators 51168 Feb 5 16:14 Microsoft.Framework.Project.dll
>du -sh
12M.Krey
27.04.2015 15:49Я особо не мудрствовал в подсчете:
get-childitem -Recurse |? {$_.Attributes -notcontains 'Directory'} | Measure-Object -property Length -sum
stoune
13.05.2015 11:11Все DNX хранятся в профиле юзера: C:\Users\Shrike\.dnx\runtimes
В старых версиях (для VS CTP6 по-прежнему): C:\Users\Shrike\.k\runtimes
rbenv, virtualenv и сейчас наконец присоединяется .net
kekekeks
Shrike Автор
Касательно «запущенного» приложения врать не буду, не проверял.
Но при запуске из студии изменения подхватываются сразу, без компиляции. Возможно это студия добавляет какой-то вотчер. Но факт в том, что есть загрузчик проекта/зависимости на основе Roslyn'a. Раньше был только загрузчик сборок с IL.
В «развернутое» приложении можно очень легко подложить исходники самого AspNet5 и дебагать. Для это надо просто скопировать папку проекта рядом со своим и все.
kekekeks
Студия даже Razor-овские вьюшки не всегда после запуска поменять даёт (по крайней мере у меня CTP6 просто блокирует редактор в ряде случаев), не то что весь стек ASP.NET без перезапуска заменить