Пользователь
0,0
рейтинг
17 апреля 2015 в 14:33

Разработка → Знакомство с ASP.NET 5

ASP*, .NET*
У каждого свой путь знакомства с 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 в папке $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 при редактировании зависимостей:
image

Увидеть все установленные в системе 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 и прочий ужас рантайм в MSDN Mag.

После всего этого, утверждение, что ASP.NET 5 не зависит от System.Web, вообще кажется очевидным. ASP.NET 5 не зависит ни от чего. ASP.NET 5 это новый runtime и огромное количество NuGet-пакетов, содержащих все то, что было в BCL Framework’а (только переписанное начисто). Множество пакетов Microsoft.AspNet.* можно условно объединить в “ASP.NET 5”.
Shrike @Shrike
карма
9,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (30)

  • +2
    Например, можно в развернутом приложении заменить зависимый проект на его исходники.
    На самом деле в запущенном приложении нельзя. Типы уже обработаны JIT и лежат в памяти, на них есть ссылки, у них есть состояние и т. п. Там ограничений ещё больше чем у Edit&Continue в студийном отладчике.
    • 0
      Касательно «запущенного» приложения врать не буду, не проверял.
      Но при запуске из студии изменения подхватываются сразу, без компиляции. Возможно это студия добавляет какой-то вотчер. Но факт в том, что есть загрузчик проекта/зависимости на основе Roslyn'a. Раньше был только загрузчик сборок с IL.
      В «развернутое» приложении можно очень легко подложить исходники самого AspNet5 и дебагать. Для это надо просто скопировать папку проекта рядом со своим и все.
      • 0
        Студия даже Razor-овские вьюшки не всегда после запуска поменять даёт (по крайней мере у меня CTP6 просто блокирует редактор в ряде случаев), не то что весь стек ASP.NET без перезапуска заменить
  • +2
    утверждение, что ASP.NET 5 не зависит от System.Web, вообще кажется очевидным
    Проблема с «зависимостью» от System.Web была не в том, что подключается сборка из GAC, а в том, что весь код был завязан на System.Web.HttpRuntime, который в плане замены веб-сервера и вообще контроля над происходящим убог донельзя. Сейчас там OWIN. Переход с HttpRuntime на OWIN ортогонален всему остальному.
    • +1
      Строго говоря OWIN в AspNet5 нет. OWIN это интерфейс, на котором основывался проект Katana в частности, легший в основу AspNet5. Все очень похоже безусловно.
      Я не говорил, что проблема зависимости от System.Web в GAC. Конечно, проблема в зависимости от IIS. Но в рамках AspNet5 (о чем я и питался написать) сделано намного больше, чем просто «отвязать asp.net от IIS». Фактически товарищи испекли новый .NET.
      • 0
        Строго говоря OWIN в AspNet5 нет
        1. Можно использовать OWIN-middleware
        2. Можно использовать OWIN-сервера (пример прослойки для NOwin)

        3. Внутри всех этих строго типизированных штук совместимость с OWIN
        • 0
          Да, есть адаптеры OWIN к AspNet5. И AspNet5 к OWIN. Но по факту это разные вещи.
  • 0
    Выглядит интересно.
    Есть (будут ли) какие-то автоматические способы перевода текущих приложений c ASP.NET MVC 5 на ASP.NET 5?
    Или там и текущая реализация заведётся без проблем?
    • +4
      Есть пакет Microsoft.AspNet.Mvc.WebApiCompatShim, который облегчает портацию WebApi. Подробней тут.
      Майкрософт говорит, что все очень легко портируется с MVC5 на MVC6. По факту все сильно зависит от приложения. Чем больше инфраструктурных вещей в нем, тем сложнее. Я вторую неделю портирую и ни конца ни края. Вообще номер версии 6 не должен обманывать. Фактически это другой фреймворк. Там все по-другому. Очень похоже, но по-другому.
      Начать стоит отсюда: aspnet.readthedocs.org/en/latest/index.html
      Самое печально, что берешь какой-то тип, типа FormDataCollection или HttpCookieCollection (который напрямую не связан с изменившимися концепциями — там хоть понятно куда бежать), а его нет. И что вместо него не понятно. Правда когда разбираешь, понимаешь, что теперь все лучше. Но от этого не легче ))
  • +2
    Чет мне кажется не успеют они все это запилить к релизу 15й студии. Судя по количеству багов в проекте Roslyn на гитхабе и вообще активности, еще годик-другой придется фигачить, уж больно кардинально все поменяли.
    • +1
      Ну в принципе не страшно, если не успеют. Теперь всё идет как отдельные nuget-пакеты, которые обновляются независимо от студии. Но вообще да, фундаментальность изменений поражает.
    • 0
      У меня сейчас на CTP6/vnext_beta3 небольшой пилотный проектик, в принципе, уже вполне можно жить, если с нуля писать сразу на нём.
      • 0
        А мы попробовали и поняли, что не выйдет пока у нас с vnext любви. Слишком мало пока либ эту штуку поддерживают, а докер контейнеры слишком часто падают. Поэтому пока на 4.6 с верой в будущее
        • 0
          Так ведь если не использовать aspnetcore50, а использовать полный .NET(aspnet50) то можно использовать любые либы, разве не так?
          • 0
            Там все равно по-моему не все гладко, у нас не заработал LightInject, еще что то. В общем пока в продакшн мы это не потащим
            • 0
              Любопытно, я думал все будет запускаться с полпинка на полном фрейморке. Свое приложение пока не пробовал. И, да, для продакшена еще рано.
              • +1
                Маленькая деталь — web.config больше нет ))
                Ну или так скажем: хостинг не читает его, т.о. ConfigurationManager не видит ничего из него.
                Вот тут на SO человек воркэраунд предлагает.
      • 0
        А расскажете ли с нуля для новичков?
        А то я студию поставил, посмотрел, понял что все изменилось кардинально, испугался и убег ждать релиза и официального нового гайда, хоть по блиотеке книг, хоть дисков…
  • 0
    Удалось кому-нибудь уже запустить на линуксе?
    PS: Название ASP NET 5 конечно совершенно дурацкое.
    • 0
      Да, народ во всю запускает на 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 )) )
      • 0
        Mono не считается, он давно работает. Я имел ввиду coreclr.
        • 0
          А. Без Mono пока кажется еще не пашет.
          Хотя в репозитории coreclr уже видно, что билд под Linux проходит…
          • +1
            Там мало что на линуксе собирается, mscorlib и corefx (собственно BCL) пока собирается на винде и копируется в линукс.
            Проблема в том что собранный хеловорд сыпет ошибками и в винде и в линуксе Unable to load DLL 'api-ms-win-core-processenvironment-l1-1-0.dll'. Это т.н. api sets, которые появляются только с Win8.
            Видимо пока не сделали полный билд на линуксе где то все застревает в зависимостях от OS и студии, хотя об этом не написано и это совсем не очевидно.
            Зато ошибка и колстэк эквиваленты в разных ОС :)
            • +9
              Одна и та же ошибка на разные ОС — не это ли обещанная кросс-платформенность! ))
        • 0
          На coreclr + kestrel (это web сервер) запускается.
          • 0
            Только не для MacOS X 64bit
  • 0
    Листинг состава пакета «hello world» pastebin.com/RkHhTUCw
    ~300 файлов 50МБ и это не линки
    • 0
      Как-то странно ты считаешь. Я вижу 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.
      • 0
        Я особо не мудрствовал в подсчете:
        get-childitem -Recurse |? {$_.Attributes -notcontains 'Directory'} | Measure-Object -property Length -sum
  • 0
    Все DNX хранятся в профиле юзера: C:\Users\Shrike\.dnx\runtimes
    В старых версиях (для VS CTP6 по-прежнему): C:\Users\Shrike\.k\runtimes

    rbenv, virtualenv и сейчас наконец присоединяется .net

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