Принимайте участие в зарплатном опросе! Уже собрано почти 8 000 анкет.

.NET дайджест #11: Не все так красочно c .NET Core и С#, границы DDD и микросервисов, обзор подсистемы Windows для Linux

В выпуске: параллельные вычисления на одном ядре, поиск ошибки производительности, анонс ASP.NET Core RC2, 6 примеров неправильного использования событий, начало работы с Angular2 и WebPack, как деплоят ребята из Stack Overflow.

.NET

Channels как альтернатива DataFlow.

Параллельные вычисления на одном ядре с использованием пространства имен System.Numerics.

Json.NET поддерживает .NET Core RC2.

Возвращение MSBuild вместо project.json.

Унифицированное API поможет проще портировать приложения на .NET Core.

Поиск ошибки производительности, или еще одно напоминание, почему стоит сравнивать строки без учета культуры, если в ней нет необходимости.

Ветка с вопросом о крутых OSS .NET проектах.

Реализация markdown для .NET.

Пост, в котором автор рассказывает, что возможно не все так красочно c .NET Core и С#.

Довольно интересная дискуссия о том, можно ли создавать серьезные системные приложения на .NET: часть 1, часть 2, часть 3, часть 4.

ASP.NET

Анонс ASP.NET Core RC2.

ASP.NET Core расписание и roadmap. Похоже, что со дня на день должен быть релиз.

ASP.NET Core Engineering guidelines.

IdentityServer4 переписан на ASP.NET Core RC2.

Строготипизированные настройки конфигурации в ASP.NET Core.

Content negotiation in ASP.NET Core.

DDD/microservices

DDD and Microservices: наконец-то какие-то границы.

Пример реализации агрегата в Bounded context, использующем CQRS и EventSourcing.

Варианты решения вопроса взаимодействие между агрегатами. Дельный совет про инъекцию сервисов в методы агрегата. В своем приложении тоже пришел к такому заключению, особенно в процессе рефакторинга. Но злоупотреблять не стоит.

10 уроков которым научил долгоиграющий проект с DDD часть 1, часть 2.

6 примеров неправильного использования событий.

Windows

Обзор подсистемы Windows для Linux.

Tools

ReSharper Ultimate 2016.2 EAP.

Docker

Контейнеры и Docker на Windows Server 2016 TP5. И еще один блог-пост на эту тему.

JS

Экспериментальная поддержка WebAssembly в основных браузерах.

Резюме и самый интересный новости ng-conf 2016.

Начало работы с Angular2 и WebPack.

SQL Server

Запустили SQL Server 2016.

Other

Почему гугл хранит миллиарда строк кода в одном репозитории.

Доступны записи выступлений с Xamarin Evolve 2016.

Как деплоят ребята из Stack Overflow.

Обзор того, как OSS работает в Microsoft.

Обязательно к прочтению из hack.summit() 2016.


← Предыдущий выпуск: .NET Дайджест #10
Следующий выпуск: .NET Дайджест #12

LinkedIn

57 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Довольно интересная дискуссия о том, можно ли создавать серьезные системные приложения на .NET: часть 1

Поправьте ссылку на часть 1 (различие в регистре, но получается 404).

Спасибо, вот правильная ссылка codeofrob.com/...-good-.net-developer.html, видимо, она как-то сконвертилась при публикации. Думаю, Сегрей или Валентина скоро поправят.

Не все так красочно c .NET Core и С#
Так ребята с мелкософта опаздали на 11 лет. Ну хотябы стартанули это в 2010. А так не понятно, к чему все это ?

Я думаю, .NET Core крут и будет популярен. Они его активно допиливают и будут портировать все больше API. ASP.NET Core работает на порядоко быстрее так что можно будет разрабатывать восоконагруженные приложения потребляя меньше ресурсов. И хостить это все на линухе, если угодно. Как по мне, то как раз вовремя.

Сколько вы знаете не высоконагруженных серверов на .NET и Java? А сколько высоконагруженных платформ на .NET и Java? И сколько из них в opensource (не Microsoft & Oracle/IBM etc провайдеров)? А сколько нужно времени, что бы opensource комьюнити .NET хотябы приблизилось к комьюнити Java как по качеству, так и по количеству?

В свое время ответы на эти вопосы меня cклонили в сторону Java. Сейчас отвечая себе же на эти вопросы у меня возникает другой вопрос — к чему эта суета от Microsoft’а?

