Проверяете пакеты из NuGet в системе контроля версий?

87

До NuGet общепринятой «передовой практикой» была регистрация всех внешних библиотек DLL, используемых в проекте. Обычно в каталоге Libsили 3rdParty.

При работе с NuGet должен ли я возвращаться в packagesкаталог или есть ли способ для MSBuild автоматически загружать необходимые пакеты из канала nuget?

version-control  msbuild  nuget 
— Скотт Вайнштейн
источник
2
Ответ на это вопрос личного мнения. Лагерь «исключить / нет» утверждает, что, поскольку предоставленный набор функций позволяет во время разработки и сборки просто извлекать из репозитория пакетов (например, nuget.org), это можно сделать просто во время сборки. Лагерь «включить / Да» утверждает, что код не будет построен без пакетов, если внешний репозиторий станет недоступен. Прочтите обе стороны, прежде чем принимать решение. См. Также: softwareengineering.stackexchange.com/questions/301547/…
— CJBS

Ответы:

68

Нет

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

Из консоли диспетчера пакетов вам необходимо установить NuGetPowerTools :

Install-Package NuGetPowerTools

Затем, чтобы ваши проекты поддерживали восстановление пакетов, вам нужно запустить другую команду:

Enable-PackageRestore

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

Источник

Использование NuGet без передачи пакетов в систему управления версиями

— Эдвард Уайльд
источник
41
Начиная с NuGet-1.6, вам больше не нужны NuGetPowerTools для этого. Просто щелкните правой кнопкой мыши на решение в обозревателе решений и выберите, Enable NuGet Package Restore. См. Документы .
— Калеб Педерсон
3
Да, вы должны проверить папку .nuget и файлы под ней.
— absynce 05
11
@Edward - С философской точки зрения, почему бы вам не включить пакеты NuGet в систему управления версиями, учитывая, что они являются зависимостями? То, что проверено в системе контроля версий, должно составлять 100% кода, достаточного для сборки. Не включая пакеты NuGet, создаются внешние зависимости, например. что, если место загрузки пакета изменилось, или по какой-то странной причине он больше не доступен и т. д. Или, что более вероятно, что, если есть небольшое изменение в пакете, который позже повторно загружается, и это нарушает сборку? Этого можно было бы избежать, если бы все необходимое для сборки проекта находилось в системе управления версиями.
— Howiecamp
5
@Howiecamp Я не могу с этим согласиться. Я не понимаю логики. Я хочу, чтобы система управления версиями была полностью автономной. Особенно, если проект несколько устаревший и какое-то время не используется. Я хочу вернуться и заставить его работать без изменений. Nuget - это единственная точка отказа, которую я не хочу иметь.
— Telavian
2
@Howiecamp Наше решение - разместить наш собственный сервер nuget и поместить все пакеты nuget, внутренние и внешние, в GIT-LFS. Это устраняет единую точку отказа и сохраняет все под контролем версий. Но мы все еще не проверяем папку пакетов - и мы по-прежнему используем автоматическое восстановление пакетов
— Каспер Леон Нильсен
30

Да. Считайте, что каталог "packages" эквивалентен вашему каталогу "libs", который вы упомянули в своем вопросе. Я лично использую этот подход в своих проектах OSS.

Мы изучаем функции, которые позволили бы MSBuild автоматически загружать необходимые пакеты, но это не было реализовано (начиная с NuGet 1.1).

Я думаю, что некоторые люди, возможно, уже реализовали такие функции самостоятельно, но мы планируем рассмотреть возможность включения этой функции в NuGet 1.2 или 1.3, надеюсь.

— Haacked
источник
10
Я определенно хотел бы, чтобы эта функция была добавлена. Было бы неплохо иметь возможность загружать пакеты по мере необходимости на сервер CI или на ПК разработчика, чтобы избежать раздувания репозитория системы управления версиями сторонними библиотеками DLL.
— Джон Миллс,
2
Если бы менеджер пакетов в Visual Studio и инструмент командной строки могли «восстанавливать пакеты», это было бы здорово.
— Шон Уилсон
1
Возможно, было бы хорошо удалить / отредактировать этот ответ, теперь он устарел
— Лекс
3
@Tim ответ не актуален imho
— Эдвард Уайльд
4
Этот ответ все еще актуален. Рассмотрите пакеты, которых нет в глобальном репозитории (нет возможности восстановить / загрузить их). IMHO, это хорошая практика - хранить пакеты в системе управления версиями.
— Павел Ходек 06
6

Несмотря на все ответы здесь, это по-прежнему просто ужасное решение - не иметь всех ваших зависимостей под «каким-то» контролем версий.

Для GIT это будет означать GIT-LFS.

Недавний эпизод с NPM показывает, почему: если интернет-репозиторий, от которого вы зависите, ломается, недоступен и т. Д., Тогда вы облажались, не так ли?

Вы больше не можете создавать свои вещи - и, следовательно, не можете их доставить.

