Сообщение Re: NuGet Package Restore или хранение исходников в VCS от 09.02.2015 6:48
Изменено 09.02.2015 7:02 Aquilaware
Здравствуйте, Нахлобуч, Вы писали:
Н>Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в VCS (Mercurial, чтобы быть конкретным), другие -- за то, чтобы полагаться на NuGet Package Restore.
Наиболее правильный вариант — это хранить все исходники всех зависимостей у себя в системе контроля версий. Скажу даже более, их нужно подписывать только своим ключом. При этом избегать хранения DLL/LIB/EXE файлов, т.к. это может раздуть репозиторий и привнести неоднозначности при сборке.
Возможно для многих людей это не очевидно, но если не делать так, как я только что посоветовал, происходят такие веши:
Опять же, восприятие решения вашего вопроса сильно зависит от отношения к работе и проекту того или иного человека. Если это попрыгун который меняет работу раз в год или два то ему пофиг на все и он будет кричать "за NuGet". Почему? Потому что его не коснется то, что будет с проектом через 3 года и ему все равно, он просто плывет как течению как бревно на сплаве.
В то же время, NuGet просто необходимо использовать для таких инфраструктурных вещей как ASP.NET, MVC, Azure. Если вы делаете вэб-приложение, то NuGet можно использовать более широко и вольно, т.к. нет проблемы GAC-hell, плюс время активной разработки вэб-проектов зачастую ниже. Также ниже плотность логики и нет такой необходимости возвращаться к деталям из ревизии XXXX. Т.е. NuGet для вэба работает намного лучше.
Н>Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в VCS (Mercurial, чтобы быть конкретным), другие -- за то, чтобы полагаться на NuGet Package Restore.
Наиболее правильный вариант — это хранить все исходники всех зависимостей у себя в системе контроля версий. Скажу даже более, их нужно подписывать только своим ключом. При этом избегать хранения DLL/LIB/EXE файлов, т.к. это может раздуть репозиторий и привнести неоднозначности при сборке.
Возможно для многих людей это не очевидно, но если не делать так, как я только что посоветовал, происходят такие веши:
- Блин, как же мне вернуться на тот revision чтобы проверить вот этот очень специфический случай зависящий от стороней библиотеки версии X.X от 24 июня 2013 года?
Приложение падало с NullReferenceException у одного клиента (у остальных 999-ти работало). Оказалось, что на машине клиента кто-то поставил в GAC модифицированную версию open source библиотеки с таким же strong name, поэтому наша программа невольно использовала эту несанкционированную и непроверенную версию модуля. А всё потому, что большинство open source проектов светят везде свои .snk ключи, вообще не задумаваясь к чему это может привести. Коммерческие поставщики (например, VistaDB) также этим грешат. Поэтому, переподписывайте все сторонние модули которые вы используете, иначе будет вам GAC-hell. Естественно, NuGet не уместен при таких требованиях
Блин, сайт open source библиотеки умер, автор удалил NuGet пакет из репозитория. Что же нам теперь делать? Где взять сорцы?
Опять же, восприятие решения вашего вопроса сильно зависит от отношения к работе и проекту того или иного человека. Если это попрыгун который меняет работу раз в год или два то ему пофиг на все и он будет кричать "за NuGet". Почему? Потому что его не коснется то, что будет с проектом через 3 года и ему все равно, он просто плывет как течению как бревно на сплаве.
В то же время, NuGet просто необходимо использовать для таких инфраструктурных вещей как ASP.NET, MVC, Azure. Если вы делаете вэб-приложение, то NuGet можно использовать более широко и вольно, т.к. нет проблемы GAC-hell, плюс время активной разработки вэб-проектов зачастую ниже. Также ниже плотность логики и нет такой необходимости возвращаться к деталям из ревизии XXXX. Т.е. NuGet для вэба работает намного лучше.
Здравствуйте, Нахлобуч, Вы писали:
Н>Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в VCS (Mercurial, чтобы быть конкретным), другие -- за то, чтобы полагаться на NuGet Package Restore.
Наиболее правильный вариант — это хранить все исходники всех зависимостей у себя в системе контроля версий. Скажу даже более, их нужно подписывать только своим ключом. При этом избегать хранения DLL/LIB/EXE файлов, т.к. это может раздуть репозиторий и привнести неоднозначности при сборке.
Возможно для многих людей это не очевидно, но если не делать так, как я только что посоветовал, происходят такие веши:
Опять же, восприятие решения вашего вопроса сильно зависит от отношения к работе и проекту того или иного человека. Если это попрыгун который меняет работу раз в год или два то ему пофиг на все и он будет кричать "за NuGet". Почему? Потому что его не коснется то, что будет с проектом через 3 года и ему все равно, он просто плывет как течению как бревно на сплаве.
В то же время, NuGet просто необходимо использовать для таких инфраструктурных вещей как ASP.NET, MVC, Azure. Если вы делаете вэб-приложение, то NuGet можно использовать более широко и вольно, т.к. нет проблемы GAC-hell, плюс время активной разработки вэб-проектов зачастую ниже. Также ниже плотность логики и нет такой необходимости возвращаться к деталям из ревизии XXXX. Т.е. NuGet для вэба работает намного лучше.
В итоге получаем такую схему:
Н>Возник у нас тут спор, что делать с зависимостями и сторонними библиотеками. Разделились на два лагеря: одни за хранение всего и вся в VCS (Mercurial, чтобы быть конкретным), другие -- за то, чтобы полагаться на NuGet Package Restore.
Наиболее правильный вариант — это хранить все исходники всех зависимостей у себя в системе контроля версий. Скажу даже более, их нужно подписывать только своим ключом. При этом избегать хранения DLL/LIB/EXE файлов, т.к. это может раздуть репозиторий и привнести неоднозначности при сборке.
Возможно для многих людей это не очевидно, но если не делать так, как я только что посоветовал, происходят такие веши:
- Блин, как же мне вернуться на тот revision чтобы проверить вот этот очень специфический случай зависящий от стороней библиотеки версии X.X от 24 июня 2013 года?
Приложение падало с NullReferenceException у одного клиента (у остальных 999-ти работало). Оказалось, что на машине клиента кто-то поставил в GAC модифицированную версию open source библиотеки с таким же strong name, поэтому наша программа невольно использовала эту несанкционированную и непроверенную версию модуля. А всё потому, что большинство open source проектов светят везде свои .snk ключи, вообще не задумаваясь к чему это может привести. Коммерческие поставщики (например, VistaDB) также этим грешат. Поэтому, переподписывайте все сторонние модули которые вы используете, иначе будет вам GAC-hell. Естественно, NuGet не уместен при таких требованиях
Блин, сайт open source библиотеки умер, автор удалил NuGet пакет из репозитория. Что же нам теперь делать? Где взять сорцы?
Опять же, восприятие решения вашего вопроса сильно зависит от отношения к работе и проекту того или иного человека. Если это попрыгун который меняет работу раз в год или два то ему пофиг на все и он будет кричать "за NuGet". Почему? Потому что его не коснется то, что будет с проектом через 3 года и ему все равно, он просто плывет как течению как бревно на сплаве.
В то же время, NuGet просто необходимо использовать для таких инфраструктурных вещей как ASP.NET, MVC, Azure. Если вы делаете вэб-приложение, то NuGet можно использовать более широко и вольно, т.к. нет проблемы GAC-hell, плюс время активной разработки вэб-проектов зачастую ниже. Также ниже плотность логики и нет такой необходимости возвращаться к деталям из ревизии XXXX. Т.е. NuGet для вэба работает намного лучше.
В итоге получаем такую схему:
- Для десктоп приложений — NuGet вообще нельзя использовать, так как можно нарваться на GAC-hell
Для остальных приложений — NuGet можно использовать (и иногда даже нужно). Но с опаской и аккуратно. Оценивайте время жизни проекта. Если это enterprise с временем жизни > 3 лет, то минимизируйте использование NuGet, так как даже самое на первый взгляд невинное изменение в сторонней библиотеке будет ломать вашу функциональность и процессы.