NuGet писали долболомы?
От: SergASh  
Дата: 07.11.14 20:46
Оценка: -1
Привет всем!

Есть solution на три проекта:
— Core
— Data
— Web

Иду в NuGet'ную командную строку, командую:
install-package nhibernate -ProjectName Data

В папке packages наблюдаю
Iesi.Collections.4.0.0
NHibernate.4.0.1

Командую дальше
install-package iesi.collections -ProjectName Core

Теперь в папке packages вот что
Iesi.Collections.4.0.0
Iesi.Collections.4.0.1
NHibernate.4.0.1

То есть теперь Core зависит от коллекций версии 4.0.1, а Data зависит от версии 4.0.0.
Проект Web зависит от обоих проектов Core и Data. В результате в Web/bin/Debug попадет случайная версия Iesi.Collections.dll.

Ни тебе предупреждений от нугета, что мол возможен конфликт. Ни попытки зареференсить уже используемую версию.
И это при том, что в NHibernate'е прописана зависимость от коллекций версии >=4.0 & <5.0.
То есть возможно автоматическое разрешение проблемы.

Непонятно на что сдалась такая "автоматизация", если все равно надо руками все править?
Или я может её не так готовлю?
Re: NuGet писали долболомы?
От: bnk СССР http://unmanagedvisio.com/
Дата: 07.11.14 23:39
Оценка: +1
Здравствуйте, SergASh, Вы писали:

SAS>Непонятно на что сдалась такая "автоматизация", если все равно надо руками все править?

SAS>Или я может её не так готовлю?

Оно обычно попроектно ставит. Т.е. согласованность в рамках одного проекта.
Может Update-Package после инсталляции подойдет (обноваить-все-на-последнюю-версию)?

Или может сначала добавить все что надо на уровне солюшена, а потом применить на проекты (галки поставить)?
http://blog.spinthemoose.com/2013/04/21/nuget-tip-3-manage-packages-at-the-solution-level/
Re: NuGet писали долболомы?
От: Слава  
Дата: 08.11.14 10:46
Оценка:
Здравствуйте, SergASh, Вы писали:

SAS>В папке packages наблюдаю

SAS>[code]
SAS>Iesi.Collections.4.0.0
SAS>NHibernate.4.0.1

Извиняюсь за непрошенный совет, но NHibernate тоже писали долболомы. То есть, вещь это громоздкая, сложная, медленная и с уймой странностей. Лучше бы ей вообще не пользоваться. Существует linq2db, он прост и понятен.

Ну и выше вам правильно пишут — пакеты ставятся на весь солюшн, а затем назначаются одному или нескольким проектам, входящим в солюшн.
Re: NuGet писали долболомы?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.11.14 13:49
Оценка: -1
Здравствуйте, SergASh, Вы писали:

SAS>Ни тебе предупреждений от нугета, что мол возможен конфликт. Ни попытки зареференсить уже используемую версию.

SAS>И это при том, что в NHibernate'е прописана зависимость от коллекций версии >=4.0 & <5.0.
SAS>То есть возможно автоматическое разрешение проблемы.
А оно и работает, если ты сначала поставишь Iesi.Collections, а потом NHibername , то в проекте у тебя будет одна версия Iesi.Collections.

NuGet не знает как ты используешь пакеты, поэтому не может тебе сказать что у тебя ссылки на разные версии одной сборки в результате получаются.

SAS>Непонятно на что сдалась такая "автоматизация", если все равно надо руками все править?

SAS>Или я может её не так готовлю?
Конечно не так. Пакеты надо ставить в порядке зависимостей.
Re[2]: NuGet писали долболомы?
От: SergASh  
Дата: 08.11.14 14:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А оно и работает, если ты сначала поставишь Iesi.Collections, а потом NHibername , то в проекте у тебя будет одна версия Iesi.Collections.

Ну до этого я конечно додумался, спасибо.

G>NuGet не знает как ты используешь пакеты, поэтому не может тебе сказать что у тебя ссылки на разные версии одной сборки в результате получаются.

Что стоит ему об этом узнать глядя на зависимости между проектами?

SAS>>Или я может её не так готовлю?

G>Конечно не так. Пакеты надо ставить в порядке зависимостей.

Надеюсь вы не станете спорить, что это не всегда возможно? Проекты развиваются и в какой из них что надо добавить заранее обычно не известно. А в солюшен их объединяют ведь неспроста, между проектами всегда есть зависимости. И если менеджер пакетов это не учитывает, то это недопиленный менеджер пакетов.
Re: NuGet писали долболомы?
От: SergASh  
Дата: 09.11.14 12:27
Оценка: -1
"Все страньше и страньше", — думала Алиса..

Похоже там не только авторы нугета тупенькие, но и авторы некоторых пакетов.

Ставлю log4net:
install-package log4net -projectname Data

В результате в packages появляется папка
log4net.2.0.3

А внутри сборка log4net.dll, у которой в метаданных стоит версия 1.2.13, которую студия и показывает в свойствах reference'а.