Оу, сколько вопросов. Мне C# просто банально больше нравится, чем Java. И то, что MS поняли, что с линуксом лучше дружить — это очень большой скачек вперед. А по производительности ASP.NET Core приблизился к Scala, если еще не обогнал. Так что Java тут немного в стороне.

Вы, навреное, не совсем понимаете попытки Microsoft’а оживить .NET (могу ошибаться). Основное в .NET core — это opensource. Можно было бы запилить поддержку *nix.NET с коммерческой лицензией. Ход конем (opensource) — это хоть как то оживить opensource комьюнити под .NET. Производительность здесь вообще ни причем (10% туда, 10% сюда не сильно играют поределяющую роль — посмотрите на проекты на PHP/Python/Ruby/Javascript — там иногда все 100% проседают). Основное — это комьюнити под платформу. Язык — это конечно классно (Java как язык и рядом не стоит с C#), но, сейчас, без вменяемой комьюнити и платфомы (в меньшей мере) — это ничего не значит. Например, как там с D vs C++? Или с Rust vs C++? Да особо никак. Вот точно так же и с .NET vs Java — тольстый клиент под винду vs ынтерпрайз/сервер/высоконагруженные приложения.
З.Ы. и да API от ASP.NET MVC в разы лучше, чем че то там в мире Java, но это не повод вложения бабла в эту технологию в каком то ынтерпрайз проекте, тем более стратапе (если высоконагруженное приложение — зачем тратиться на не понятно что — бери и юзай бесплатно куча готовых решений на джаве).

Конечно, если под задачи лучше подходит джава — стоит выбирать джаву. Я не вижу (может, не замечаю) проблем с .NET коммюнити. Хотя от остальных PHP, Ruby, и т.п. далек.

Ну не скажите. .Net core не только про opensource, а так же и про кросс платфомерную поддержку, и плюс про офф поддержку Microsoft-ом, чего явно не было у Mono, что весьма существенный плюс для энтерпрайза.

«.net core-скептики» во многом правы — платформа сейчас ужасно сырая (от тузлов до самого фреймворка — в пакетах и версиях уже сейчас просто натуральный dependency hell в полный рост), что очень нетипично для MS. Чтобы в этом убедиться, достаточно попробовать сделать что-то на шаг право-влево от простейших MVC страничек \ REST API (например, подготовить билды своих библиотек под .NET Standards 1.3-1.5) — и это в RC2, выпущенном за месяц до релиза.

Ясно, что релиз 1.0 это больше маркетинговый ход и вот так магически в 1.0 все не станет стабильно и неглючно. Еще 6-12 месяцев — это даже оптимистичный сценарий, учитывая сколько времени заняло дойти до того что имеем на текущий момент.

Также MS ярко подпортила имэйдж с цирком k-runtime, ASP.NET 5, dnx, asp.net 1.0 core — подавая совершенно разной направленности сигналы потребителям платформы, а также массово забивая на свои же технологии (WCF, WebForms вот это все — список длинный. Вложено кучу ресурсов — люди изучали, внедряли, базировались, и все в дедпул). В итоге вроде бы текущий фреймворк 4.x то легаси, то уже не легаси, и там где был выбор .net с мутным будущем или что-то другое, в последние годы выбирали что-то другое.

p.s. разрабатываю на .net с самой первой версии, и полностью зависим от этой платформы — и как вендор .net компонентов, и как разработчик. Очень хочется надеяться, что «там наверху» изменят текущее состояние вещей, добавят вагон ресурсов и смогут стабилизировать платформу как задумано, до того как она перейдет в маргинальную нишу. Пока что прогноз по принципу вчерашней погоды, не очень радостный.

с цирком k-runtime, ASP.NET 5, dnx, asp.net 1.0 core
по-моему, все понятно и логично. k — это было временное название для dnx. А переименоване в Core и создание .NET Core чтобы на платформе можно было не только веб-приложения создавать, но и сервисы — очевидное решение, жаль, что они сразу так не слелали.
забивая на свои же технологии
Из-за WebForms я думаю не много кто расстроится, тем более Full Framework никто не отменял. То же и с WCF, если нужно — используйте.

Для себя я вижу использование .NET Core в производительный микросервисах, тех, в которых на него можно легко перейти. Опять, же, использовать там, где применимо.

Это стало логичнее и понятнее после переименования в .NET Core 1.0 (потребители платформы это не только разработчики. Есть еще много тех, кто совсем не разработчики но принимают решения, и они в первую очередь ориентируются на официальные блоги/презентации MS), и уже совсем понятнее после объяснений куда все идет с .NET Standards — а это было аж несколько месяцев назад если не ошибаюсь.

Из-за WebForms я думаю не много кто расстроится
Я вот подобное массово-негативное отношение к этой технологии наблюдаю только у наших аутсорсеров. Вы просто не представляете сколько людей продолжают использовать WebForms в мире, и как ни странно — особенно в развитых странах (моя выборка — тысячи фидбеков и вопросов по моим компонентам, с 2013 года). Я наблюдаю, что WebForms/WebPages технология просто отличная для бизнеса — особенно для использования не профессиональными разработчиками, когда надо заткнуть текущую потребность прямо сейчас — сгенерить простую форму, отрендерить какой нибуть invoice. Они просто делают это очень быстро (и дешево) добавляя 1 aspx файл, и г%%нячат аки в PHP (но в отличие от — могут быстро накидать туда UI-контролов). И это реально работает — мир не состоит только из монстроидальных тырпрайз систем.
Ответ «вот же он остался WebForms» слабый — технология не развивается, хотя идеологически есть куда и что исправлять хоть отбавляй. Кто мешал перескочить от серверного рендеринга к MVVM, при этом сохранив компонентную модель для UI контролов?.. MVC это же шаг назад на лет 15 — все эти контроллеры модели и шаблоны у нас были в 2000-м на PHP, низкий уровень абстракции и сложный реюз, делать Web UI все так же дорого и долго. Прорыв есть в плане переносимости — но в большинстве реальных веб-проектов это не было критичным — выбрали .net / windows, и ладно. MVC Core не имеет никаких концептуальных преимуществ перед аналогичными фреймворками на пхп\руби\js.

По WCF также могу пройтись, но это уже точно оффтопик.

Я вот подобное массово-негативное отношение к этой технологии наблюдаю только у наших аутсорсеров. Вы просто не представляете сколько людей продолжают использовать WebForms в мире, и как ни странно — особенно в развитых странах (моя выборка — тысячи фидбеков и вопросов по моим компонентам, с 2013 года).
Да, ну? Вы и вправда наивно полагаете что все это потому, что Web Forms удобней любой из PHP CMS и быстрее для освоения непрофессионалом, а не из-за плюшек саппорта с хорошими гарантиями на уровне корпоративных лицензий и общей тенденции к использованию legacy систем оставшихся в наследие из 2000?
MVC Core не имеет никаких концептуальных преимуществ перед аналогичными фреймворками на пхп\руби\js.
Думаю, все-таки имеет. Насколько мне известно перечисленные технологии одновременно не предоставляют асинхронность с неблокирующим i\o, многопотчоностью и условную типизацию в рамках одной платформы.
Да, ну? Вы и вправда наивно полагаете что все это потому, что Web Forms удобней любой
Я наивно полагаю, что несмотря на известные проблемы (исполнение было далеко от идеального, факт), концептуально технология была весьма мощной, ориентированной на реюз компонентов и снижение издержек, особенно в бизнес-аппах. Что предложено взамен — MVC с тем же уровнем абстракции, что был и 15 лет назад — обработкой GET/POST для любого чиха?.. Без какой-либо вменяемой компонентной архитектуры, с размазыванием кода по файлам. Нормальный подход для контентовых сайтиков, отстой для репид девелопмента веб аппов. В любом случае, это мое мнение и мой опыт.
не предоставляют асинхронность с неблокирующим i\o, многопотчоностью и условную типизацию в рамках одной платформы.
для большинства асп.нет аппов (формошлепство), все эти фичи не являются маст-хев, а причина тормозов находится на уровне запросов к бд. Особенно если потребители приложения — аж эти все 50-100 юзеров какого-то относительно небольшого бизнеса. И попробуйте используя только эти аргументы, обосновать преимущества .net core (глючного на данный момент) перед альтернативными платформами для бизнеса, которому по большому счету все равно что там под капотом и какими кейвордами оперируют наемные спецы.
обосновать преимущества .net core (глючного на данный момент)
вы интересовались концептуальной разницой технологий, если вопрос только в сроках — любой PHP фрилансер перебьет ASP.NET Web Forms проект по срокам с простым сайтом на CMS и бюджетом в разы меньшим на развертывание\разработку\сопровождение.
Если вопрос в качестве — то ASP NET MVC и сопуствующие фреймворки гибче Web Forms. В современной веб-разработке люди уже давно не парятся вопросами оптимизацией размера Server State и разбухшей разметки, и не потому что в корпоративных сетях гонять и рендерить метры этого мусора — стало ок, они это просто выкинули как страшный сон и стараются не вспоминать, когда их пытаются заманить на мертвые Enterpirise проекты. Ничего удивительного что MS не инвестирует в эту «нишу».

Если ошибаюсь поправь — я думаю, ты из свежего поколения, для которого дотнет был всегда (в смысле, не застал времена когда его еще не было), а WebForms запомнился только как непонятный зверь с безумной логикой биндинга и здоровыми вьюстейтами. Как и любую технологию, ее можно было использовать криво и стрелять в ногу, кто спорит. А можно было готовить правильно, и тогда она позволяла действительно осуществлять rapid development — напомню, я изначально говорил про вебформы как техологию для бизнес вебаппов, где стопятсот списков-форм-переходов, описывающих кастомный бизнес процесс. Альтернативы которая позволяла бы делать это еще быстрее И дешевле (имхо важнейший критерий ценности технологии) — на самом деле сейчас нет.

з.ы. сейчас слепить SPA который грузит 10мб — это типа норм, зато вьюстет в 50кб это же ужас-ужас =)

