Наступил на грабли,
есть Microsoft.AspNetCore.Identity.UI в котором IEmailSender
который используется для регистрации прочей лабуды в Asp.Net.
Захотелось оформить реализацию отдельной библиотекой.
И тут оказалось, что с 3.0.0 эта зараза зависит от netcoreapp.
Какая-то лажа или я что не понял? Почему так вдруг закрутили?
Выходит, хочешь не хочешь придется всем переезжать на NET 5?
Неужели заговор?
Здравствуйте, varenikAA, Вы писали:
AA>Наступил на грабли, AA>есть Microsoft.AspNetCore.Identity.UI в котором IEmailSender AA>который используется для регистрации прочей лабуды в Asp.Net. AA>Захотелось оформить реализацию отдельной библиотекой. AA>И тут оказалось, что с 3.0.0 эта зараза зависит от netcoreapp. AA>Какая-то лажа или я что не понял? Почему так вдруг закрутили?
AFAIR Весь ASP.NET Core начиная в 3 только на Core и работает.
Здравствуйте, varenikAA, Вы писали:
AA>Какая-то лажа или я что не понял? Почему так вдруг закрутили?
Потому что .NET FW протухает и протухнет окончательно менее чем через пару месяцев. А без него netstd лишен смысла.
AA>Выходит, хочешь не хочешь придется всем переезжать на NET 5? AA>Неужели заговор?
Здравствуйте, Ночной Смотрящий, Вы писали: AA>>Какая-то лажа или я что не понял? Почему так вдруг закрутили?
НС>Потому что .NET FW протухает и протухнет окончательно менее чем через пару месяцев. А без него netstd лишен смысла.
И всё равно. Очевидно, не очень хорошее архитектурное решение. в сборке с UI лежит простой не зависящий от платформы интерфейс IEmailSender, который необходим для дефолтной логики авторизации, регистрации.
Мы хотим его реализовать, но для этого надо сделать сборку с реализацией сендера зависимой от всего корэ.
Использование .NET Standard 2.1
Новую версию стандарта не планируют использовать в .NET Framework 4.8, который продолжит работать на версии 2.0. А вот .NET Core 3.0, Xamarin, Mono и Unity обновят до версии 2.1. При этом обновление всех библиотек не планируется, во всяком случае сейчас.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, varenikAA, Вы писали:
AA>И всё равно. Очевидно, не очень хорошее архитектурное решение.
Очевидно это отличное архитектурное решение, поскольку позволяет избавиться от ненужного гемороя с поддержкой netstd 2.0.
AA> в сборке с UI лежит простой не зависящий от платформы интерфейс IEmailSender, который необходим для дефолтной логики авторизации, регистрации.
И? Что надо сделать? Выделить пакет с одним единственным интерфейсом, при том что пакетов и так овердохрена? По этому пути хипста их кора уже ходила, когда в первых версиях безобидный функционал цеплял десятки, а то и сотню нугетов. От этого идиотизма слава богу избавились.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И? Что надо сделать? Выделить пакет с одним единственным интерфейсом, при том что пакетов и так овердохрена? По этому пути хипста их кора уже ходила, когда в первых версиях безобидный функционал цеплял десятки, а то и сотню нугетов. От этого идиотизма слава богу избавились.
и поэтому в UI сборке у нас будет интерфейс сервиса, которому ЮАЙ совсем ни к чему?
Здравствуйте, Ночной Смотрящий, Вы писали:
AA>>и поэтому в UI сборке у нас будет интерфейс сервиса, которому ЮАЙ совсем ни к чему?
НС>Дя, чтобы не ломать совместимость.
Думаю ничего бы не поломалось. выделить в отдельную сборку интерфейс. Кто будет мигрировать, все равно будет обновлять версии пакетов.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, varenikAA, Вы писали:
AA>>Думаю ничего бы не поломалось. выделить в отдельную сборку интерфейс.
НС>Но пользы от того тоже пояти нет. Так нафига платить больше?
Польза очевидна: могут быть старые и новые проекты, реализация общая, если 2.0, иначе все кору 3.1 перетаскивать.
Это же первая аксиома Дяди Бо — зависимости есть зло.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Потому что .NET FW протухает и протухнет окончательно менее чем через пару месяцев. А без него netstd лишен смысла.
На виндах раскатано море копий старых фрэймворков и люди еще лет 20 будут писать под них софт. Кроме того есть тот Кзамарин и потребность создавать независимые от платформы библиотеки не пропадет никогда.
Есть такое понятие обратная совместимость. Раньше, когда Гейтс рулил, МС считала этот принцип священным. А сейчас там собралось стало баранов не понимающих важность этого принципа. Потому и усиленно теряют рынки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>На виндах раскатано море копий старых фрэймворков
Если брать с поддержкой netstd2, то не такое уж и море.
VD> и люди еще лет 20 будут писать под них софт.
Нафига? Уже сейчас есть возможность таскать кор с собой. В 5.0 будет возможность упихать все в один файл.
VD> Кроме того есть тот Кзамарин
Там 2.1 поддерживается.
VD>Есть такое понятие обратная совместимость. Раньше, когда Гейтс рулил, МС считала этот принцип священным. А сейчас там собралось стало баранов не понимающих важность этого принципа. Потому и усиленно теряют рынки.
Ага, особенно кор усиленно рынки теряет по сравнению с FW.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И? Что надо сделать? Выделить пакет с одним единственным интерфейсом, при том что пакетов и так овердохрена? По этому пути хипста их кора уже ходила, когда в первых версиях безобидный функционал цеплял десятки, а то и сотню нугетов. От этого идиотизма слава богу избавились.
Интерфейс с одним методом. Зачем он вообще нужен? Заменить стандартный делегат System.Func<string, string, string, System.Threading.Tasks.Task>.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Интерфейс с одним методом. Зачем он вообще нужен? Заменить стандартный делегат System.Func<string, string, string, System.Threading.Tasks.Task>.
Публиковать в DI универсальные делегаты — не так чтобы хорошая идея.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нафига? Уже сейчас есть возможность таскать кор с собой. В 5.0 будет возможность упихать все в один файл.
А чтобы людям не приходилось таскать за собой фрэймворк.
НС>Ага, особенно кор усиленно рынки теряет по сравнению с FW.
При таком подходе будет. Виндофон просрали же.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
НС>>Публиковать в DI универсальные делегаты — не так чтобы хорошая идея. VD>А что плохого если нужна ссылка на один метод? Вот что хорошего во ведении нового типа на ровном месте?
Еще раз, по буквам. Как правило этот самый IEmailSender используется через DI. Код примерно такой:
services.AddSingleton<IEmailSender>(myEmailSender);
...
public SomeDIService(IEmailSender sender) => sender.Send(...);
Неужели ты думаешь, MS не умеет выкручивать локти? Они этим занимаются со времён Win3.1!
