Многопользовательская команда с использованием NuGet и Source Control

Question

Я работаю в команде из двух человек, использующей Team Foundation Server для контроля версий. Я начал новое решение. Для этого решения я создал несколько проектов. Во многих из них я использовал NuGet для установки AutoMapper и Unity. Затем я щелкнул правой кнопкой мыши по решению и выбрал «Добавить в систему управления версиями». Затем я проверил итоговые ожидающие изменения.

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

Итак, я решил, что мне нужно добавить папку пакетов. Так я и сделал.

После того, как я это сделал, ссылки на NuGet все еще не работают (для него).

Кроме того, когда я пытаюсь добавить пакет NuGet в файл, я получаю эту ошибку сейчас:

Доступ к пути 'C: \ src \ MyPath \ ToMySolution \ packages \ repositories.config' запрещен.

Я предполагаю, что это потому, что файл repositories.config теперь находится под контролем исходного кода (поэтому он доступен только для чтения, пока не извлечен вручную).

Итак, вот мои два вопроса:

1. Как или что я могу проверить, чтобы пакеты NuGet были действительны для моего коллеги, когда он получал последнюю версию?
2. Есть ли способ не проверять файлы NuGet вручную, когда мне нужно использовать NuGet?

Я делаю это неправильно? или NuGet на самом деле не предназначен для использования с Source Control?

Answer 1

Редактировать 2014/03/31: ручное восстановление пакета на основе MSBuild больше не требуется, см. Также http://xavierdecoster.com/migrate-away-from-msbuild-based-nuget-package-restore.

Редактировать 2012/02/07: теперь это встроенная функция NuGet vsix, которая называется Enable Package Restore.

Устаревшая альтернатива

Для этого есть пакет NuGet, он называется NuGetPowerTools. Он добавляет две новые команды в консоль диспетчера пакетов NuGet в Visual Studio, среди которых наиболее интересной является Enable-PackageRestore.

Будет добавлена ​​папка .nuget, содержащая nuget.exe, nuget.settings.targets и nuget.targets. Когда вы запускаете команду enable package restore, он перечисляет все проекты в вашем решении и добавляет оператор import nuget.targets в файлы проектов (которые фактически являются самими файлами msbuild).

Всякий раз, когда вы создаете проект или все решение, nuget извлекает все пакеты для этого проекта / решения, как это определено в файле packages.config. Это происходит на этапе перед сборкой.

Итак, вкратце:

1. не регистрировать пакеты
2. выполнить регистрацию в файлах конфигурации (файлы repositories.config и packages.config)
3. использовать Включить восстановление пакета
4. регистрация в папке .nuget

Всякий раз, когда кто-то получает исходные коды, будь то другой разработчик в команде или агент сборки, процессу msbuild будет дано указание выбрать все необходимые пакеты на этапе предварительной сборки.

Кроме того, когда пакеты не зафиксированы в TFS Source Control, вы не столкнетесь с проблемами только для чтения и не столкнетесь с конфликтами двоичных файлов.

Если хотите, вы также можете ознакомиться с обоснованием этого подхода в моем блоге .

Answer 2

Не проверять папку пакетов в.

Добавьте следующее событие предварительной сборки в ваш проект:

$(SolutionDir)build\nuget install $(ProjectDir)packages.config -source \\server\path\NuGetPackages -o $(SolutionDir)packages

Опустить параметр -source, если не используются пользовательские пакеты.

nuget.exe проверен в $ (SolutionDir) build \ nuget

Answer 3

У меня тоже есть эта проблема.Мне нравится идея восстановления Nuget, но я не думаю, что она мне нужна.Я хочу, чтобы мои разработчики JR могли извлекать решение и иметь все необходимое.

Поэтому я поставил папку с пакетами под контроль исходного кода.

Мое решение для включения Nuget в этих обстоятельствах заключалось вобратите внимание на это сверху:

"Я предполагаю, что это потому, что файл repositories.config теперь находится под контролем исходного кода (поэтому он доступен только для чтения, пока не извлечен вручную)."

Я открыл файл repositories.config и добавил пустую строку.Затем добавил нужные мне пакеты Nuget.Проблема решена.

Answer 4

Я всегда проверяю только папку packages.config и использую задачу rake, которую разработчик (и сервер сборки) может использовать для локального обновления пакетов.

Задание выглядит так:

def nuget_for_project(project_dir)
  sh "tools\\NuGet.exe " +
    "i Source\\#{project_dir}\\packages.config " +
    "-o Source\\Packages"
end

namespace :nuget do
  desc "nuget for servicebus"
  task "ServiceBus" do
    nuget_for_project "SampleProject.ServiceBus"
  end    

  desc "nuget for web"
  task "Web" do
    nuget_for_project "SampleProject.Web"
  end  

  desc "nuget for all"
  task "all" => ["nuget:ServiceBus", "nuget:Web"]
end

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

Вы можете написать это вместо msbuild или nant.

Я недавно написал более длинное сообщение в блоге , которое может оказаться полезным.

Answer 5

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

1. Открыл целевой файл в NP ++
2. В меню редактирования, полностью внизщелкните Clear Read-Only Flag
3. Сохранить файл
4. Прибыль

Это работает для меня с решением, на момент написания которого 39 проектов.

Answer 6

Должен дать крик этой статье: http://www.jsinh.in/2013/11/enable-nuget-package-restore/ Он точно описывает, что делать и почему.

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

Редко, но возможно.

Например, в ваш проект встроен пакет abc.package версии 2.0.2. Вы не делаете версию 'abc.package', но делаете версию packages.config. Через несколько месяцев вам нужно добавить исправление к сборке, которую вы сделали несколько месяцев назад. Вы получаете предметы из ВК. VisualStudio загружает версию 2.0.2 файла abc.package, но после последней сборки разработчик пакета вставил или исправил некоторый код. Этот новый код может работать по-разному в вашем приложении.

Итак, есть веские причины для проверки пакетов!