Rapid development связанных списков можно сделать и в SAP и в 1С, Oracle и любой другой ERP\CRM\BPM системе. Это имеет мало общего с веб разработкой и проблемами, которые есть в ней сейчас. Для этих задач никто не нанимает ASP.NET Web Forms девелопера, что бы порешать их «быстро» разработав систему с нуля, которую еще прийдеться и интегрировать с ERP и админинстрировать кому-то.

Есть большие компоненты, которые не плохо смотрелись в web forms.
demos.devexpress.com/ASPxPivotGridDemos

Пора переходить на вітчізняного виробника )) pivottable.nrecosite.com

10мб SPA должно кешироваться на клиенте (не говоря о том что это как-то сильно много даже для SPA). А 50кб вьюстейта будет в каждом запросе без кеширования. Причем когда страница маленькая ~5kb, и у неё 50кб вьюстейта который будет в каждом запросе — ну это как-то сильно уж.

Ну, 10 лет назад это все бегало, а тут во времена 8-ядерных смартов и массового 4г стало вдруг непереносимой болью )) тем более, что с вьюстейтом после .нет 3.5 стало лучше. Моя теория — забили, так как олдскульные архитекты которые продвигали компонентную разработку — все эти XML-модели там же, ушли (может и на пенсию бгг), а молодая смена не пойняла полета мысли дедов, и давай строчить клон рельсов со своим блекджеком и json конфигами. Кстати тяжко шло, MVC 1.0 был еще той адской поделкой.