Как можно мириться с таким бардаком?
  Скрытый текст
Что-то я не припоминаю, чтоб кто-то до рождения нугета жаловался, что тратит сильно много времени на добавление библиотек. Зато теперь трах обепечен
Re: NuGet писали долболомы?
От: drol  
Дата: 09.11.14 14:56
Оценка: -1
Вообще-то весь софт на планете написан долболомами. А .NET и его библиотеки — ещё и особенно отборными. Как не загляну внутрь — везде какой-то ад. За DateTime, например, надо провести децимацию всей Microsoft. За ICollection<T> сотоварищи — ещё одну.

SAS>Ни тебе предупреждений от нугета, что мол возможен конфликт.


Это неправильно. Полностью с Вами согласен.

SAS> Ни попытки зареференсить уже используемую версию.


Однако, такое поведение NuGet вполне логично. Зависимости фиксируются на момент публикации пакета. Если позже появились новые версии зависимых пакетов, то даже если они удовлетворяют заданным правилам типа >=4.0 & <5.0, совершенно не факт, что реальная совместимость сохранилась. Посему, загрузка только версий существовавших на момент публикации — разумный подход. Другое дело, что должна быть возможность управления выбором стратегии на тему и соответствующий интерфейс во всех местах.
Re[2]: NuGet писали долболомы?
От: drol  
Дата: 09.11.14 14:58
Оценка:
Здравствуйте, Слава, Вы писали:

С>Ну и выше вам правильно пишут — пакеты ставятся на весь солюшн, а затем назначаются одному или нескольким проектам, входящим в солюшн.


С solution аналогичная ботва. Проблема в другом: http://rsdn.ru/forum/dotnet/5847869?tree=tree
Автор: drol
Дата: 09.11.14
Re[2]: NuGet писали долболомы?
От: fddima  
Дата: 09.11.14 16:40
Оценка:
Здравствуйте, drol, Вы писали:

D>За DateTime, например, надо провести децимацию всей Microsoft.

А что конкретно не нравится в DateTime?
Re[3]: NuGet писали долболомы?
От: drol  
Дата: 09.11.14 17:19
Оценка:
Здравствуйте, fddima, Вы писали:

F> А что конкретно не нравится в DateTime?


Можете начать с изучения его операторов сравнения.
Re[4]: NuGet писали долболомы?
От: fddima  
Дата: 09.11.14 17:32
Оценка:
Здравствуйте, drol, Вы писали:

F>> А что конкретно не нравится в DateTime?

D>Можете начать с изучения его операторов сравнения.
Чего там изучать — сравниваются тики, без учета служебных бит. Вы ожидали что-то другое?
Если же это намек на Kind — то это не самое плохое решение.
Если DateTime совсем уж так не подходит — берите Noda Time. Но там, — как и везде — тоже не всё идеально.
Re[5]: NuGet писали долболомы?
От: drol  
Дата: 09.11.14 18:15
Оценка: +1
Здравствуйте, fddima, Вы писали:

F> Чего там изучать — сравниваются тики, без учета служебных бит. Вы ожидали что-то другое?


Да. Я ожидал проверку Kind. Нынешний же код операций сравнения означает отсутствие у DateTime ключевых свойств нормального типа, а именно — корректности и полноты. На ровном месте можно получить практически undefined behaviour.

F> Если же это намек на Kind — то это не самое плохое решение.


Плохое решение — мешать в кучу три перпендикулярных ответственности. DateTime нарушает практически все базовые принципы\правила дизайна типов. Остальное это лишь следствия.

F> Если DateTime совсем уж так не подходит — берите Noda Time.


Я не проникся NodaTime. Какая-то она громоздкая и неудобная. Время есть суть полная функциональщина. Код на тему должен литься непрерывно и непринуждённо с любой точки. А там постоянно какие-то конструкторы внезапно вылезают и т.п.
Re[6]: NuGet писали долболомы?
От: fddima  
Дата: 09.11.14 19:09
Оценка:
Здравствуйте, drol, Вы писали:

F>> Чего там изучать — сравниваются тики, без учета служебных бит. Вы ожидали что-то другое?

D>Да. Я ожидал проверку Kind. Нынешний же код операций сравнения означает отсутствие у DateTime ключевых свойств нормального типа, а именно — корректности и полноты. На ровном месте можно получить практически undefined behaviour.
F>> Если же это намек на Kind — то это не самое плохое решение.
D>Плохое решение — мешать в кучу три перпендикулярных ответственности. DateTime нарушает практически все базовые принципы\правила дизайна типов. Остальное это лишь следствия.
Они посчитали, что ремарки в документации об этом достаточно. Да, неудобно, — но жить можно. Мне приходилось конечно сравнивать даты, но они всегда при этом были получены из одного источника с одинаковым Kind — поэтому проблемы не было. А вот невозможность конвертации из одного kind в другой — встречалась — и тут адекватного варианта решения "на автомате" не будет. Есть мнение что если переизобрести DateTime & co. по уму — то получится что-то вроде NodaTime, который тебе же кажется громоздким.
Это приблизительно как и с ICollection — многие ноют, но вместе с тем — сами же его широко используют (хотя никто не заставляет).