— Каспер Леон Нильсен
источник
1
Это очень хороший момент. Даже если у нас есть собственный внутренний сервер NuGet, можем ли мы рассчитывать на то, что он всегда будет доступен во время сборки? Кроме того, как часто наши пакеты меняются, чтобы нам всегда приходилось получать новую копию для каждой сборки?
— Джош П.
npmсломался, потому что он не исключил пакеты, а фактически удалил их. NuGet этого не делает; если в какой-то момент вы не можете получить доступ к NuGet, что-то ужасно неправильно. Я не думаю, что хранение огромного количества зависимостей в git - хорошее решение: просто заблокируйте свои зависимости определенной версией и создайте зеркало между вами и в Интернете, если это важно для вас.
— Дэн
2
«NuGet этого не делает». Ну худилуху, вы только что пообещали, что будущее домена находится полностью вне вашего контроля. В реальном мире вещи вне вашей области контроля, ну, они вне вашей области контроля. Это касается NuGet, а также Npm. Более того, ваша идея «зеркала» - это именно то, что я предлагаю здесь, но в вашем мире «зеркало» не поддерживается какой-либо схемой управления версиями. Опять же, вы не решили поставленную задачу.
— Каспер Леон Нильсен
5

Задав вопрос, я применил следующий подход, чтобы мне не приходилось проверять каталог пакетов верхнего уровня .

В файле build.msbuild верхнего уровня:

<Target Name="NuGet">
    <ItemGroup>
       <NuGetPackage Include="*\packages.config" />
    </ItemGroup>
    <Exec Command='libs\NuGet.exe install "%(NuGetPackage.FullPath)" -o Packages'  />

    <!-- optional for project that has JavaScript content -->
    <CreateItem Include="Packages\*\Content\Scripts\*">
       <Output TaskParameter="Include" ItemName="NuGetJSFiles"/>
    </CreateItem>
    <Copy SourceFiles="@(NuGetJSFiles)" DestinationFolder="MainProj\Scripts\" OverwriteReadOnlyFiles="true" SkipUnchngedFiles="true" />
    <Delete Files="MainProj\Scripts\.gitignore" />
    <WriteLinesToFile File="MainProj\Scripts\.gitignore" Lines="%(NuGetJSFiles.Filename)%(NuGetJSFiles.Extension)" /
    <Delete Files="@(PostNuGetFiles)" />
</Target>

В каждом файле project.csproj

<Target Name="BeforeBuild">
    <Error Condition="!Exists('..\Packages\')" Text="You must run &gt; msbuild build.msbuild to download required NuGet
Packages" />

    <!-- optional for project that has JavaScript content -->
   <ReadLinesFromFile File="Scripts\.gitignore">
     <Output TaskParameter="Lines" ItemName="ReqJSFiles" />
   </ReadLinesFromFile>
   <Message Text="@(ReqJSFiles)" />
   <Error Condition="!Exists('Scripts\%(ReqJSFiles.Identity)')" Text="You must run &gt; msbuild build.msbuild to download required NuGet JS Package - Scripts\%(ReqJSFiles.Identity)" />
 </Target>
— Скотт Вайнштейн
источник
2
Это работает, но в наши дни лучше всего просто использовать встроенное восстановление пакета включения
— Скотт Вайнштейн,
4

Я понимаю, что реальность была другой, когда этот вопрос был первоначально опубликован и дан ответ, но, к счастью, ответ немного изменился. Теперь можно использовать NuGet для загрузки зависимостей через MSBuild с помощью события Pre-Build. Вам не нужно помещать папку пакетов в репозиторий кода, все зависимости будут загружены и / или обновлены при сборке. Возможно, это обходной путь, но выглядит он достаточно прилично. Подробнее см. Следующее сообщение в блоге: http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html

— Павел Краковяк
источник
4
Я был взволнован, пока не вспомнил, что для этого требуется, чтобы сервер сборки имел доступ к репозиторию NuGet, и это не единственное место, где я работал, где серверы сборки не видят Интернет. Я просто вернусь к проверке дерева пакетов в ...
— piers7
3

По состоянию на 20.09.13 есть что-то под названием «Восстановление Nuget». На самом деле вам не нужно проверять папку пакета, если вы хотите это сделать. (Особенно, если вы используете DVCS)

Проверьте это: Использование NuGet без фиксации пакетов в системе контроля версий http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages

— Мэтт В
источник
3

Этот пост сильно устарел. Ответ по-прежнему НЕТ, но решение изменилось. Начиная с NuGet 2.7+, вы можете включить автоматическое восстановление пакетов без включения файла NuGet.exe в исходный код (это, мягко говоря, нежелательно), и если вы используете любую современную DVCS, вы можете игнорировать папку пакетов. Если вам нужны какие-либо особые настройки, вы можете создать файл nuget.config в корне решения.

http://docs.nuget.org/docs/reference/package-restore

Кроме того, с новым форматом csproj вы также можете избежать лишних файлов nuget.config, поскольку они интегрированы сейчас. Пожалуйста, ознакомьтесь с этим постом, который объясняет это лучше:

Следует ли добавить папку .nuget в систему контроля версий?

— Джереми
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.