Полет мысли у дедов был еще тот. Построить весь веб фреймворк вокруг статического HttpContext в многопоточном, асинхронном рантайме это от большего ума определенно.

он же ThreadStatic что не совсем тоже самое. Ну и Core 1.0 они ушли от этого

Да ладно. HttpContext.Current по факту идёт в ContextBase, который по факту хранится в Thread.CurrentThread, что в общем-то идеологически является ThreadStatic.У каждого потока свой статический экземпляр контекста, который хранится в самом же потоке и инициализируется ASP.Net пайплайном.

У каждого потока свой статический экземпляр контекста,
Там не так. 1 запрос может выполняться в разных никак не связанных потоках, если есть асинхронные i\o операции, к тому же это асинхронная оперция — пока она выполняеться нету ниодного потока к которому привязан текущий запрос вообще. Вся синхронизация основана на AspNetSyncContext и замыканиях переданных в Continuations.

у дедов зато релиз-кандидаты постабильнее были )) ничего асинхронного в .нет 1.0 не было. Даже кривые Begin*/End* появились чуть позже. На то время, иис+асп.нет вебформы показывали очень и очень приличный перфоманс. И вообще не было асинхронных веб-серверов. Ширше надо смотреть на историю, критикуя дедов — сохранение обратной совместимости штука непростая. А подход «разрушим до основанья, а затем» достаточно гм спорный, то что выходит «затем» часто бывает уже никому не нужно.

