Нужно ли проверять файл project.lock.json в системе контроля версий? (ASP.NET Core 1.0)

asp.net

6508 просмотра

3 ответа

4592 Репутация автора

При использовании ASP.NET Core 1.0 рекомендуется ли проверять файл project.lock.json в системе контроля версий ?

Автор: Ender2050 Источник Размещён: 19.07.2016 02:03

Ответы (3)


0 плюса

114 Репутация автора

Нет, это просто файл блокировки , на самом деле вы никогда не должны регистрировать его, когда файл блокировки существует (кроме случаев, когда программа, которая заблокировала его, хочет проверить его в системе контроля версий, в этом случае исключите файл блокировки!).

Автор: mjz19910 Размещён: 19.07.2016 02:06

42 плюса

3326 Репутация автора

Решение

Краткий ответ : Нет, project.lock.file не должен быть включен в систему контроля версий - вы должны настроить систему контроля версий так, чтобы она игнорировалась (т.е. добавьте ее в .gitignore, если вы используете git).

Длинный ответ : project.lock.json содержит снимок всего дерева зависимостей проекта - не только пакеты, перечисленные в разделах «зависимости», но также все разрешенные зависимости этих зависимостей и т. Д. Но это не похоже на Gemfile.lock в ruby . В отличие от Gemfile.lock, project.lock.json не указывает, dotnet restoreкакие именно версии пакетов должны быть восстановлены - он просто перезаписывается. Как таковой, он должен рассматриваться как файл кэша и никогда не проверяться в системе контроля версий.

Если вы проверите это в системе контроля версий, то, скорее всего, на другой машине:

  • dotnet будет думать, что все пакеты восстановлены, но на самом деле некоторые пакеты могут отсутствовать, и сборка не удастся, без намека разработчика на запуск dotnet restore
  • Project.lock.json будет перезаписан во время dotnet restoreи в большинстве случаев будет отличаться от версии, хранящейся в системе контроля версий. Так что он будет изменен практически при каждом коммите
  • project.lock.json вызовет конфликты во время слияния
Автор: qbik Размещён: 19.07.2016 03:31

4 плюса

7144 Репутация автора

На самом деле вы иногда хотите зафиксировать свой project.lock.json в git.

Проверка вашего проекта JSON

По точным причинам, он показывает вам зависимости, которые вы использовали. Сказать:

  1. Я как разработчик работаю над приложением, я ненавижу каждый раз обновлять пакеты, поэтому я добавляю зависимость пакета к пакету nuget X = 1. *
  2. Я восстановил пакет, я получил версию 1.2.4
  3. Производитель пакетов только что сделал очень глупую ошибку, он что-то сломал, пытаясь исправить и выпустить 1.2.5
  4. Человек 2 проверяет (или, что еще хуже, релиз релизов).
  5. Человек 2 восстанавливает и получает версию 1.2.5
  6. Человек 2 запускает ваше приложение и обнаруживает, что приложение не работает.
  7. Человек 2 начинает отладку и думает, что в программном обеспечении должна быть ошибка.

На этом шаге 7 человек 2 мог видеть в git, что его файл блокировки был изменен, и была загружена более новая версия библиотеки, которая не была протестирована ни одним из других разработчиков!

Downsides

Недостатки проверки в этом файле - вы можете получить множество конфликтов слияния при продолжении обновления пакетов.

Альтернативное решение

Используйте только жесткие зависимости версий (это довольно сложно, хотя для nuget). И только вручную обновлять до новой версии время от времени.

Downsides

  • Это не работает, если вы создаете библиотеку для использования другими людьми, поскольку вы прикрепляете их к определенной версии ваших зависимостей.
  • Зависимости зависимостей по-прежнему разрешаются автоматически, поэтому, если вы не укажете их сами, вы не сможете гарантировать их версию на dotnet restore

Заключение

Если вы хотите избежать кавычек «Работает на моей машине» и, черт возьми, постоянно обновляться вручную до новой версии: проверьте файл project.lock.json.

А также создайте проверку сборки CI / Release, чтобы проверить, не изменился ли этот файл по сравнению с git, перед выпуском (если ваше программное обеспечение очень критично)!

Если это не проблема, а также автоматическое обновление (до потенциально испорченного пакета) не является большой проблемой, возможно, вы не захотите зафиксировать свой project.lock.json.

Автор: Joel Harkes Размещён: 27.01.2017 10:13
Вопросы из категории :
32x32