В контексте совместимости лучше задавать вопрос ни чего запустить нельзя, а что можно. Как я понимаю по серверной части и десктопу кроме консоли ничего запустить и нельзя. К чему тут msbuild, если под маком ни вин службы, ни wcf проекты, ни wpf ни ms tests работать не будут как я понимаю. О каком переходе на мак может идти речь.
и опять же, не следует забывать что в Asp.net со статическим httpcontext и велосипедом под него в виде aspnetsynccontext были очень грубые ошибки дизайна которые просто удивительно как прожили 15 лет, то что их убрали и теперь используют что бы продать новый Фреймворк не очень честно со стороны мс
Vs code становится приятней, но подсветка работает не всегда правильно, solution на несколько проектов Omni sharp не всегда подхватывает с первого раза с intelli sense по другим проектам, приходится переключатся между проектам, или реалоадить солюшин постоянно добавив проект и reference, не удобно.
Тест tech empower по text plain Json, не лучший пример, они используют не свои сокеты, а p/invoke Libuv- посмотрите как он с базой работает, полагаю со своим .net I/o уступая в 5-6 раз конкурентам.
Если запустить ASP.NET Core под 4.6, тогда и service model будет доступна. Собрать проект, который референсит service model как netcoreapp на текущий момент нельзя, насколько помниться.
OWIN это просто абстракция, а не хост. Любой веб сервер может быть OWIN совместимым, как и IIS. System.Web.HttpContext же отсутствует только если вы не используете IIS.
PerRequestLifetimeManager работает под Web Api и под MVC одинаково, когда вы используете IIS для хостинга так же и как и все остальные HttpModules в IntegratedPipeline.
Вы не первый кому понадобилось использовать Shared DbContext в Web Api и не первый, кто словил исключение при попытке сделать join при получении данных.
До тех пор пока Web Api 2 хоститься под IIS по идее в Unity должен нормально работать PerHttpRequestModule и не важно используете вы OwinMiddleware в своем приложении или нет. Описанный выше кейс более актуальный для self host. + судьба Unity достаточно туманна в текущий момент, год назад его мс передали каким-то ребятам его, и до сих пор не было аннонсированно ни обновлений ни будущих планов на эту либу.
Качество кода в мс далеко не абсолютный показатель. Приходилось писать интеграцию с тфс сервером, их объектная модель с одной стороны штука удобная, с другой не покрывала наших потребностей в частности создание проекта с git sc, пришлось делать реверс инженеринг и заглянуть в то, что называлось у них как закрытая часть. К нашему удивлению там были soap сервиса, которые в xml body принимали по частям sql запросы. Верю что качество кода будет повышаться по мере того как они движутся в open source направлении, но то что у них было раньше сложно назвать высокими стандартами местами.
Что более важно, он делегирует свои запросы на resolve в контейнер (если такой есть), но не делегирует туда register.
В таком случае, что вам мешает делать как прежде? Использовать контейнер от стороннего вендора вне Asp.Net Core фрейморка и написать UnityGlobalFilterProvider, AutofacFilterProvider, MyControllerFactory и подключить их в IServiceCollection не мешая два контейнера?
Хотите использовать два контейнера — используйте.
Проблема, которая возникла у вендоров состоит совсем в другом — необходимость обеспечения совместимости для интерфейсов, которые МС использует для регистрации внутренних компонентов ASP.NET Core.
А как без него? Раньше тоже был такой интерфейс —
http://www.asp.net/web-api/overview/advanced/configuring-aspnet-web-api#services
Все что спасало сторонних вендоров от текущих проблем, что не было одного DI зашаренного между компонентами фреймворка и зависимостями определяемыми разработчиками.
Был Resolver который где-то мог использоваться фреймворком где-то нет при содании клиентских типов. И набор сервис локатор для фреймворка.
В свою очередь это порождало другую боль для разработчиков:
1. Необходимость для вендоров, а иногда и самих разработчиков переопределять стандартные фабрики и провайдеры своими и прогонять обьект через сторонний контейнер.
2. Непонятный жизненный цикл компонентов — когда надо помнить, что вот у меня эти фильтры живут как синглтоны, а эти transient, а эти Handlers опять singltones.
Мне не совсем понятен отсыл к предыдущим реализациям 'DI' в Mvc и Web Api даже на фоне текущих проблем он выглядит мягко говоря странным.
но призывает немного по другому взглянуть на привычные вещи, позволяет писать безопасный и легко тестируемый с точки зрения многопоточности код.
Вы где-то кроме программирования State Machine пытались применить это решение? Насколько я понял вы отказались от использования асинхронного кода в связке с .NET ThreadPool — в пользу создания создания отдельного потока на каждый контекст и последовательного выполнения задач в нем. Для кастомизации и тюнинга таких низкоуровневых решений требуеться намного больше знания многопоточности, чем для обычной синхронизации кода с использованием async\await, и которые не требуют девелопера считать сколько и когда им создавать потоков на приложение\event bus\операцию.
Какая разница ASP.NET разработчику как грузиться mscorlib api, это уже меняли несколько раз и никого это не волновало, пока кто-то об этом не написал в твиттере.
Вопрос с заменой project.json также выглядит раздутым интернет тролями, поэтому сейчас все на него ведутся.
Куда более неожиданным было появление NET CLI, отказ от DNX и отсутствие достаточно длительное время Tools для нормальной работы с новым рантаймом. Но этого никто не замечал, так как в интернете никто не бурлил, хотя трудностей это добавляло куда более.
Неопределенность с project.json как аргумент для невключения в Rider — ок. Серьезный момент, сложно спорить.
В целом по поводу фидбека и
so what do my projects and my business need to be doing with regard to .NET Core today
Все смахивает на неконструктивный троллинг, автор приводит в качестве контраргумента неуверенность Фаулера по поводу будущего поддержки WebAssm и то, что его Веб приложения будут кидать NotImplemented на AppDomain.Create(). Первый вопрос, который возник, интересно как часто он этим пользуется сейчас в ASP.NET и насколько его волнует как именно подгружаеться mscorlib api в его веб приложения.
Как по мне первые вопросы, которые его должны волновать,
-как tech guy in MS stack это какие benefits он получит от того, что сможет запускать и дебажить Asp.Net приложение в Docker Image, или насколько легче ему станет масштабировать горизонтально\вертикально веб приложение от того что MS наконец-то избавились от статичного HttpContext и AspNetSyncronization контекст для синхронизации асинхронных операций i\o.
— как product-ownerа, это какие benefits он получить от того что ASP.NET компоненты веб-приложения от начала до конца стали Host agnostic и при доступных опциях хостинга в Linux vm облаке
-any other role — т.д.
.net cli tooling вышел пару недель назад, работает привлекательней чем во времена dnx, отладка на Mac работает без каких либо проблем например. Netcoreapp фреймворк, который совместим с NET Standard так же уже на nuget, апи вполне достаточно, разве нет? asp.net core, ef core и библиотеки сторонних вендоров понемногу так же компилируют под него и выкладывают в nuget. не ожидал что добавив поддержку dnx не будет доступна поддержка .net cli, которая тоже уже аннонсированна была как года пол назад.
В Razor есть готовые хелперы для большинства стандартных элементов, создавать и reusать шаблонов по типам .NET так же достаточно просто, скафолд форм из моделей и собственно хелперы для ajax формы. Если все это совместить с бутстрапом — выйдет намного проще, легковестней и гибче чем серверные контролы и ajax панели.
Другое дело что сейчас это уже так же используеться скорее для прототипированния или кровавого энтерпрайза в интранетах, вы остали очень позади от современных проблем веб разработки, когда люди паряться всякими хаками типа спрайтов, cookieless domains пытаються применять http2 для оптимизации загрузки сайтов и боряться за каждую милисекунду, вы даже не задумываетесь про весь хешированные стейт в веб формах и разбухшую разметку, только потому что можете в конструкторе создавать веб сайт. Дело ваше но с такими подходами и приоритетами будет чем дальше тем сложнее оставаться на плаву в веб разработке.
Кстати Self-hosts в консоли можно было делать и раньше для отдельных компонентов ASP.NET фреймворка. Основное отличие сейчас, что они вместо .net сокетов взяли и обернули libuv через p\invoke и вызывают его из dotnet в так называемом kestrel http server.
Это те же сокеты, что и Node.js использует.
А самая фишка, что вебприложение с netXXX компилируется в exe файл. Запустил — и твой сервер работает. Даже IIS не нужен.
Компиляций в исполняемый файл не зависит напрямую от выбранного framework. Все что нужно сделать указать runtimes в project.json и он под каждую систему и выбранный фреймворк будет выдавать свой исполняемый файл. Упаковка в dll дефолтный вариант если не указаны runtimes.
Так это не только проблема подключения к бд, а скорее вопрос того когда они сделают стабильные реализации рантайма для разных платформ. Еще недавно было достаточно много проблем связанных с i\o разного рода на разных платформах, даже такими базовыми вещами как HttpClient например.
https://msdn.microsoft.com/en-us/library/dn270723(v=vs.113).aspx
Вы не первый кому понадобилось использовать Shared DbContext в Web Api и не первый, кто словил исключение при попытке сделать join при получении данных.
В таком случае, что вам мешает делать как прежде? Использовать контейнер от стороннего вендора вне Asp.Net Core фрейморка и написать UnityGlobalFilterProvider, AutofacFilterProvider, MyControllerFactory и подключить их в IServiceCollection не мешая два контейнера?
Хотите использовать два контейнера — используйте.
Сейчас так и есть, конфигурация специфичная для каждого контейнера как была так и осталась, со всем фичами характерными для каждого контейнера.
http://docs.autofac.org/en/latest/integration/aspnetcore.html
Проблема, которая возникла у вендоров состоит совсем в другом — необходимость обеспечения совместимости для интерфейсов, которые МС использует для регистрации внутренних компонентов ASP.NET Core.
http://www.asp.net/web-api/overview/advanced/configuring-aspnet-web-api#services
Все что спасало сторонних вендоров от текущих проблем, что не было одного DI зашаренного между компонентами фреймворка и зависимостями определяемыми разработчиками.
Был Resolver который где-то мог использоваться фреймворком где-то нет при содании клиентских типов. И набор сервис локатор для фреймворка.
В свою очередь это порождало другую боль для разработчиков:
1. Необходимость для вендоров, а иногда и самих разработчиков переопределять стандартные фабрики и провайдеры своими и прогонять обьект через сторонний контейнер.
2. Непонятный жизненный цикл компонентов — когда надо помнить, что вот у меня эти фильтры живут как синглтоны, а эти transient, а эти Handlers опять singltones.
Мне не совсем понятен отсыл к предыдущим реализациям 'DI' в Mvc и Web Api даже на фоне текущих проблем он выглядит мягко говоря странным.
Вы где-то кроме программирования State Machine пытались применить это решение? Насколько я понял вы отказались от использования асинхронного кода в связке с .NET ThreadPool — в пользу создания создания отдельного потока на каждый контекст и последовательного выполнения задач в нем. Для кастомизации и тюнинга таких низкоуровневых решений требуеться намного больше знания многопоточности, чем для обычной синхронизации кода с использованием async\await, и которые не требуют девелопера считать сколько и когда им создавать потоков на приложение\event bus\операцию.
Вопрос с заменой project.json также выглядит раздутым интернет тролями, поэтому сейчас все на него ведутся.
Куда более неожиданным было появление NET CLI, отказ от DNX и отсутствие достаточно длительное время Tools для нормальной работы с новым рантаймом. Но этого никто не замечал, так как в интернете никто не бурлил, хотя трудностей это добавляло куда более.
В целом по поводу фидбека и
Все смахивает на неконструктивный троллинг, автор приводит в качестве контраргумента неуверенность Фаулера по поводу будущего поддержки WebAssm и то, что его Веб приложения будут кидать NotImplemented на AppDomain.Create(). Первый вопрос, который возник, интересно как часто он этим пользуется сейчас в ASP.NET и насколько его волнует как именно подгружаеться mscorlib api в его веб приложения.
Как по мне первые вопросы, которые его должны волновать,
-как tech guy in MS stack это какие benefits он получит от того, что сможет запускать и дебажить Asp.Net приложение в Docker Image, или насколько легче ему станет масштабировать горизонтально\вертикально веб приложение от того что MS наконец-то избавились от статичного HttpContext и AspNetSyncronization контекст для синхронизации асинхронных операций i\o.
— как product-ownerа, это какие benefits он получить от того что ASP.NET компоненты веб-приложения от начала до конца стали Host agnostic и при доступных опциях хостинга в Linux vm облаке
-any other role — т.д.
.net cli tooling вышел пару недель назад, работает привлекательней чем во времена dnx, отладка на Mac работает без каких либо проблем например. Netcoreapp фреймворк, который совместим с NET Standard так же уже на nuget, апи вполне достаточно, разве нет? asp.net core, ef core и библиотеки сторонних вендоров понемногу так же компилируют под него и выкладывают в nuget. не ожидал что добавив поддержку dnx не будет доступна поддержка .net cli, которая тоже уже аннонсированна была как года пол назад.
Другое дело что сейчас это уже так же используеться скорее для прототипированния или кровавого энтерпрайза в интранетах, вы остали очень позади от современных проблем веб разработки, когда люди паряться всякими хаками типа спрайтов, cookieless domains пытаються применять http2 для оптимизации загрузки сайтов и боряться за каждую милисекунду, вы даже не задумываетесь про весь хешированные стейт в веб формах и разбухшую разметку, только потому что можете в конструкторе создавать веб сайт. Дело ваше но с такими подходами и приоритетами будет чем дальше тем сложнее оставаться на плаву в веб разработке.
Это те же сокеты, что и Node.js использует.
Компиляций в исполняемый файл не зависит напрямую от выбранного framework. Все что нужно сделать указать runtimes в project.json и он под каждую систему и выбранный фреймворк будет выдавать свой исполняемый файл. Упаковка в dll дефолтный вариант если не указаны runtimes.