Ширше надо смотреть на историю, критикуя дедов — сохранение обратной совместимости штука непростая
Последние лет 10 только и делали, что пытались выпилить эту обратную совместимость в виде System.Web, надизайнили как надо — намертво.
ичего асинхронного в .нет 1.0 не было. Даже кривые Begin*/End* появились чуть позже.
на целый год позже! при этом поломав всю совместимость в 1.1 оставили дизайн asp.net из 1.0 и обречены были на страдания, любители самого быстрого ооп антипаттерна все последующие 15 лет.
на целый год позже!
Внезапно реализация асинхронных контролеров в первой версии ASP.NET MVC тоже вызывала желание пойти проблеваться, и нормальное юзабельное решение появилось вроде только в 3 версии

отмучались бедняги, зато сейчас заживем! Нет бинарной сериализации? А и не надо, это деды намудрили. Ой, нет DataSet/DataRow? Ф топку, антипаттерн, там же в штабе точно не дураки сидят ))

ничего асинхронного в .нет 1.0 не было. Даже кривые Begin*/End* появились чуть позже.
Ну справедливости ради, в 2000 году асинхронные веб-страницы и так были не нужны.
Построить весь веб фреймворк вокруг статического HttpContext
Из статического там же вроде только HttpContext.Current был? На моей памяти особых проблем он не доставлял, плюс там были более цивилизованные способы получить доступы к текущему контексту, не особо отличающиеся от того, что запилили в MVC.
это от большего ума определенно.
Не знаю, от большого или не от большого, но больше 10 лет на той архитектуре просидели, запилили миллионы веб-приложений. и MS не приходилось выпускать новую версию каждый год, как сейчас.
Не знаю, от большого или не от большого, но больше 10 лет на той архитектуре просидели,
а было из чего выбирать? так и не запили ниодного альтернативного веб-сервера. зато как отказались от AspNetSyncContext для синхронизации — так сразу стало в 23 раза больше запросов пропускать на том же железе. как упростили контекст и отказались от статической типизации на уровне контрактов HttpContext и сделали нормальную расширяемость так и за пару месяцев сумели запилить на libuv веб-сервер для asp.net.
зато как отказались от AspNetSyncContext для синхронизации — так сразу стало в 23 раза больше запросов пропускать на том же железе. как упростили контекст и сделали нормальную расширяемость так и за пару месяцев сумели запилить на libuv веб-сервер для asp.net.
Это офигенно, но как видно по графикам, пик популярности пришелся на момент выхода ASP.NET 2.0, построенным поверх богомерзкого HttpContext, а загнулось все после выхода православного ASP.NET MVC.

То, что решили проблему с производительностью — это хорошо, но, как оказалось, решение этой проблемы никто сильно и не хотел

Если судить по графику с точки зрения того что популярней asp.net mvc или веб формы, то он ниочем. То что интерес к asp.net начал падать среди прочих технологий уж точно не из-за того, что появилась mvc реализация, а скорее наоборот. Также история и с core — мс закрыли важные хвосты и сделали up to time фреймворк, каким он должен быть и каким asp.net до этого момента не был. Поздно — да, но в целом asp.net еще достаточно живая технология что бы говорить что это никому не нужно.

Этот график о том, что после выхода абсолютно сырого ASP.NET MVC, который существенно уступал web forms как платформа, фанаты MS поняли, что в импери добра окончательно упоролись и все начали валить с .NET/Windows платформы кто куда попало, конец предсказуем, MS теряет 35% market share всего за несколько лет.

События следующих 5 лет показали, что они сделали правильный выбор.

Также история и с core — мс закрыли важные хвосты
Решили кучу проблем, забыв у кастомеров перед этим поинтерисоваться, нужно ли кому-то решение этих проблем.
каким он должен быть и каким asp.net до этого момента не был.
Ну что, это офигенно, что теперь мне проще и быстрее запилить бекенд сайта на javascript в emacs чем на ASP.NET (хотя раньше мне для этого нужно было нажать несколько кнопочек и настроить нужные свойства в дизайнере, а теперь нужно вручную править json конфиги).

Насколько я видел Фаулеру достаточно активно реагировал на запросы комьюнити по добавлению фич в corе. Я тоже был удивлен , когда оказалось что под маком запилить и отдебажить в vs code и задиплоить в докере asp.net сайт не многим сложней node. Учитывая куда более вменяемый рантайм .net с нормальной системой типов в отличии от node единственное, что заставляет использовать Ноду — стабильность платформы и наличие изобилия компонентов, в .net core с этим пока совсем глухо. Но думать про node в перспективе сложно.

