Наступил на грабли,
есть 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(...);
Здравствуйте, VladD2, Вы писали:
НС>>Нафига? Уже сейчас есть возможность таскать кор с собой. В 5.0 будет возможность упихать все в один файл. VD>А чтобы людям не приходилось таскать за собой фрэймворк.
Это маргинальщина. Сейчас весь десктоп в том же направлении идет, а вся эта история с предустановленными фреймворками — она чисто десктопная.
Здравствуйте, VladD2, Вы писали:
VD>При таком подходе будет. Виндофон просрали же.
Виндофон как раз просрали из-за того, что отказались от Win CE. При этом не предложив нормальное решение.
А оно появилось только в Win Mo 10 в основе которого и лежит Core. То есть как минимум через 7 лет!
Что касается FW и Core то они шли параллельно, пока Core (.Netstandard, а отладка на Core) не подрос до FW.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это маргинальщина. Сейчас весь десктоп в том же направлении идет, а вся эта история с предустановленными фреймворками — она чисто десктопная.
Тут еще дело в безопасности, одна проверенная системная библиотека лучше куче локальных с непонятной начинкой.
Работал в одной очень крупной кампании. Так там разработчиков плагинов для кассового ПО запрещали в дистрибутив даже xml пихать, которые автоматом генерятся.
Таже федора(линукс) за это ругает убунту, что те постоянно патчат библиотеки плюя на совместимость.
Неужели ты думаешь, MS не умеет выкручивать локти? Они этим занимаются со времён Win3.1!
