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

В более новых версиях NuGet можно настроить проект для автоматического восстановления пакетов NuGet, чтобы packagesпапку не нужно было включать в репозиторий исходного кода. Хорошо.

Однако эта команда добавляет новую .nugetпапку, и там есть двоичный файл NuGet.exe. Это также может быть автоматически воссоздано Visual Studio, поэтому не кажется правильным добавлять это в систему контроля версий. Однако без этой папки Visual Studio даже не сможет правильно загрузить решение.

Как вы с этим справляетесь? Добавить .nuget в систему управления версиями? Запустить какой-нибудь сценарий командной строки перед открытием решения?

Это старый пост, вам больше не следует использовать восстановление пакета NuGet на уровне решения. Начиная с версии 2.7+, в настройке NuGet есть опция для автоматического восстановления пакетов при сборке. Таким образом, можно удалить папку .nuget и удалить эту опцию из ваших проектов.

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

ОБНОВЛЕНИЕ: с выпуском NuGet 4.x и .NET Standard 2.0, когда вы используете новый формат csproj, теперь вы можете использовать ссылки на пакеты, по иронии судьбы повторно вводя зависимость от msbuild для восстановления пакетов, но теперь пакеты являются первоклассными гражданами msbuild . В приведенной выше ссылке также упоминается PackageReference, но в следующем объявлении это более подробно описано:

https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html

И объявление NuGet 4.x RTM, которое по иронии судьбы не так полезно:

https://blog.nuget.org/20170308/Announcing-NuGet-4.0-RTM.html

ОБНОВЛЕНИЕ 2: По-видимому, с VS2017 вы даже можете использовать ссылки на пакеты с классическими проектами csproj, но они больше не имеют обратной совместимости, и возникли некоторые проблемы с восстановлением зависимостей пакетов. Я уверен, что все решится.

Ответ @Richard Szalay правильный - вам не нужно фиксировать nuget.exe. Если по каким-либо причинам Visual Studio не загружает nuget.exe автоматически, убедитесь, что в файле установлено значение truenuget.targets :

<!-- Download NuGet.exe if it does not already exist --> 
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe>

Закройте решение VS, снова откройте его и соберите. Visual Studio должна автоматически загрузить nuget.exe.

Согласно этой теме , папка .nuget должна контролироваться версиями.

Вы должны совершить .nuget\nuget.targets, но не nuget.exe. Цели загрузят исполняемый файл, если он не существует, если вы измените его DownloadNuGetExeна trueв nuget.targets.

Хотя мне обычно не нравится идея добавления exe в систему управления версиями, я бы посоветовал, чтобы система управления версиями содержала все, что требуется для открытия, сборки и выполнения проекта.

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

Единственный оставшийся вопрос, который вам нужно изучить, - это то, как NuGet будет реагировать, если эта папка помечена как доступная только для чтения, что TFS сделает после того, как она будет зарегистрирована.

Обновление: я провел немного больше исследований по этому поводу, поскольку никогда раньше не использовал NuGet. http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html

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

Кроме того, вы должны поместить в систему управления версиями командный файл, необходимый для подготовки рабочей станции к началу редактирования проекта. Пакетный файл будет запускать команды, необходимые для получения и установки пакетов зависимостей.

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

Теперь, когда nuget поддерживает восстановление пакетов, мы рассмотрим его более внимательно.

Мы используем Subversion для управления версиями, и я изначально думал, что .nugetнужно добавить в наш репозиторий, но с использованием svn: externals, чтобы он указывал на одно место.

Таким образом, мы можем автоматически отправлять новые версии всем разработчикам и проектам. Для проектов в ветвях выпуска, а не в HEAD, мы можем указать версию ссылки svn: externals, если мы хотим оставить nuget в покое.

У нас много проектов, так что это также означает, что nuget.exeв репо не нужно дублировать несколько раз.

У нас есть nuget.configфайл в папке, так как он содержит ссылки на наш внутренний сервер Nuget, используя область источников пакетов: https://docs.nuget.org/consume/nuget-config-settings

Помимо этой причины, вы должны позволить Visual Studio обрабатывать загрузку пакетов.