Теория с графиком и виной всему mvc звучит немного как bull shit по множеству причин, я слышал много cool story от зрящих в корень проблем мс людей но это уже совсем на смех пробивает.

имхо, мысли дедов MS-а были в том чтобы упростить переход с WinForms на WebForms. Они очень близки в этом — тот же дизайнер в студии, та же подписка на события через дизайнер и странная обработка OnClick-ов и остальных вещей. Те же странные AutoPostback-и. Такой же ужасный HTML код, который сгенерированный этим дизайнером. Я видел один такой проект, который был сделан аля WinForms, который совершенно не учитывал веб специфику.... это было печально.... и это к слову то что было у MS в их обучающих видео по ASP.Net-у первых версий

имхо, мысли дедов MS-а были в том чтобы упростить переход с WinForms на WebForms
Нормальная мысль, и народу понравилось. Но потом что-то пошло не так, и вместо тягания контролов и настройки их свойств в дизайнере всех отправили вручную рендерить html как в 95-м году.

Можно представить, что было бы если б вместо выпуска WPF, народу в качестве замены Win Forms предложили бы обертку для вызова Win32API функций.

Внезапно, в WPF интерфейс тоже строится с использованием языка разметки. Возможно, такой подход к построению интерфейсов во многом более удобный и гибкий?

В WPF есть более менее нормальный дизайнер, а редактировать XAML с 20-уровнями вложенности — удовольствие далеко не из приятных, но маемо те що маемо

Эх, был бы он еще и реактивный.

асинхронность с неблокирующим i\o, многопотчоностью и условную типизацию в рамках одной платформы
Эээээ... Java?

Как минимум Ratpack and Vert.x ... да и Spring уже тоже предоставляет + в 5.0 будет еще больше. Node.js тоже умеет неблокирующий и\о но его надо в несколько процессов еще запускать чтобы все ядра загрузить, но есть средства которые это решают ...

Кто мешал перескочить от серверного рендеринга к MVVM, при этом сохранив компонентную модель для UI контролов?

«visual web gui» — например, крутая штука, но умерла.

Кто мешал перескочить от серверного рендеринга к MVVM, при этом сохранив компонентную модель для UI контролов?
Здравый смысл.
MVC Core не имеет никаких концептуальных преимуществ перед аналогичными фреймворками на пхп\руби\js.

О каких концептуальных преимуществах вы говорите? Есть вопрос выбора языка и платформы, в который входят производительность, распространенность, поддержка — и в конце выбирают то, на чем пишет команда.

по-моему, все понятно и логично. k — это было временное название для dnx. А переименоване в Core и создание .NET Core чтобы на платформе можно было не только веб-приложения создавать, но и сервисы — очевидное решение, жаль, что они сразу так не слелали.
Честно говоря не вижу ничего логичного. Для тех, кто пристально не следит за каждым шагом MS, весь процес напоминает то, как Дядя Федор писал письмо своим родителям.

Те, кто не следит — могли бы просто подождать релиза. Кстати, сегодня должен быть.

Ну что, первый пошел — NReco.PivotData успешно сбилдил под .NET Standards 1.5 (пока nuget пакет не релизил — собираю фидбеки. Кто захочет потестить вышлю билд).

Кстати, .NET Core-потребители, нет ли потребности в либе, которая предоставляет абстрактный data layer — нечто вроде старого DataAdapter + абстрактные query? Нечто более удобное, чем низкоуровневый System.Data.Common (где надо SQL ручками композить), предоставляющее быстрый CRUD-интерфейс к БД. Для тех случаев когда EntityFramework не подходит. Могу портировать такую либу из закромов родины.

Согласен это не совсем логично, но ведь это их внутренее имя, которое они изменили ближе к релизу. Я понимаю возмущения если бы они меняли названия между релизными версиями, но по факту ведь это все было community preview\beta\etc, которые вполне могли переименовать тулинг во время процесса разработки.

Channels как альтернатива DataFlow.
лучше редиректить сюда: github.com/....Threading.Tasks.Channels

Отлично, я пока глубоко не изучал, прото где-то упоминалось, но вещь интересная и добавил себе на потом разобраться. Спасибо за ссылку!

Подписаться на комментарии