Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
S>>>Вопрос раз: как мы его будем тестировать? _NN>>Юнит тестами . S>Не выйдет. Нужна чистая vm только с FW2. Причём это будет vm не в appveyor, там все образы с свежим fw.
S>Поведение FW меняется от 2.0 к 3.5 (к примеру, правилось поведение для call context). S>Если код использует рефлексию и лезет в кишки fw — тоже надо проверять.
Для 2.0->3.5 такой халявы нет
_NN>Можно закрыть PR, это было больше разминкой чем реальным применением.
На твоё усмотрение. Если есть желание саппортить ветку с 2.0 — почему нет?
Здравствуйте, Sinix, Вы писали:ing/4.5.1-4.6.2
S>Для 2.0->3.5 такой халявы нет
_NN>>Можно закрыть PR, это было больше разминкой чем реальным применением. S>На твоё усмотрение. Если есть желание саппортить ветку с 2.0 — почему нет?
Если то, что есть устраивает, то могу.
Пока NUnit не убьют поддержку 2.0, хотя вряд ли в 3.x это сделают и вообще в этом году.
Здравствуйте, _NN_, Вы писали:
IT>>Это ещё одна зависимость? _NN>Да. это слой совместимости для старых версий.
Можно же легко обойтись без каких-либо зависимостей.
_NN>При чём эта будет единственной зависимостью, другие библиотеки как LinqBridge, TaskParallelLibrary будут не нужны.
Одна уже есть — System.ValueTuple и она мне уже весь мозг высосала. Пришлось даунгрейдить её до определённой версии из-за конфликтов. Народ на проекте кто ржёт, кто матом орёт и грозиться "вынинуть найух этот твой CodeJam, задолбал он уже". А вы ещё зависимостей добавляете Убирать существующие надо, а не добавлять новые. CodeJam не тот проект, который ну никак не обойдётся без зависимостей.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>И вообще это недоразумение можно из библиотеки убирать. AVK>>Какое именно недоразумение?
IT>MapperBuilder и всё с ним связанное
Что с ним не так?
IT> что перенесено в Blocks (кто только название такое дебильное придумал?).
Здравствуйте, Sinix, Вы писали:
S>Сабж.
S>Вопрос раз: как мы его будем тестировать?
Юнит тестами .
2.0 должен быть в постоянном статусе на свой страх и риск S>Вопрос два: смысл? Есть ли реальный кейс для добавления поддержки?
Кейс для популяризации CodeJam.
Есть до сих пор библиотеки с поддержкой 2.0 и если CodeJam будет это поддерживать, то возможно, будет больше заинтересованных.
Здравствуйте, _NN_, Вы писали:
S>>Вопрос раз: как мы его будем тестировать? _NN>Юнит тестами .
Не выйдет. Нужна чистая vm только с FW2. Причём это будет vm не в appveyor, там все образы с свежим fw.
Поведение FW меняется от 2.0 к 3.5 (к примеру, правилось поведение для call context).
Если код использует рефлексию и лезет в кишки fw — тоже надо проверять.
_NN>2.0 должен быть в постоянном статусе на свой страх и риск S>>Вопрос два: смысл? Есть ли реальный кейс для добавления поддержки? _NN>Кейс для популяризации CodeJam.
Тут есть засада. CJ делался и развивается как библиотека, построенная по реальным, проверенным в бою сценариям использования.
Нет пруфов — нет кода
Я поддерживать и гарантировать качество работоспособность на FW2 не готов. Если найдётся желающий поддерживать сборку под FW2 на постоянной основе — вэлкам
_NN>Есть до сих пор библиотеки с поддержкой 2.0 и если CodeJam будет это поддерживать, то возможно, будет больше заинтересованных.
Для больше заинтересованных нужны как минимум справка и блог с постами с юзкейсами.
Здравствуйте, Sinix, Вы писали:
_NN>>Можно закрыть PR, это было больше разминкой чем реальным применением. S>На твоё усмотрение. Если есть желание саппортить ветку с 2.0 — почему нет?
Цель была подсадить другие библиотеки на CodeJam
Как оказывается есть до сих пор библиотеки с поддержкой 2.0.
По этому поводу даже поднялся вопрос о поддержке .NET 2.0 в NUnit.
Здравствуйте, _NN_, Вы писали:
_NN>Если то, что есть устраивает, то могу. _NN>Пока NUnit не убьют поддержку 2.0, хотя вряд ли в 3.x это сделают и вообще в этом году.
Ок, вечером гляну.
Здравствуйте, _NN_, Вы писали:
_NN>Если то, что есть устраивает, то могу. _NN>Пока NUnit не убьют поддержку 2.0, хотя вряд ли в 3.x это сделают и вообще в этом году.
Глянул, должно работать. Если есть желание запушить — пусть ещё кто-то из CJ team одобрит.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Sinix, Вы писали:
S>>Вопрос два: смысл? Есть ли реальный кейс для добавления поддержки?
IT>Лучше добавить поддержку Core 1.6.
_NN>Если это похожий объём работы то не проблема .
Мне кажется, что бОльший. Я бы вообще с Core 1.x кроме LTS не связывался.
Тем более, что через год у Core 1 end of support наступит. Если реально надо — попробуем.
Здравствуйте, Sinix, Вы писали:
S>Мне кажется, что бОльший. Я бы вообще с Core 1.x кроме LTS не связывался. S>Тем более, что через год у Core 1 end of support наступит. Если реально надо — попробуем.
Я так понимаю Игорь хочет подцепить к l2db, а у него core 1.6 поддерживается, так что в текущем виде не прокатит.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
S>>Мне кажется, что бОльший. Я бы вообще с Core 1.x кроме LTS не связывался. S>>Тем более, что через год у Core 1 end of support наступит. Если реально надо — попробуем.
AVK>Я так понимаю Игорь хочет подцепить к l2db, а у него core 1.6 поддерживается, так что в текущем виде не прокатит.
О, если реальный сценарий есть — отлично. Давайте реквест на 1.6, покопаюсь на след. неделе.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Sinix, Вы писали:
S>>Мне кажется, что бОльший. Я бы вообще с Core 1.x кроме LTS не связывался. S>>Тем более, что через год у Core 1 end of support наступит. Если реально надо — попробуем.
AVK>Я так понимаю Игорь хочет подцепить к l2db, а у него core 1.6 поддерживается, так что в текущем виде не прокатит.
Вот сильно сомневаюсь
У нас таки не появились дополнительные зависимости, да и пока не надо. Хотя я все чаще поглядываю в сторону ASP.NET Options Pattern, чтобы избавиться от глобальных настроек.
Здравствуйте, Danchik, Вы писали:
D>У нас таки не появились дополнительные зависимости, да и пока не надо. Хотя я все чаще поглядываю в сторону ASP.NET Options Pattern, чтобы избавиться от глобальных настроек.
Какое то мутное описание. Что то я под вечер не уловил в чем кайф этих экзерсисов. Можешь попроще объяснит?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Danchik, Вы писали:
D>>У нас таки не появились дополнительные зависимости, да и пока не надо. Хотя я все чаще поглядываю в сторону ASP.NET Options Pattern, чтобы избавиться от глобальных настроек.
AVK>Какое то мутное описание. Что то я под вечер не уловил в чем кайф этих экзерсисов. Можешь попроще объяснит?
Какие это даст бенефиты. К примеру подключили дополнительную либу, назвем ее linq2db.NpgSql.NetTopologySuite.
И тут же аккуратно нарезали опции для соединения, маппинга, да и пользуемся всюду.
Я для себя такое настроить могу, но только потому что я пару раз код linq2db перечитал. Да и расширять экстеншинами сложно, все пляшет вокруг MappingSchema.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
_NN>>Если то, что есть устраивает, то могу. _NN>>Пока NUnit не убьют поддержку 2.0, хотя вряд ли в 3.x это сделают и вообще в этом году.
S>Глянул, должно работать. Если есть желание запушить — пусть ещё кто-то из CJ team одобрит.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Как закончу интеграцию с Theraot.Core, будет легко добавить поддержку.
IT>Это ещё одна зависимость?
Да. это слой совместимости для старых версий.
Для новых версий фреймворка зависимость будет не нужна конечно.
При чём эта будет единственной зависимостью, другие библиотеки как LinqBridge, TaskParallelLibrary будут не нужны.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
IT>>>Это ещё одна зависимость? _NN>>Да. это слой совместимости для старых версий.
IT>Можно же легко обойтись без каких-либо зависимостей.
Каким обоазом? Притащить весь код библиотек в CodeJam? _NN>>При чём эта будет единственной зависимостью, другие библиотеки как LinqBridge, TaskParallelLibrary будут не нужны.
IT>Одна уже есть — System.ValueTuple и она мне уже весь мозг высосала. Пришлось даунгрейдить её до определённой версии из-за конфликтов. Народ на проекте кто ржёт, кто матом орёт и грозиться "вынинуть найух этот твой CodeJam, задолбал он уже". А вы ещё зависимостей добавляете Убирать существующие надо, а не добавлять новые. CodeJam не тот проект, который ну никак не обойдётся без зависимостей.
Не проще ли в CodeJam просто обновить зависимость ?
Какое решение предлагается ?
Здравствуйте, _NN_, Вы писали:
IT>>Можно же легко обойтись без каких-либо зависимостей. _NN>Каким обоазом? Притащить весь код библиотек в CodeJam?
Если нужно весь, то можно притащить весь. Хотя это вряд ли понадобится.
_NN>Не проще ли в CodeJam просто обновить зависимость ?
Кому проще? Юзерам проще выкинуть это овно нахрен и предать анафеме криворуких девелоперов вместе с их поделками.
_NN>Какое решение предлагается ?
Предлагается убрать существующие зависимости и не добавлять новых без совсем уж крайней необходимости. А если такая необходимость возникнет, то всегда можно создать новый проект.
Но данный случай — это не та самая необходимость. Лучше уж не трогать ничего. Пусть не будет этой поддержки, хрен с ней, если не хватает тяму обойтись без дополнительных зависимостей.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
IT>>>Можно же легко обойтись без каких-либо зависимостей. _NN>>Каким обоазом? Притащить весь код библиотек в CodeJam?
IT>Если нужно весь, то можно притащить весь. Хотя это вряд ли понадобится.
В случае старых фреймворков понадобится.
Чем новее фреймворк тем меньше нужно.
_NN>>Не проще ли в CodeJam просто обновить зависимость ?
IT>Кому проще? Юзерам проще выкинуть это овно нахрен и предать анафеме криворуких девелоперов вместе с их поделками.
_NN>>Какое решение предлагается ?
IT>Предлагается убрать существующие зависимости и не добавлять новых без совсем уж крайней необходимости. А если такая необходимость возникнет, то всегда можно создать новый проект.
IT>Но данный случай — это не та самая необходимость. Лучше уж не трогать ничего. Пусть не будет этой поддержки, хрен с ней, если не хватает тяму обойтись без дополнительных зависимостей.
В таком случае библиотеку надо сделать только для последних версий .NET и никаких зависимостей не потребуется совсем.
Проблема в том, что не у всех есть счастье пользоваться последними версиями фреймворков.
Можно разделить библиотеку.
Будет
CodeJam с поддержкой только 4.8 и Core 3.0.
CodeJam.Legacy для более старых версий с дополнительными зависимостями
Здравствуйте, _NN_, Вы писали:
_NN>Проблема в том, что не у всех есть счастье пользоваться последними версиями фреймворков.
Например, у меня.
_NN>Можно разделить библиотеку.
Не надо ничего делить. Надо втащить для старых фреймворков код для совместимости в саму библиотеку, без всяких новых зависимостей. Работы на пол часа. Мы тут дольше это обсуждаем.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Проблема в том, что не у всех есть счастье пользоваться последними версиями фреймворков.
Наверное стоит определиться о какой версии идёт речь.
Для версий меньше 4.5 в любом случае в проекте будет слой совместимости и лучше если не будет дублирований имён и все будут пользоваться одной библиотекой.
Также для версий до 4.0 тащить весь System.Threading.Tasks в CodeJam мне кажется перебором.
Для 4.5 и выше на данный момент единственной зависимостью является System.ValueTuple последней версии.
Если код этой библиотеки втащить в CodeJam, то будет конфликт имён если проект использует зависимость на System.ValueTuple.
Мне кажется, тут проще синхронизировать версии.
IT>Например, у меня.
_NN>>Можно разделить библиотеку.
IT>Не надо ничего делить. Надо втащить для старых фреймворков код для совместимости в саму библиотеку, без всяких новых зависимостей. Работы на пол часа. Мы тут дольше это обсуждаем.
Вопрос сколько кода втаскивать и для каких старых фреймворков.
Можно втащить хоть всю библиотеку Theraot (LinqBridge, TaskParallelLibrary и т.д.) вместо зависимости и получить проблемы в других местах.
Здравствуйте, _NN_, Вы писали:
_NN>Для 4.5 и выше на данный момент единственной зависимостью является System.ValueTuple последней версии. _NN>Если код этой библиотеки втащить в CodeJam, то будет конфликт имён если проект использует зависимость на System.ValueTuple.
От System.ValueTuple нужно просто избавиться. У нас нет публичного API, который её использует. А без внутреннего использования можно как-нибудь обойтись.
_NN>Мне кажется, тут проще синхронизировать версии.
С кем синхронизировать? С юзерами, у которых в проектах полный зверинец из всех возможных версий? Они синхронизируют это очень просто — нахрен ваш CodeJam и всё.
IT>>Не надо ничего делить. Надо втащить для старых фреймворков код для совместимости в саму библиотеку, без всяких новых зависимостей. Работы на пол часа. Мы тут дольше это обсуждаем.
_NN>Вопрос сколько кода втаскивать и для каких старых фреймворков.
Сколько нужно столько и втаскивать. В linq2db как-то это получается и нет никаких проблем ни с какой совместимостью.
_NN>Можно втащить хоть всю библиотеку Theraot (LinqBridge, TaskParallelLibrary и т.д.) вместо зависимости и получить проблемы в других местах.
Каких, например?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Для 4.5 и выше на данный момент единственной зависимостью является System.ValueTuple последней версии. _NN>>Если код этой библиотеки втащить в CodeJam, то будет конфликт имён если проект использует зависимость на System.ValueTuple.
IT>От System.ValueTuple нужно просто избавиться. У нас нет публичного API, который её использует. А без внутреннего использования можно как-нибудь обойтись.
Если нет публичного API то достаточно иметь просто internal классы.
Не вижу проблем это исправить.
IT>Сколько нужно столько и втаскивать. В linq2db как-то это получается и нет никаких проблем ни с какой совместимостью.
Посыл я понял.
Таки нужно делить библиотеку тогда.
Скажем, CodeJam библиотека 0 зависимостей.
И например CodeJam.TaskParallelLibary расщиряющий TPL для .NET 3.5 на базе TaskParallelLibrary nuget-а.
Здравствуйте, IT, Вы писали:
_NN>>Можно втащить хоть всю библиотеку Theraot (LinqBridge, TaskParallelLibrary и т.д.) вместо зависимости и получить проблемы в других местах. IT>Каких, например?
При подключенгии второй библиотеки с теми же именами типов Type.GetType("") выдаст много чего интересного. В ту же степь — разные DI с локальным кэшем по Type.FullName.
Так что я — или за готовый слой, или за internal-типы.
P.S. Если есть проблемы с старыми фреймворками — давай issue с репро, бум чинить.
Здравствуйте, _NN_, Вы писали:
_NN>Если нет публичного API то достаточно иметь просто internal классы.
Вот оно в internal классах и используется.
_NN>Не вижу проблем это исправить.
Нужно исправить.
IT>>Сколько нужно столько и втаскивать. В linq2db как-то это получается и нет никаких проблем ни с какой совместимостью. _NN>Посыл я понял. _NN>Таки нужно делить библиотеку тогда. _NN>Скажем, CodeJam библиотека 0 зависимостей. _NN>И например CodeJam.TaskParallelLibary расщиряющий TPL для .NET 3.5 на базе TaskParallelLibrary nuget-а.
Делить тоже плохо. Особенно по такому пустяшному поводу. В данном случае я бы вообще убрал поддержку TPL для 4.0 и ниже. Но если уж кому-то нужно очень очень, тогда действительно можно отдельной сборкой, но при этом соблюсти структуру классов основной сборки, чтобы при переходе на новую версию можно было просто убрать референс из проекта.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, IT, Вы писали:
_NN>>>Можно втащить хоть всю библиотеку Theraot (LinqBridge, TaskParallelLibrary и т.д.) вместо зависимости и получить проблемы в других местах. IT>>Каких, например?
S>При подключенгии второй библиотеки с теми же именами типов Type.GetType("") выдаст много чего интересного. В ту же степь — разные DI с локальным кэшем по Type.FullName. S>Так что я — или за готовый слой, или за internal-типы.
Проблема тор то ясна.
Скажем для .NET 2.0 сейчас неподдерживаемый старый LinqBridge я хочу заменить на более поддерживаемую библиотеку.
Теперь придётся либо переключаться в своём проекте либо огрести конфликты имён из двух библиотек.
S>P.S. Если есть проблемы с старыми фреймворками — давай issue с репро, бум чинить.
CodeJam хочет ValueTuple 4.5.0, а проект использует другую версию, скажем 4.0.0.
Здравствуйте, IT, Вы писали:
IT>Делить тоже плохо. Особенно по такому пустяшному поводу. В данном случае я бы вообще убрал поддержку TPL для 4.0 и ниже. Но если уж кому-то нужно очень очень, тогда действительно можно отдельной сборкой, но при этом соблюсти структуру классов основной сборки, чтобы при переходе на новую версию можно было просто убрать референс из проекта.
У меня есть проект, требует 3.5, и хотелось бы иметь плюшки из CodeJam тоже.
Некоторые проекты вообще с 2.0.
Какие будут предложения ?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Если нет публичного API то достаточно иметь просто internal классы.
IT>Вот оно в internal классах и используется.
Если не считать защищённых членов публичных классов.
public class SuffixTreeBase
{
protected List<(int Start, int Length)> StringLocations { get; }
}
Здравствуйте, Sinix, Вы писали:
S>При подключенгии второй библиотеки с теми же именами типов Type.GetType("") выдаст много чего интересного. В ту же степь — разные DI с локальным кэшем по Type.FullName. S>Так что я — или за готовый слой, или за internal-типы.
А зачем нам такие же типы? Namespace будет другой, можно и имена типам другие дать, тем более, что все они как правило реализуются как расширения. К тому же их можно закатать под internal.
S>P.S. Если есть проблемы с старыми фреймворками — давай issue с репро, бум чинить.
Есть проблема с ненужными зависимостями.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, _NN_, Вы писали:
_NN>У меня есть проект, требует 3.5, и хотелось бы иметь плюшки из CodeJam тоже. _NN>Некоторые проекты вообще с 2.0. _NN>Какие будут предложения ?
Сделать отдельной либой. Так только ты один немножко страдать будешь. Но это нормальная плата за такие хотелки.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Если нет публичного API то достаточно иметь просто internal классы.
IT>Вот оно в internal классах и используется.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>У меня есть проект, требует 3.5, и хотелось бы иметь плюшки из CodeJam тоже. _NN>>Некоторые проекты вообще с 2.0. _NN>>Какие будут предложения ?
IT>Сделать отдельной либой. Так только ты один немножко страдать будешь. Но это нормальная плата за такие хотелки.
Мне всё равно сколько зависимостей добавлять в конечный проект.
Там и так без проблем десяток собирается всякого разного.
Здравствуйте, _NN_, Вы писали:
IT>>Сделать отдельной либой. Так только ты один немножко страдать будешь. Но это нормальная плата за такие хотелки. _NN>Мне всё равно сколько зависимостей добавлять в конечный проект. _NN>Там и так без проблем десяток собирается всякого разного.
Это если ты эти зависимости сам осознано добавляешь, а не через депендеси депенденсей.
Если в проекте сотня нугетов, у которых нет зависимостей, то проблем не будет. А если их только две, у которых зависимости на один другой нугет разных версий, то ждите проблем.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, IT, Вы писали:
IT>>И вообще это недоразумение можно из библиотеки убирать.
AVK>Какое именно недоразумение?
Здравствуйте, IT, Вы писали:
IT>Одна уже есть — System.ValueTuple и она мне уже весь мозг высосала. Пришлось даунгрейдить её до определённой версии из-за конфликтов. Народ на проекте кто ржёт, кто матом орёт и грозиться "вынинуть найух этот твой CodeJam, задолбал он уже". А вы ещё зависимостей добавляете Убирать существующие надо, а не добавлять новые. CodeJam не тот проект, который ну никак не обойдётся без зависимостей.
Нашёл ещё одну зависимость.
Предлагаешь выдернуть код и вставить в CodeJam ?
Здравствуйте, _NN_, Вы писали:
_NN>Нашёл ещё одну зависимость. _NN>Предлагаешь выдернуть код и вставить в CodeJam ?
The System.ComponentModel.DataAnnotations namespace provides attribute classes that are used to define metadata for ASP.NET MVC and ASP.NET data controls.
Стоит ли прибивать библиотеку гвоздями к ASP.NET?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Нашёл ещё одну зависимость. _NN>>Предлагаешь выдернуть код и вставить в CodeJam ?
IT>
IT>The System.ComponentModel.DataAnnotations namespace provides attribute classes that are used to define metadata for ASP.NET MVC and ASP.NET data controls.
IT>Стоит ли прибивать библиотеку гвоздями к ASP.NET?
Всё дело в DisplayAttribute, который определён в System.ComponentModel.DataAnnotations.
А начиная с .NET Core эту сборку вынесли в отдельный пакет.
Вот использование типа.
[PublicAPI]
public class EnumValues : IReadOnlyCollection<EnumValue>
{
[NotNull, ItemNotNull]
private static EnumValue[] GetValues([NotNull] Type enumType)
{
//...foreach (var nameValue in enumNames.Zip(enumValues, (name, value) => (name, value)))
{
var field = fields[nameValue.name];
var displayAttribute = field.GetCustomAttribute<DisplayAttribute>();
Можно конечно через рефлексию доставать, но это просто усложнит код.
Здравствуйте, AndrewVK, Вы писали:
IT>> что перенесено в Blocks (кто только название такое дебильное придумал?). AVK>Есть вариант лучше?
Ну уж не Blocks это точно. Таким названием в своё время называли всякие помоечные отбросы от Майкрософт. Я думал это название уже больше никогда никем не будет использоваться. А тут такое дело. Лучше вообще это удалить с концами и не позориться.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Можно конечно через рефлексию доставать, но это просто усложнит код.
IT>Вот такие решения и отличают девелоперов нежно заботящихся о своих пользователях от всяких остальных мудаков
Хороший вопрос.
В .NET Core вынесли всё в отдельные пакеты.
Как они предполагают, чтобы люди разрабатывали библиотеки тогда ?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
_NN>>Можно конечно через рефлексию доставать, но это просто усложнит код.
IT>Вот такие решения и отличают девелоперов нежно заботящихся о своих пользователях от всяких остальных мудаков
S>>P.S. Если есть проблемы с старыми фреймворками — давай issue с репро, бум чинить. _NN>CodeJam хочет ValueTuple 4.5.0, а проект использует другую версию, скажем 4.0.0.
Если это _реальный_ issue — давай пример (хватит имён пакетов), посмотрю.
Если теория — не верю. Сейчас почти всё таргетит netstandard2, т.е. более-менее свежие версии пакетов.
Плыть против течения очень невыгодно. Текущий тулчайн студии не может в нормальное разруливание конфликтов. Ни с старым форматом csproj, ни с новым.
Поэтому любые несвежие пакеты == копящийся техдолг.
Не, ситуация гораздо лучше, чем год назад, но всё равно не идеальная. Даже с политикой "всегда юзаем самые свежие версии пакетов" конфликты не пропадают. Большая часть из них разруливается через app.config, но бывают случаи, когда изя всё от слова совсем.
К примеру, System.Memory 4.5.2 несовместим с свежим StackExchange.Redis. AssemblyLoadException при любом таргетинге.
Откат до 4.3.0 тоже не прокатит, тогда конфликт будет уже с azure sdk.
Поэтому для боль-менее большого проекта единственная рабочая политикой будет всегда ставить last stable пакеты и временами просить мейнтейнеров пакетов обновить зависимости.
Что утешает, с свежими версиями пакетов ещё можно кое-как победить все проблемы, в крайнем случае — через issue. А вот для легаси (4.5 и ниже) в последние года два с совместимостью настал совсем ппц. Его невыгодно поддерживать, апгрейд получается дешевле и в краткосрочной и долгосрочной перспективе.
С учётом всего, что выше, я предлагаю для боль-менее свежих FW всегда таргетить самые свежие пакеты.
Для легаси — самые свежие поддерживаемые и делать downgrade по запросу с real issue.
Здравствуйте, IT, Вы писали:
IT>А зачем нам такие же типы? Namespace будет другой, можно и имена типам другие дать, тем более, что все они как правило реализуются как расширения. К тому же их можно закатать под internal.
А, тогда надо типы вообще прятать. Изначально мы в CJ встроили мини-слой таргетинга, который бэкпортил типы в младшие фреймворки.
Если идея не взлетела, то надо убирать в internal, конечно.
Здравствуйте, IT, Вы писали:
IT>Лучше вообще это удалить с концами и не позориться.
Давай без срача
Если есть конкретная проблема или предложение — всегда велкам. Про "убрать зависимости" услышал, бум думать.
Для остального пока обоснования не увидел.
Здравствуйте, Sinix, Вы писали:
IT>>Лучше вообще это удалить с концами и не позориться. S>Если есть конкретная проблема или предложение — всегда велкам.
Конкретное предложение — убрать Blocks за ненадобностью. В качестве бонуса получим "не позориться".
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Sinix, Вы писали:
IT>>>Лучше вообще это удалить с концами и не позориться. S>>Если есть конкретная проблема или предложение — всегда велкам.
IT>Конкретное предложение — убрать Blocks за ненадобностью. В качестве бонуса получим "не позориться".
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Sinix, Вы писали:
S>>Вопрос два: смысл? Есть ли реальный кейс для добавления поддержки?
IT>Лучше добавить поддержку Core 1.6.
Имеется ввиду .NET Standard 1.6 я так понимаю ?
Практически готово осталось решить 92 ошибки компиляции
Если нам не помогут, то мы тоже никого не пощадим.
