Здравствуйте, _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>();
Можно конечно через рефлексию доставать, но это просто усложнит код.
Здравствуйте, IT, Вы писали:
IT>>>И вообще это недоразумение можно из библиотеки убирать. AVK>>Какое именно недоразумение?
IT>MapperBuilder и всё с ним связанное
Что с ним не так?
IT> что перенесено в Blocks (кто только название такое дебильное придумал?).
Здравствуйте, 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 ошибки компиляции
Если нам не помогут, то мы тоже никого не пощадим.
Убирать существующие надо, а не добавлять новые. CodeJam не тот проект, который ну никак не обойдётся без зависимостей.
