Релиз планируется вместе с 2.1 самого .NET Core и ASP.NET Core, где-то в начале-середине лета. По фичам, как я понимаю, цели соответствовать старому SignalR и нету, никакой совместимости тоже не будет. Вот тут можно подробнее почитать — habrahabr.ru/post/338490
Какой критерий по которому можно отнести 1.2 и 2.0 к одному продукту? Название? Есть где-то официальный список обратных несовместимостей — вроде сломалось — A, B, С? (Как это делают все нормальные команды и компании)
Правильно ли я вас понимаю, что разработка в ASP.NET (не Core — да-да, мы так должны всегда оговариваться из-за того, что бардак, который вы не хотите признать) — это не развитие идей ASP.NET? Если там есть развитие идей, то каких? Если это развитие идей ASP.NET — то получается целых два проекта для развития одних и тех же идей? Ну и на сладкое: вот этот вот Blazer вкрутили в какой из продуктов (ASP.NET не Core как я понимаю)? Он будет везде или только кое-где? Какая логика в этом? «Здесь — читать, здесь — не читать, а здесь мы рыбу заворачивали.»
ASP.NET вроде как и не развивается. Там только баги какие-то фиксят. Вся работа идёт только над Core. Blazor пока никто никуда не вкрутил, это сторонний, к тому же экспериментальный, проект. Как и было написано в статье — есть планы предоставить удобную интеграцию для ASP.NET Core проектов. Но для самого Blazor никакой ASP.NET Core не нужен.
Ага, гуглить я умею. Повторю вопрос: Если у меня код пользуется Owin во всю, я смогу его использовать в ASP.NET Core 2.0? Как Microsoft.AspNet.WebApi.Owin связан с Microsoft.AspNetCore.Owin? Как там с портированием кода при переходе с одной библиотеки на другую? Список несовместимостей? Или это тоже разные продукты? Ну вроде как просто называются Owin?
ASP.NET Core 2.0 — это фикс к какому «уже существующем проекту»? Удовлетворит ли он главному критерию фикса — полная обратная совместимость?
Если бы совместимость не ломалась — его бы 1.2, а не 2.0. Разный продукт и потеря совместимости это разные вещи.
Как этот новый очень быстрый продукт соотносится с продуктом ASP.NET (по названии вроде бы почти одно и то же).
Это развите идей ASP.NET. Но это не новая версия. А ещё Java и JavaScript тоже похоже называются =)
А ещё моё любимое: как там в новом проекте с базовой внутренней библиотекой Owin? Если у меня код пользуется Owin во всю, я смогу его использовать в ASP.NET Core 2.0?
И одновременно с вашими предположениями MS шлет привет и мочит, например, новую структуру проектов на базе json, которая пришла вместе с Core. Что не добавляет уверенности относительно их планов на Core.
Я, в общем, про это в конце и написал.
Смысл Mono при наличии Core тоже не понятен. Вроде бы это была открытая реализация .Net. А теперь у нас их две и обе у MS: Mono и Core.
Всё-таки Mono умеет работать там, где не умеет Core, плюс имеет гуёвый и мобильный стэк построенный поверх себя. Быстро перенести Xamarin на Core видимо не получится, поэтому пока что Mono будет жить.
Ну а ASP.Net только ленивый не пинал: каждый, абсолютно каждый релиз — это на самом деле новый продукт, просто называние похоже.
1.1, 2.0, 2.1 — с точки зрения ASP.NET Core разработчика это не особо крупные обновления. Они хорошие, полезные, но это не разные продукты. Миграция с 1.1 на 2.0 занимала иногда считанные минуты. Заменить project.json на csproj это не катастрофа. Вот между бетами и релиз-кандидатами — там да, были сильные изменения.
Но от компании (а не от кучки ночных красноглазиков) требуется именно разбор завалов и очень четкая стратегия. А ее нет.
С другой стороны большая компания может себе позволить одновременно развивать много направлений и обмениваться успешными наработками.
Я, конечно, в Microsoft не работаю, поэтому о таких планах не осведомлён. Однако, насколько я понимаю позиционирование, то Mono уже практически никак не отделяется от Xamarin и будет развиваться именно для присутствия на мобилках и в играх. Ну и вот, видимо в браузере.
.NET Core это кроссплатформа для бэкенда.
.NET Framework это виндовс-приложения.
UWP это такой .NET Core для приложений в сторе с мордой на WPF. Так как WPF стандартизовали, то возможно со временем они UWP и превратят в надстройку над .NET Core.
Простой ASP.NET всё ещё поддерживается, но есть ощущение, что это теперь Legacy, который никак развиваться не будет. Как только они более-менее догонят его по фичам в ASP.NET Core, то начнут совсем активно продвигать миграцию и минимизировать усилия по поддержке.
Но это лишь мои мысли и догадки. Нынешний Microsoft, конечно, неплох, но если вспомнить чехарду с ASP.NET 5, Core, DNX, DNVM и этим всем — чёрт его знает, что они ещё могут выкинуть =)
Если уж на то пошло, то хеллоу ворлд на ангуларе будет не сильно меньше весить =) Как они сами говорят, у них есть реализация Mono на asm.js, но она гораздо медленее wasm-версии, так что выгода в скорости заявляется. Киллер-фича тут в том, что можно прям в браузере юзать библиотеки, авторы которых никогда и не думали, что кто-то их будет так запускать.
Но это ведь не совсем GWT. GWT компилировал Java в JavaScript, что накладывает свои ограничения. А если учесть каким был JavaScript ещё лет 5 назад, то трансляция джавы кажется ещё более ужасной идеей. WebAssembly же этой некий байт-код, на который отлично ложится компиляция того же дотнета или джавы, которые итак в собственный байт-код собираются. Ну и это открытый стандарт, который развивается силами разных компаний. Думаю в данном случае мы получим совсем другой результат. По крайне мере хочется в это верить.
Microsoft понимает, что они нехило так профукали рынки мобильных, кроссплатформенных и веб приложений. Вот и пытаются навёрстывать. Xamarin, .NET Core, TypeScript, а теперь вот и Blazor. Довольно приятно видеть, что в нынешнем Microsoft даже такой just-for-fun проект как Blazor можете получить поддержку и ресурсы для дальнейшего развития.
Если WPF сможет трансформироваться в корректный DOM — почему нет? Главное понимать, что какой бы магией это не казалось, запускается оно всё в браузере и должно жить по его правилам.
Я не сомневаюсь что у вас есть какие-то проблемы, но у нас вся разработка идёт через Docker for Windows и не могу сказать что мы как-то страдаем от скорости дисковой системы. Учитывая, что затем развёртка на прод идёт также в контейнерах, мы получаем максимально идентичное окружение у разработчиков.
Allowing a trailing comma in function calls will make it more convenient to append arguments in many contexts where it is common to call a function with lots of arguments; especially variadic functions.
«especially», но прям про ограничение я нигде не вижу.
Разве это проблема? Зато сразу видно, что запятая не была забыта. А вот при чтении кода с этой «лишней» запятой как-то не сразу очевидно что происходит.
public function foo($a, $b, $c = 3);
foo(1, 2); // всё понятно
foo(1, 2, ); // неочевидно, может быть теперь в c придёт null?
Общий код? Общий API с частичной несовместимостью? Что вам ещё нужно? Список несовместимостей очевидно есть, вместе с гайдом по миграции — docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x
ASP.NET вроде как и не развивается. Там только баги какие-то фиксят. Вся работа идёт только над Core. Blazor пока никто никуда не вкрутил, это сторонний, к тому же экспериментальный, проект. Как и было написано в статье — есть планы предоставить удобную интеграцию для ASP.NET Core проектов. Но для самого Blazor никакой ASP.NET Core не нужен.
Owin это стандарт, есть реализация его поддержки в ASP.NET Core. Вот можете тут почитать — docs.microsoft.com/en-us/aspnet/core/fundamentals/owin. У меня owin нет, с его миграцией я не сталкивался.
Если бы совместимость не ломалась — его бы 1.2, а не 2.0. Разный продукт и потеря совместимости это разные вещи.
Это развите идей ASP.NET. Но это не новая версия. А ещё Java и JavaScript тоже похоже называются =)
Вроде как вполне — www.nuget.org/packages/Microsoft.AspNetCore.Owin
Я, в общем, про это в конце и написал.
Всё-таки Mono умеет работать там, где не умеет Core, плюс имеет гуёвый и мобильный стэк построенный поверх себя. Быстро перенести Xamarin на Core видимо не получится, поэтому пока что Mono будет жить.
1.1, 2.0, 2.1 — с точки зрения ASP.NET Core разработчика это не особо крупные обновления. Они хорошие, полезные, но это не разные продукты. Миграция с 1.1 на 2.0 занимала иногда считанные минуты. Заменить project.json на csproj это не катастрофа. Вот между бетами и релиз-кандидатами — там да, были сильные изменения.
С другой стороны большая компания может себе позволить одновременно развивать много направлений и обмениваться успешными наработками.
Начали за здравие, закончили за упокой.
.NET Core это кроссплатформа для бэкенда.
.NET Framework это виндовс-приложения.
UWP это такой .NET Core для приложений в сторе с мордой на WPF. Так как WPF стандартизовали, то возможно со временем они UWP и превратят в надстройку над .NET Core.
Простой ASP.NET всё ещё поддерживается, но есть ощущение, что это теперь Legacy, который никак развиваться не будет. Как только они более-менее догонят его по фичам в ASP.NET Core, то начнут совсем активно продвигать миграцию и минимизировать усилия по поддержке.
Но это лишь мои мысли и догадки. Нынешний Microsoft, конечно, неплох, но если вспомнить чехарду с ASP.NET 5, Core, DNX, DNVM и этим всем — чёрт его знает, что они ещё могут выкинуть =)
«especially», но прям про ограничение я нигде не вижу.
Ещё и выглядит некрасиво.