Должен ли я зафиксировать свою папку wwwroot/lib в веб-приложении ASP .Net Core?
Я только что создал веб-приложение ASP .Net с помощью команды dotnet new webapp.
Интересно, нужно ли зафиксировать папку wwwroot/lib?
Похоже, что он содержит версионные библиотеки, и версия больше нигде в приложении не упоминается, поэтому я думаю, что мне следует их зафиксировать.
Но я действительно не хочу иметь дистрибутивы сторонних библиотек в моем репозитории git.
Другой компромисс, о котором никто не упоминал ранее (и я уже сталкивался с этим раньше), заключается в том, что какая-либо из этих библиотек становится недоступной или вам нужно запустить очень старую сборку с использованием гораздо более старых версий фреймворка/библиотеки, и эти библиотеки не могут быть загружены или собраны/скомпилированы с более новыми версиями фреймворка и доступными собственными заголовками/компиляторами.
Ответы 3
Если ваша команда согласовала, какие библиотеки использовать, и их версии ясны, вы можете написать список библиотек в файле сведений, чтобы напомнить другим участникам.
Если указанная библиотека невелика и вы хотите лучше обеспечить целостность кода, вы можете зафиксировать wwwroot/lib.
С недавними изменениями в основном веб-приложении ASP.Net. вы можете игнорировать добавление клиентской библиотеки (содержимое папки wwwroot) в свой контроль версий, такой как git.
они должны быть восстановлены во время сборки.
вы можете использовать LibMan для восстановления этих библиотек во время сборки.
эта статья от Microsoft расскажет вам, как включить восстановление клиентской библиотеки во время сборки, чтобы вам не приходилось добавлять их в систему управления версиями.
поскольку он также содержит конкретную версию, поэтому проблем с совместимостью не будет.
пример файла libman.json
{
"version": "1.0",
"defaultProvider": "cdnjs",
"libraries": [
{
"library": "[email protected]",
"files": [
"jquery.min.js",
"jquery.js",
"jquery.min.map"
],
"destination": "wwwroot/lib/jquery/"
},
{
"provider": "unpkg",
"library": "[email protected]",
"destination": "wwwroot/lib/bootstrap/"
},
{
"provider": "filesystem",
"library": "C:\\temp\\lodash\\",
"files": [
"lodash.js",
"lodash.min.js"
],
"destination": "wwwroot/lib/lodash/"
}
]
}
Надеюсь, это полезно.
Я использую Libman в течение многих лет. В последнее время были некоторые сбои, приводящие к недоступности пакетов. В одном из своих проектов я даже решил удалить Libman и поместить каждую зависимость в папку lib-raw с контролируемой версией, где я закрепляю определенные версии зависимостей.
@citronas Просто любопытно, как вы управляете ими в проекте? И какой инструмент вы используете для управления им?
@CesarB Мы используем Git для контроля версий
Решение представляет собой компромисс между временем сборки и наличием «восстанавливаемых» файлов в репозитории. В нескольких проектах я изначально игнорировал файлы в wwwroot/lib и использовал libman.json и восстановление клиентских библиотек во время сборки . Это восстановление повлияло на «бесплатные минуты», предоставляемые CI (Github Actions, Azure DevOps), поэтому я отменил свое решение; и вручную восстановил эти файлы и отправил файлы wwwroot/lib в репозиторий.
Если бесплатные минуты сборки не являются ограничением, я бы рекомендовал не хранить файлы в системе контроля версий.
dotnet new mvcпоставляется с 57 файлами общим размером 7,8 МБ в папкеwwwroot/lib, но без системы управления пакетами, которая могла бы вытащить их, если они не являются частью репозитория. Странно фиксировать так много сторонних файлов и добавлять их в свой собственный контроль версий.