Перевірка пакетів з NuGet на контроль версій?

87

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

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

version-control  msbuild  nuget 
— Скотт Вайнштейн
джерело
2
Відповідь на це питання думки. Табір "виключити / Ні" стверджує, що, оскільки наданий набір функцій полегшує під час розробки та збірки просто витягування зі сховища пакунків (наприклад, nuget.org), це можна зробити просто під час збірки. Табір "include / Yes" стверджує, що код не будуватиметься без пакетів, якщо зовнішнє сховище стане недоступним. Прочитайте обидві сторони, перш ніж приймати рішення. Також див.: 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.03.13
11
@Edward - Філософськи, чому б вам не включити пакети NuGet до керування джерелом, враховуючи, що вони є залежностями? Те, що перевіряється в контролі джерела, повинно складати 100% коду, достатнього для збірки. Не включаючи пакети NuGet, створюються зовнішні залежності, наприклад. що робити, якщо місце завантаження пакета змінюється, або з якоїсь дивної причини воно вже недоступне і т. д. Або, що більш імовірно, якщо відбудеться незначна зміна пакета, який згодом буде повторно завантажено, і це призведе до порушення збірки? Цього можна було б уникнути, якби все необхідне для побудови проекту знаходилось під контролем джерел.
— Howiecamp
5
@Howiecamp Я не міг більше погодитися. Я не розумію логіки. Я хочу, щоб контроль над джерелами був повністю автономною системою. Особливо, якщо проект є дещо застарілим і якийсь час не доступний. Я хочу повернутися і попрацювати без змін. Nuget - це єдиний момент відмови, якого я не хочу мати.
— Телавіан
2
@Howiecamp Нашим рішенням є розміщення нашого власного nuget-сервера - і розміщення всіх nuget-пакетів, внутрішніх як зовнішніх, у GIT-LFS. Це усуває єдину точку відмови і все чудово тримає під контролем версій. Але ми все ще не реєструємося в папці пакети - і все ще використовуємо автоматичне відновлення пакунків
— Каспер Леон Нільсен
30

Так. Вважайте каталог "пакети" еквівалентним вашому каталогу "libs", який ви згадали у своєму питанні. Саме такий підхід я особисто застосовую до своїх проектів OSS.

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

Я думаю, що деякі люди, можливо, вже реалізували такі функції самостійно, але ми плануємо розглянути можливість вбудовування цієї функції в NuGet 1.2 або 1.3.

— Зламаний
джерело
10
Я точно хотів би, щоб цю функцію додали. Було б непогано мати можливість витягувати пакети за необхідності на сервер CI або dev PC, щоб уникнути здуття сховища керування джерелом сторонніми бібліотеками DLL.
— Джон Міллз
2
Якби менеджер пакетів у візуальній студії та інструмент командного рядка могли "ремонтувати пакети", це було б чудово.
— Шон Вільсон
1
Можливо, було б добре видалити / відредагувати цю відповідь зараз вона застаріла
— Lex
3
Відповідь @Tim наразі не імхо
— Едвард Уайльд,
4
Ця відповідь досі актуальна. Розгляньте пакети, яких немає в глобальному сховищі (немає можливості їх відновити / завантажити). IMHO - хороша практика зберігати пакунки в системі управління версіями.
— Павло Ходек
6

Незважаючи на всі відповіді тут, все ще є жахливим рішенням не мати всіх своїх залежностей під "якимось" контролем версій.

Для GIT це означало б GIT-LFS.

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

Ви більше не можете створювати свої речі - і, отже, не можете доставити.

— Каспер Леон Нільсен
джерело
1
Це ДУЖЕ хороший момент. Навіть якщо у нас є власний внутрішній сервер NuGet, чи можемо ми покладатися на те, що він завжди буде доступний під час збірки? Крім того, як часто змінюються наші пакети, щоб нам завжди потрібно було отримувати нову копію для кожної збірки?
— Джош П
npmзламався, оскільки не видав список із пакетів, насправді їх видалив. NuGet цього не робить; якщо в будь-який момент ви не можете отримати доступ до NuGet, щось страшенно неправильно. Я не думаю, що зберігання краптона залежностей у git є хорошим рішенням: просто зафіксуйте свої залежності до певної версії і встановіть дзеркало між вами та в Інтернеті, якщо це для вас важливо.
— Дан
2
Msgstr "NuGet цього не робить". Ну худілуху ви щойно дали обіцянки щодо майбутнього домену, який повністю виходить з-під вашого контролю. У реальному світі речі поза вашим контролем, вони поза вашим контролем. Це стосується NuGet, як і Npm. Крім того, ваша ідея "дзеркала" - саме те, що я пропоную тут, але у вашому світі "дзеркало" не підтримується жодною схемою, керованою версіями. Знову ж таки, ви не вирішили проблему, яку вирішили.
— Каспер Леон Нільсен,
5

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

У файлі 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 Restore". Насправді вам не потрібно реєструватися в папці пакунка, якщо ви хочете це зробити. (Особливо, якщо ви використовуєте 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.