Комментарии 39
Никто до сих пор не сказал зачем и кому все это реально нужно, кроме гипотетического желания запустить веб-приложение в других ОС.
А разве это уже не плюс? Также теперь не надо зависеть от установленной версии .Net у хостера (не все используют для этого vps еще)
Когда же будет можно подружить ubuntu+nginx+Mono(ASP vNext?)+PostgreSQL.
Видимо мечты скоро сбудутся.
Видимо мечты скоро сбудутся.
Хм, я кстати это момент не понял. Потому что я и раньше ASP.NET приложения запускал на линуксе(отладочный сервер xsp + nginix). Возможно имеется ввиду что теперь это можно будет делать без mono(с Core CLR)
Нет, это всё равно надо будет делать с mono, просто теперь новые версии фреймворка будут тестироваться на работоспособность в mono самим Майкрософтом.
Пока с этим не все до конца понятно. Но на текущий момент ситуация такова.
KLR запустить полностью в режиме Core CLR можно под Win 8.
Во всех остальных случаях приложения запускаются поверх .net desktop, либо mono и это не Core CLR.
Убедиться в этом можно распаковав любой klr проект коммандой — kpm restore. В обоих случаях грузиться «десктопный» mscorlib.
Реализация Core CLR Native Host пока отсутствует для Linux/OSX.
KLR запустить полностью в режиме Core CLR можно под Win 8.
Во всех остальных случаях приложения запускаются поверх .net desktop, либо mono и это не Core CLR.
Убедиться в этом можно распаковав любой klr проект коммандой — kpm restore. В обоих случаях грузиться «десктопный» mscorlib.
Реализация Core CLR Native Host пока отсутствует для Linux/OSX.
Кто-нибудь знает/понимает зачем разработчики решили отказаться от старого доброго web.config'a(и заодно мощного XML'a) в пользу config.json(c менее мощным JSON)?
НЛО прилетело и опубликовало эту надпись здесь
Причем здесь фатальный недостаток?
Насколько я понимаю, package.json это в некотором смысле калька с NodeJS.
Но мне действительно интересно, почему решили отказаться от XML-based конфигов. Они повсеметно распространены в мире .NET. Зарекомендовали себя неплохо(возможно только излишне многословны). И причин отказа от них я не вижу, потому и спрашиваю.
Насколько я понимаю, package.json это в некотором смысле калька с NodeJS.
Но мне действительно интересно, почему решили отказаться от XML-based конфигов. Они повсеметно распространены в мире .NET. Зарекомендовали себя неплохо(возможно только излишне многословны). И причин отказа от них я не вижу, потому и спрашиваю.
НЛО прилетело и опубликовало эту надпись здесь
Довольно таки жуткое детище, я вам скажу. У меня при каждом открытии глаза вытекают от количества элементов. Json же более лаконичный и его проще редактировать в %favorite_editor%, на чем MS акцентировало внимание. Мне лично это все кажется хорошим шагом. Давно мечтаю удаляить студию и пересесть на легковесный редактор. Сейчас же этот процесс во много затруднен, без толпы утилит для правки web.config/csproj/etc.
Понимаете… фатальный недостаток — это про велосипеды, это если вместо json был бы mson (ну, например, Microsoft Object Notation).
новый формат конфигурации обусловлен как минимум тем, что полностью изменили концепцию, рантайм. старый был уже давно перегружен, с ужасными классами для работы со стандартной конфигурацией. а поскольку все-равно необходимо делать что-то новое — вот и решили заодно и выбрать подходящий формат, минималистичный.
НЛО прилетело и опубликовало эту надпись здесь
>>почему решили отказаться от XML-based конфигов
То чувство, когда ты не знаешь что выбрать: аттрибут или вложенный элемент…
То чувство, когда ты не знаешь что выбрать: аттрибут или вложенный элемент…
Могу предположить, что дело в новом подходе к конфигурации приложения, который будет более ориентирован на Fluent стиль в Startup.cs.
С Roslyn у разработчиков теперь не IL библиотеки, а исходные cs файлы — редактируем код с полной поддержкой intellisense, строгим контролем типов, после просто сохраняем и перезапускаем веб-приложение, без промежуточной компиляции в сборку всего проекта и передиплоя.
В отличии от xml конфигурации — без надобности добавления Config Sections. Добавить reference все же проще.
json конфигурация поддерживает json-схему, спец символы. Новая ConfigurationModel поддерживает и xml источники.
С Roslyn у разработчиков теперь не IL библиотеки, а исходные cs файлы — редактируем код с полной поддержкой intellisense, строгим контролем типов, после просто сохраняем и перезапускаем веб-приложение, без промежуточной компиляции в сборку всего проекта и передиплоя.
В отличии от xml конфигурации — без надобности добавления Config Sections. Добавить reference все же проще.
json конфигурация поддерживает json-схему, спец символы. Новая ConfigurationModel поддерживает и xml источники.
давным-давно кодил на php, в последнее время занимаюсь разработкой на asp.net и вот несколько удивил подход нового компилятора.
В php я имел дело с файлами исходного кода, в asp.net имею дело со сборками. И тут тебе как гром среди ясного неба: в asp.net тоже теперь исходники безо всяких сборок благодаря новому компилятору Roslyn. Даже не знаю, шаг ли это вперед или просто такое забавное совпадение, ограничивающееся только поверхностым сходством.
И тут сразу же вопрос: как дела обстоят с совместимостью с обычными сборками? Связывание с ними происходит перед построением IL-кода новым компилятором? Т.е. как в случае с View в MVC: тоже имеем дело сперва с исходниками, которые потом самим IIS преобразуются в сборку?
и ещё один вопрос не в этой ветке: такие гибкие механизмы как трансформации нам дадут сразу же или придётся ждать следующей версии?
В php я имел дело с файлами исходного кода, в asp.net имею дело со сборками. И тут тебе как гром среди ясного неба: в asp.net тоже теперь исходники безо всяких сборок благодаря новому компилятору Roslyn. Даже не знаю, шаг ли это вперед или просто такое забавное совпадение, ограничивающееся только поверхностым сходством.
И тут сразу же вопрос: как дела обстоят с совместимостью с обычными сборками? Связывание с ними происходит перед построением IL-кода новым компилятором? Т.е. как в случае с View в MVC: тоже имеем дело сперва с исходниками, которые потом самим IIS преобразуются в сборку?
и ещё один вопрос не в этой ветке: такие гибкие механизмы как трансформации нам дадут сразу же или придётся ждать следующей версии?
По факту компиляция в .NET так и остались на месте, просто компиляция происходит «на лету» и ждать пересборки всех dll'ок не нужно.
Фишка с пересборкой по F5 (без передеплоя), как я понял, это фишка 14ой студии, потому что «в блокноте» у меня такой фокус провернуть не получилось.
Фишка с пересборкой по F5 (без передеплоя), как я понял, это фишка 14ой студии, потому что «в блокноте» у меня такой фокус провернуть не получилось.
Это не совсем фиша студии, просто сборка уже собрана в памяти K Native Host — KLR.exe.
В зависимости от того насколько серьезны изменения в коде(в частности Reference), может потребовать от обычного перезапуска проекта в текущем процессе приложения хоста K
И аж до запуска нового процесса k.exe, выбора активной KRE, распаковки приложения и его запуска.
Больше информации тут:
github.com/aspnet/Home/wiki/KRuntime-structure
В зависимости от того насколько серьезны изменения в коде(в частности Reference), может потребовать от обычного перезапуска проекта в текущем процессе приложения хоста K
И аж до запуска нового процесса k.exe, выбора активной KRE, распаковки приложения и его запуска.
Больше информации тут:
github.com/aspnet/Home/wiki/KRuntime-structure
И тут сразу же вопрос: как дела обстоят с совместимостью с обычными сборками?
Обратная совместимо имеется, проект можно билдить и запускать в режиме .NET Desktop, с текущим фреймворком установленым на системе, указывая referenсe в project.json. Кроме того в project.json можно указывать не только сборки, но и просто cs файлы, что будут включены и скомпилированы в рамках построения текущего проекта.
С View все было несколько по-другому, сейчас не надо придумывать механизма кеширования динамически скомпилированных razor view — все в памяти происходит.
Не совсем понял последний вопрос про трансформации.
В случае с asp.net проектами можно создать несколько трансформаций Web.config для каждой конфигурации. При деплое трансформация применялась к исходному Web.config (анпример, prod-база вместо dev) и уже в таком виде он публиковался на сервер/в пакет.
Это уже больше к новой версии студии вопрос, нежели к ASP.NET или K — гибкие механизмы трансформации конфигов под целевую среду.
Учитывая, что пока даже свойства проекта и поддержка через gui project.json не реализована полноценно, пока еще рано говорить об этом.
Учитывая, что пока даже свойства проекта и поддержка через gui project.json не реализована полноценно, пока еще рано говорить об этом.
С учетом того, что я увидел здесь: www.asp.net/vnext/overview/aspnet-vnext/getting-started-with-aspnet-vnext-and-visual-studio.
Json-конфиги добавляются ручками в коде. Соответственно можно на уровне директив препроцессора добавлять разные JSON-файлы которые будут перезаписывать данные из основного. Но это чисто предположения.
Скорее всего сделают и механизм трансформаций
Json-конфиги добавляются ручками в коде. Соответственно можно на уровне директив препроцессора добавлять разные JSON-файлы которые будут перезаписывать данные из основного. Но это чисто предположения.
Скорее всего сделают и механизм трансформаций
На уровне кода это было реализовано еще проще и гибче чем использование директив компилятора.
Startup.cs — условная конвенция.
В config.json веб-хоста(Microsoft.AspNet.Hosting) мы можем указать ключ:
env: 'Dev'
При запуске приложения сервер сначала будет искать класс StartupDev.cs и только потом Startup.cs для построения веб-приложения.
Если ключ будет переопределен в консоли при передаче параметров в запуска приложения хоста, например 'env:QA'
он будет приоритетней чем config.json. Соотвественно сначала будет произведен поиск StartupQA, если его нету, Startup.cs.
Для каждой среды надо создать свой Startup.cs класс, в котором и будет идти специфическая для среды конфигурация для веб приложения.
Startup.cs — условная конвенция.
В config.json веб-хоста(Microsoft.AspNet.Hosting) мы можем указать ключ:
env: 'Dev'
При запуске приложения сервер сначала будет искать класс StartupDev.cs и только потом Startup.cs для построения веб-приложения.
Если ключ будет переопределен в консоли при передаче параметров в запуска приложения хоста, например 'env:QA'
он будет приоритетней чем config.json. Соотвественно сначала будет произведен поиск StartupQA, если его нету, Startup.cs.
Для каждой среды надо создать свой Startup.cs класс, в котором и будет идти специфическая для среды конфигурация для веб приложения.
Мне кажется json читается человеком легче, чем XML. Системой он читается (обрабатывается) также быстрее.
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. Обзор vNext на TechEd channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DEV-B385#fbid.
2. Как устроено внутри vNext на TechEd channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DEV-B411
Какие то инструменты для миграции существуют?
Текущий проект написан на ASP.NET MVC 3 но очень хотелось бы на vNext перейти.
Текущий проект написан на ASP.NET MVC 3 но очень хотелось бы на vNext перейти.
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, то скорее всего придется переносить что-то и руками, особенно если используете возможности отсутствующие в новой редакции. Пока деталей по тулзам нету, но сам факт их наличия положительный момент.
Конечно, непривычно, но по сути в написании MVC проектов ничего серьезного не изменилось.
Только вот JSON выглядит как-то не так, есть у MS такая особенность забивать и резко переходить на что-то другое — так гляди еще и в XAML заменят на что-то json подобное в WPF.
Только вот JSON выглядит как-то не так, есть у MS такая особенность забивать и резко переходить на что-то другое — так гляди еще и в XAML заменят на что-то json подобное в WPF.
>>MS такая особенность забивать и резко переходить на что-то другое
Тут на самом деле довольно таки двубокая ситуация, на мой взгляд…
Плюсы:
— Никакого legacy
— Всякие плюшки
— Обычно (!) становится лучше\проще
Минусы:
— Никакого legacy
— Ничего не понятно, приходится читать (не всегда)
Я в коей мере даже за замену XAML на JSON, слишком он многословен и выглядит не очень (расставлять переносы для с десяток аттрибутов меня задолбало). Переучиваться в общем то и не надо, да и, уверен, всегда будет возможность использовать XAML, парсер ведь отделен от WPF.
Тут на самом деле довольно таки двубокая ситуация, на мой взгляд…
Плюсы:
— Никакого legacy
— Всякие плюшки
— Обычно (!) становится лучше\проще
Минусы:
— Никакого legacy
— Ничего не понятно, приходится читать (не всегда)
Я в коей мере даже за замену XAML на JSON, слишком он многословен и выглядит не очень (расставлять переносы для с десяток аттрибутов меня задолбало). Переучиваться в общем то и не надо, да и, уверен, всегда будет возможность использовать XAML, парсер ведь отделен от WPF.
В примерах все весело запускают k web а вот как его запустить на IIS информации ноль.
+1
Ну так установите студию 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 — стандартно либо через нативный модуль.
Кстати, теперь все переименовали:
k -> dotnet
kre -> xre (.Net cross-platform runtime engine)
kvm -> dotne sdk
kpm -> nuget
www.youtube.com/playlist?list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF (последнее видео от 12-01-2015).
В том же видео рассказывают как оно внутренне будет работать на IIS — стандартно либо через нативный модуль.
Вы своими глазами видели там запуск через IIS? Что-то среди таргетсов не наблюдаю полный IIS, только экспресс.
мне полный IIS на машине не нужен, а вот ответ на вопрос:
stackoverflow.com/questions/27325264/asp-net-5-project-hosting-on-iis
stackoverflow.com/questions/27325264/asp-net-5-project-hosting-on-iis
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция веб-фреймворков Microsoft. ASP.NET vNext