F>> Если DateTime совсем уж так не подходит — берите Noda Time.

D>Я не проникся NodaTime. Какая-то она громоздкая и неудобная. Время есть суть полная функциональщина.
D>Код на тему должен литься непрерывно и непринуждённо с любой точки. А там постоянно какие-то конструкторы внезапно вылезают и т.п.
Ну работать с ним можно + меня больше интересовала поддержка tzdb, а не этот BCL / windows-specific бред, который непойми когда обновляется и обновляется ли вообще (в продакшне).
Re[7]: NuGet писали долболомы?
От: drol  
Дата: 09.11.14 22:19
Оценка: 3 (1) +1 :)
Здравствуйте, fddima, Вы писали:

F> Они посчитали, что ремарки в документации об этом достаточно.


Да не считали они ничего. Просто поручили работу какому-нибудь школоло. Ведь тип для времени это так просто

F> Да, неудобно, — но жить можно.


Называть такое жизнью нельзя.

F>Мне приходилось конечно сравнивать даты, но они всегда при этом были получены из одного источника с одинаковым Kind — поэтому проблемы не было.


Вы очень большой оптимист. В том и дело, что проблема просто так не видна. Если нет соответствующих тестов, то, например, можно ВНЕЗАПНО обнаружить, что полгода по субботам ресурсы в статистике не учитывались.

Дальше — больше. Тот же EF, например, при чтении DateTime всегда отдаёт как Unspecified. А вот записать можно с каким угодно Kind'ом.

F>А вот невозможность конвертации из одного kind в другой — встречалась — и тут адекватного варианта решения "на автомате" не будет.


Так оно и не нужно. DateTimeKind это бред.

F>Есть мнение что если переизобрести DateTime & co. по уму — то получится что-то вроде NodaTime, который тебе же кажется громоздким.


NodaTime кривая прежде всего из-за того, что является портом древней Java-библиотеки. Никаких принципиальных проблем сделать новую нормальную и на современном C# нет.

F> Это приблизительно как и с ICollection — многие ноют, но вместе с тем — сами же его широко используют (хотя никто не заставляет).


Приехали. Стандартные collection'ы пронизывают весь .NET — библиотеки, CLR, семантику языков. Как Вы собрались их не использовать ??? Везде оборачивать во врапперы и обратно ???

F> Ну работать с ним можно + меня больше интересовала поддержка tzdb, а не этот BCL / windows-specific бред, который непойми когда обновляется и обновляется ли вообще (в продакшне).


tzdb и Microsoft'овская работа на тему стоят друг друга. Когда я изучал вопрос, то мой итоговый вывод был таков: нормального решения на данный момент не существует. Все поделки по этой части не предлагают никакой внятной и адекватной модели предметной области, да ещё и постоянно тащут с собой безумные ужасы совместимости с какими-то древними примитивными маразмами.
Re[2]: NuGet писали долболомы?
От: Doc Россия http://andrey.moveax.ru
Дата: 10.11.14 12:35
Оценка:
Здравствуйте, SergASh, Вы писали:

SAS>А внутри сборка log4net.dll, у которой в метаданных стоит версия 1.2.13, которую студия и показывает в свойствах reference'а.


И причем тут NuGet?
Re[2]: NuGet писали долболомы?
От: IT Россия linq2db.com
Дата: 13.11.14 19:16
Оценка: 8 (2) +1 :))) :)))
Здравствуйте, Слава, Вы писали:

С>Существует linq2db, он прост и понятен.


Подтверждаю. linq2db нереарльно крут.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: NuGet писали долболомы?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.11.14 09:51
Оценка:
Здравствуйте, IT, Вы писали:

IT>Подтверждаю. linq2db нереарльно крут.


Надо только нам дизайнер модели все таки запилить.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re[3]: NuGet писали долболомы?
От: artelk  
Дата: 17.11.14 10:16
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Слава, Вы писали:


С>>Существует linq2db, он прост и понятен.


IT>Подтверждаю. linq2db нереарльно крут.


Пользуясь случаем: а асинхронщина в нем настоящая есть или только через Task.Run?
Re[4]: NuGet писали долболомы?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.11.14 11:18
Оценка:
Здравствуйте, artelk, Вы писали:

A>Пользуясь случаем: а асинхронщина в нем настоящая есть или только через Task.Run?


Пока только второе — многовато работы по дублированию асинхронных версий методов.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re[5]: NuGet писали долболомы?
От: artelk  
Дата: 17.11.14 14:33
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, artelk, Вы писали:


A>>Пользуясь случаем: а асинхронщина в нем настоящая есть или только через Task.Run?

AVK>Пока только второе — многовато работы по дублированию асинхронных версий методов.

Ок, а планируется? Штука позволяет экономить на потоках пула в случае, когда оно является узким местом — например, когда для подавляющего большинства запросов к базе результат отдается из кэша СУБД.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.