Nuget package explorer как пользоваться
Обновлено: 08.07.2024
Вне области: пакеты для использования в нативных (c / c ++) проектах
Самый полезный комментарий
папка на время выполнения? Какая структура?
Требуется ли это дублирование и с какой целью, если оно для обратной совместимости, знаете ли вы, где мы могли бы найти "старую" версию с проблемой?
Несколько недель назад кто-то из сотрудников связался со мной по поводу создания пакетов с управляемыми и собственными dll. Я попытался объяснить им это, и они дали мне обратную связь, что это им очень помогло:
С PackageReference NuGet выбирает сборки времени компиляции и времени выполнения независимо:
- сборки во время компиляции выбираются из ref/ , но если ни одно не соответствует, возвращается к lib/ .
- сборки среды выполнения выбираются из runtimes/ , но если ни один не соответствует, возвращается к lib/ .
- Следовательно, для проекта PackageReference, если пакет содержит lib/ , ref/ и runtimes/ , все с активами для той же целевой платформы, тогда папка lib/ игнорируется, он также может не существовать.
- используются только ресурсы lib/ , как для времени компиляции, так и для времени выполнения
- Все остальное (ресурсы среды выполнения на идентификатор среды выполнения) должно быть выполнено автором пакета через реквизиты / цели msbuild в папке build/<tfm>/ пакета.
- Обратите внимание, что PackageReference импортирует build/<tfm>/<packageid>.props&targets только в том случае, если для пакета в проекте есть PackageReference . Пакеты включают в качестве зависимостей (переходные пакеты) только импорт buildTransitive/<tfm>/<packageid>.props&targets . Распространенный шаблон, который я видел, - это наличие файлов props / target в папках buildTransitive/. которые не делают ничего, кроме импорта файла props / target в build/. , что позволяет избежать дублирования содержимого в пакакге, Если вам важен размер упаковки.
как нам отключить "вывод сборки" csproj, чтобы мы могли просто запустить dotnet pack на csproj, который содержит только
Есть два, которые кажутся интересными. IncludeBuildOutput делает то, о чем вы спрашиваете, он указывает NuGet неявно копировать выходную сборку проекта в пакет.
Под управлением подразумевается поиск, скачивание, установка, настройка, обновление и удаление файлов сторонних разработчиков у себя в приложении.
Технически NuGet Manager представляет собой расширение для Visual Studio, доступное программисту в процессе работы над своим проектом. Если вы используете «студию» версии 2012 и выше, то NuGet уже заранее предустановлен и готов к работе. В случае версии 2010 его нужно установить вручную. Его можно скачать либо с официального сайта, либо установить напрямую из Visual Studio через менеджер дополнений.
Давайте откроем менеджер. Для этого в Solution Explorer щелкаем правой кнопкой мыши по рабочему проекту и в контекстном меню выбираем пункт «Manage NuGet Packages…»:
NuGet Manager открывается в новой вкладке в текстовом редакторе. Интерфейс у него довольно простой.
Три главные вкладки:
- Browse. Найти и установить нужные нам пакеты из хранилища NuGet
- Installed. Список уже установленных в нашем проекте библиотек
- Updates. Библиотеки в нашем проекте, которые можно обновить до новой версии
Также в интерфейсе менеджера представлены:
- Строка поиска. Мы можем искать нужную нам библиотеку, начав вводить ее название
- Кнопка «Обновить состояние окна»
- Галочка «Включать в выдачу предрелизные версии библиотек», например, какие-то тестовые или экспериментальные
- Выпадающий список Package source. В каком месте менеджер будет искать нужные нам библиотеки
- Кнопка «Настройки менеджера»
- Главная панель с результатами выдачи (слева)
- Панель с описанием того компонента, который мы выбрали (справа)
Попробуем установить какую-нибудь библиотеку к нам в проект, например, Entity Framework. Для этого переходим во вкладку Browse и в строке поиска начинаем вводить название нужного пакета. Далее выбираем его из списка и нажимаем кнопку Install. При необходимости можно выбрать определенную версию, отличную от стабильной последней, а также ознакомиться с информацией о данном пакете (авторы, лицензия и т.д.).
В зависимости от устанавливаемого пакета NuGet Manager также определит все его зависимости, или, другими словами, все дополнительные библиотеки, которые требуются устанавливаемому пакету для полноценной работы. В случае с Entity Framework таких зависимостей нет.
Теперь давайте более детально посмотрим, что конкретно сделал менеджер при установке этого компонента в наш проект:
1. Он определил, что для данного пакета нет никаких сторонних зависимостей. Если бы они были, то менеджер автоматически их определил и подтянул.
2. NuGet Manager добавил ссылку на установленный компонент в наш проект (References):
3. NuGet разместил скачанные файлы в специальной папке Packages, которая находится в корневой папке нашего приложения. Это очень удобно, ссылки в проекте теперь идут на эту папку:
4. В конфигурационный файл packages.config была добавлена запись о новом пакете:
5. В конфигурационный файл приложения web.config также были внесены необходимые изменения, чтобы подготовить компонент Entity Framework к работе:
Вот такие операции происходят, когда NuGet Manager добавляет новую библиотеку к нам в проект.
Подобным образом происходит и обновление, и удаление компонентов из нашего проекта. В случае удаления менеджер также автоматически вносит изменения в файлы нашего проекта – убирает записи из файла packages.config, удаляет соответствующие файлы в папке packages, убирает ссылки на эти библиотеки.
Давайте рассмотрим еще несколько моментов.
С NuGet Manager можно работать не только через графический интерфейс, но и через командную строку (консоль). Чтобы ее открыть, идем Tools -> NuGet Package Manager -> Package Manager Console.
Работа в консоли ничем не отличается от работы в графическом интерфейсе, это дело вкуса.
Управление осуществляется посредством специальных команд. Чтобы вывести в консоль список всех доступных команд нужно написать инструкцию:
Команд достаточно много, и описание каждой можно найти в официальной документации на сайте. Вот пример использования наиболее популярных команд.
Добавляем пакет Entity Framework в текущий проект:
Обновляем ранее установленный пакет:
Переустанавливаем ВСЕ пакеты во всех проектах в данном решении:
Подведем краткий итог. NuGet – это просто незаменимый инструмент для разработчика на сегодняшний день. Он автоматизирует весь процесс работы с пакетами в проекте, а именно поиск, скачивание, установка, настройка, обновление и удаление файлов.
В видео версии этого урока более подробно и наглядно показана работа с этим инструментом.
Я использую NuGet для извлечения пакетов из внешних и внутренних источников пакетов, что очень удобно. Но я понял, что пакеты по умолчанию хранятся для каждого решения, что очень расстраивает, когда некоторые проекты со ссылками NuGet включены в несколько решений. Затем ссылки изменяются на другую папку пакета решений, которая может быть недоступна другому разработчику или машине сборки.
Я видел, что есть способы укажите общее расположение пакета (возможно, на корневом уровне проекта, мы используем TFS source control) с выпуском 2.1 NuGet, см. заметки . Я с помощью NuGet версии v2.7
но я попытался добавить nuget.конфигурационные файлы, не видя никакого эффекта от этого. Пакеты хранятся в папке решения. Я что-то пропустил? Кажется, что существуют различные структуры xml-узла для добавления в nuget.конфигурационный файл, в зависимости от того, кто отвечает вопрос: Schwarzie предлагает на еще один поток Stackoverflow:
примечания к выпуску NuGet 2.1 (см. ссылку выше) предлагают следующий формат:
Я не знаю, какой из них, или любой, или оба будут работать в конце. Я пробовал оба на уровне решения. Может nuget.файл конфигурации должен быть размещен на корневом уровне проекта TFS или должен быть в каталоге решения? Кажется, что NuGet читает и применяет настройки из этих файлов в определенном по порядку, почему бы не добавить их в несколько уровней, где нугет.файл конфигурации на уровне решения переопределит файл на корневом уровне проекта TFS. Можно ли это уточнить?
мне нужно удалить все установленные пакеты, прежде чем эти ссылки будут работать? Я хотел бы, чтобы кто-то мог предоставить пошаговую инструкцию для перехода от использования nuget для конкретного решения к общей папке пакета, где проекты, принадлежащие нескольким решениям, могут найти необходимый nuget пакеты.
у меня аналогичная ситуация с внешними и внутренними источниками пакетов с проектами, на которые ссылаются более чем в одном решении. Я только что получил эту работу с одной из наших баз кода сегодня, и, похоже, работает с рабочими станциями разработчика и нашим сервером сборки. Ниже процесс имеет этот сценарий в виду (хотя это не должно быть трудно адаптироваться, чтобы иметь общую папку пакетов еще где).
- кода
-
На
- Решение 1
- решение 2
- решение 3
- пакеты (это общий для всех решений)
обновленный ответ от NuGet 3.5.0.1484 с обновлением Visual Studio 2015 3
этот процесс теперь немного проще, чем когда я изначально занимался этим и думал, что пришло время обновить это. В в общем, процесс тот же, только с меньшим количеством шагов. Результатом является процесс, который решает или обеспечивает следующее:
- все, что необходимо передать в управление исходным кодом, отображается и отслеживается в решении
- установка новых пакетов или обновление пакетов с помощью диспетчера пакетов в Visual Studio будет использовать правильный путь к репозиторию
- после первоначальной настройки, никакого взлома .файлы csproj
- нет модификации рабочей станции разработчика (код готов к сборке при выезде)
есть некоторые потенциальные недостатки, о которых нужно знать (я еще не испытал их, YMMV). См.Бенол это ответ и комментарии ниже.
Добавить NuGet.Config
вы захотите создать NuGet.Файл конфигурации в корне папки \Solutions\. Убедитесь, что это файл в кодировке UTF-8, который вы создаете, если вы не знаете, как это сделать, используйте Visual Studio Меню Файл - >Создать - >файл, а затем выберите шаблон XML-файла. Добавить в NuGet.Настройте следующее:
для параметра repositoryPath можно указать абсолютный или относительный путь (рекомендуется) с помощью $ token. Токен $ основан на том, где находится NuGet.Config находится (токен $ фактически относительно на один уровень ниже расположение NuGet.Конфигурация.) Итак, если у меня есть \Solutions\NuGet.Config и я хочу \Solutions\Packages мне нужно будет указать $\..\Packages как значение.
Далее, вы хотите добавить папку решения к вам решение под названием Что-то вроде "NuGet" (щелкните правой кнопкой мыши на своем решении, добавить->Новая папка решения). Папки решений-это виртуальные папки, которые существуют только в решении Visual Studio и не создают фактическую папку на диске (и вы можете ссылаться на файлы из любого места). Щелкните правой кнопкой мыши на папке решения" NuGet", а затем добавьте - >существующий элемент и выберите \\NuGet Для Решения.Конфиг.
причина, по которой мы это делаем, заключается в том, что он виден в решении и должен помочь убедиться, что он правильно привязан к вашему элементу управления исходным кодом. Этот шаг может потребоваться для каждого решения в вашей кодовой базе, участвующей в общих проектах.
путем размещения NuGet.Конфигурационный файл в \Solutions\ над любым .sln-файлы, мы используем тот факт, что NuGet будет рекурсивно перемещаться по структуре папок вверх от "текущего рабочего каталога", ищущего NuGet.Файл конфигурации для использования. "Текущий рабочий каталог" означает здесь несколько разных вещей, одна из которых-путь выполнения NuGet.exe, а другой-расположение .sln файл.
переключение папки пакетов
во-первых, я настоятельно рекомендую вам просмотреть каждую папку решения и удалить все существующие \Packages\ folders (сначала вам нужно закрыть Visual Studio). Это облегчает задачу чтобы увидеть, где NuGet помещает вашу недавно настроенную папку \Packages\ и гарантирует, что любые ссылки на неправильную папку \Packages\ завершатся ошибкой и могут быть исправлены.
откройте решение в Visual Studio и начните перестраивать все. Игнорируйте все ошибки сборки, которые вы получите, это ожидается на данный момент. Однако это должно запустить функцию восстановления пакета NuGet в начале процесса сборки. Убедитесь, что папка \Solutions\Packages\ создана в указанном месте хотеть. Если нет, проверьте конфигурацию.
теперь для каждого проекта в вашем решении вы захотите:
- щелкните правой кнопкой мыши проект и выберите выгрузить проект
- щелкните правой кнопкой мыши проект и выберите Редактировать-xxx.csproj
- найдите любые ссылки на \packages\ и обновите их до нового местоположения.
- большинство из них будут ссылками , но не все из них. Например, WebGrease и Microsoft.Bcl.Сборка будет иметь отдельные параметры пути, которые необходимо будет обновить.
- сохранить .csproj файл и щелкните правой кнопкой мыши на проекте и выберите перезагрузить проект
однажды все ваши .csproj файлы были обновлены, начать другую перестроить все, и вы не должны иметь больше ошибок сборки о недостающих ссылках. На этом этапе вы закончили, и теперь NuGet настроен на использование папки общих пакетов.
по состоянию на NuGet 2.7.1 (2.7.40906.75) с VStudio 2012
во-первых, нужно иметь в виду, что nuget.config не контролирует все параметры пути в системе пакетов nuget. Это было особенно сложно понять. В частности, проблема заключается в том, что msbuild и Visual Studio (вызов msbuild) не используют путь в nuget.config, а скорее переопределяют его в nuget.целевой файл.
Подготовка Среды
во-первых, я бы прошел через ваш папка решения и удалите все\ packages \ папки, которые существуют. Это поможет убедиться, что все пакеты явно устанавливаются в правильную папку и обнаруживают ссылки на неверные пути во всех решениях. Затем я бы удостоверился, что у вас установлено последнее расширение NuGet Visual Studio. Я бы также убедился, что у вас есть последний nuget.exe устанавливается в каждое решение. Откройте командную строку и перейдите на каждые $(SolutionDir)\ .NuGet\ folder и выполните следующие действия команда:
установка общего пути к папке пакета для NuGet
откройте каждый $(SolutionDir)\ .из NuGet\NuGet для.Настройте и добавьте следующее внутри раздела :
Примечание: вы можете использовать абсолютный или относительный путь. Имейте в виду, если вы используете относительный путь с $, что по отношению к на один уровень ниже расположение NuGet.Config (считаю, что это жук.)
установка общего пути к папке пакета для MSBuild и Visual Studio
откройте каждый $(SolutionDir)\ .из NuGet\NuGet для.цели и измените следующий раздел (обратите внимание, что для не-Windows есть еще один раздел ниже):
Примечание: GetFullPath разрешит наш относительный путь в абсолютный путь.
восстановление всех пакетов nuget в общую папку
Откройте командную строку и получите каждый $(SolutionDir)\ .NuGet и выполните следующую команду:
на данный момент у вас должна быть одна папка \packages\ в вашем общем местоположении и ни в одной из ваших папок решения. Если нет, проверьте свои пути.
исправление ссылок на проекты
открыть каждый .файл csproj в текстовом редакторе и найдите любые ссылки на \packages и обновите их до правильного пути. Большинство из них будут ссылками , но не все из них. Например, WebGrease и Microsoft.Bcl.Сборка будет иметь отдельные параметры пути, которые необходимо будет обновить.
построить решение
откройте решение в Visual Studio и начать строить. Если он жалуется на отсутствующие пакеты, которые необходимо восстановить, не предполагайте, что пакет отсутствует и должен быть восстановлен (ошибка может вводить в заблуждение). Это может быть плохой путь в одном из ваших .csproj файл файлы. Проверьте это перед восстановлением пакета.
есть ошибка сборки о недостающих пакетах?
если вы уже проверили, что пути в вашем .файлы csproj верны, то у вас есть два варианта, чтобы попробовать. Если это результат обновления кода из системы управления исходным кодом, вы можете попробовать проверить чистую копию, а затем создать ее. Это сработало для одного из наших разработчиков, и я думаю, что в нем был артефакт .СУО файл или что-то подобное. Этот другой вариант-вручную принудительно восстановить пакет с помощью командной строки .папка nuget рассматриваемого решения:
вместо установки общего местоположения пакета для всех проектов также можно изменить HintPath в project следующим образом:
в большинстве случаев в общем проекте будет всего несколько пакетов, поэтому вы можете легко его изменить.
Я думаю, что это лучшее решение, когда вы разветвляете код, при установке общего РЕПО вы должны изменить относительный путь, в этом решении вам не нужно это делать.
мой опыт пытается это сделать с последней версией NuGet (2.7) и VS2012:
- удалить .папка nuget (на диске и в решении)
- положите NuGet.Конфигурационный файл в общей родительской папке всех решений
- удалить все существующие папки пакеты
- пройдите через все файлы csproj и измените HintPaths, чтобы указать на новое местоположение
- прибыль
в моем случае я хотел поместить все пакеты в .packages , Итак, мой NuGet.Конфигурация выглядела как ниже.
обратите внимание, что есть несколько "странных" вещей, которые могут произойти, но я думаю, что они терпимы:
- если вы "обновите" пакет из одного решения, он быстро удалит старую версию из папки "пакеты" (он не может знать, есть ли у вас другое решение, которое указывает туда). Это меня не сильно беспокоит, так как другое решение будет просто восстанавливаться при необходимости.
- если вы пытаетесь добавить пакет из правой кнопки мыши на решении, если пакет уже присутствует в другом решении, он увидит, что он есть, и покажет вам "зеленую галочку" вместо кнопки "Установить". Обычно я устанавливаю из правой кнопки мыши по проекту, поэтому это меня совсем не беспокоит.
отказ от ответственности: я только что попробовал это сегодня, у меня нет долгосрочного опыта, чтобы поддержать его!
у меня есть версия NuGet 2.8.50926 с VS 2013. Вам не нужно использовать несколько nuget.конфигурационные файлы, или использовать сложные структуры каталогов. Просто измените файл по умолчанию находится здесь:
вот содержимое моего файла:
поэтому все пакеты идут в "C:\Projects\nugetpackages-папка, где бы ни было решение.
во всех ваших решениях просто удалите существующие папки "пакеты". Затем создайте свое решение, и NuGet будет автоматическое восстановление отсутствующих пакетов в указанном вами новом централизованном каталоге.
я состряпал пакет NuGet, который прозрачно преобразует все ссылки NuGet в проекте в относительный формат $(SolutionDir). Он делает это с помощью преобразования XSLT во время сборки, поэтому вам не нужно вручную взломать файл проекта. Вы можете свободно обновлять свои пакеты, это ничего не сломает.
обновление моего опыта работы с nuget 2.8.3. Все было относительно просто. Все сделал включено восстановление пакета от щелчка правой кнопкой мыши решение. Редактировать С Помощью NuGet.Config и добавил Эти строки :
затем перестроил решение, загрузил все пакеты в нужную папку и автоматически обновил ссылки. Я сделал то же самое для всех моих других проектов, где загружались только инкрементные пакеты и ссылались на существующие пакеты. Отсюда общий репозиторий для всех проектов, как было установлено.
Вот пошаговая процедура для включения восстановления пакета.
из Visual Studio 2013 Update 4 и версии диспетчера пакетов Nugget > 2.8.5.
создать nuget.файл config в корне репозитория.
это приведет к тому, что все пакеты перейдут в папку packages на уровне вашего nuget.конфигурационный файл.
теперь вы можете пойти для каждого .консоль sln nuget с командой "update-package-reinstall"
Если у вас есть несколько репозиториев на одном уровне и что поделитесь одной и той же папкой пакета через них попробуйте использовать способ перехода на одну папку вверх.
но таким образом вы вызываете, что ссылка на пакеты nuget csproj указывает одну папку вне пути репозитория.
просто hardlink / packages в нужное общее местоположение. Тогда ваш проект не будет разбит для других пользователей, у которых нет специального расположения пакетов.
Откройте командную строку как admin и используйте
для любого значимого решения вышеуказанные ответы не подойдут. Проще говоря, сложная структура рабочего пространства TFS с различными относительными путями, ветвлением, общими проектами и т. д. сделать единое центральное хранилище невозможным.
использование ($SolutionDir) является шагом в правильном направлении, но ручное кодирование файла csproj с помощью ($SolutionDir) станет довольно утомительным в базе кода с сотнями пакетов, которые регулярно обновляются (каждый раз, когда происходит обновление, HintPath получает перезаписано новым относительным путем). Что произойдет, если вам нужно запустить Update-Package-Reinstall.
есть отличное решение под названием NugetReferenceHintPathRewrite. Он автоматизирует инъекцию ($SolutionDir) в HintPaths непосредственно перед сборкой (без фактического изменения файла csproj). Я предполагаю, что он может быть легко включен в автоматизированные системы сборки
краткое резюме для тех, кто на VS 2013 professional С NuGet для версия: 2.8.60318.667
Это то, как вы направили бы пакеты на путь относительно .папка nuget:
например, если решение (.sln-файл) находится в C:\Projects\MySolution, когда вы включаете восстановление пакета NuGet,.папка nuget создается следующим образом: C:\Projects\MySolution - . NuGet и пакеты будут загружены в каталог вот так: C:\Projects\MySolution\Dependencies
Примечание: по какой-то (неизвестной) причине каждый раз, когда я обновляю "repositoryPath", я должен закрыть и снова открыть решение, чтобы изменения вступили в силу
для тех, кто использует пакет в качестве менеджера пакетов, есть опция автоматической символической ссылки для вашего файла зависимостей:
btw: пакет использует nuget
Если вы хотите изменить как можно меньше, вы можете просто периодически очищать подкаталоги с помощью скрипта. то есть. Поведение Nuget по умолчанию-копирование файлов из глобального местоположения в локальные пакеты папка, поэтому удалите эти файлы позже.
нет необходимости редактировать файлы уровня решения.
работает с Visual Studio 2013 и тремя проектами совместного использования решений.
У меня есть решение с несколькими проектами. Большинство сторонних ссылок отсутствует, но для каждого проекта есть файл packages.config . Как заставить NuGet установить / обновить все необходимые пакеты? Нужно ли это делать с помощью командной строки для каждого проекта?
Вы можете использовать nuget.exe для восстановления своих пакетов или с установленным NuGet 2.7 или выше, вы можете просто скомпилировать ваше решение в Visual Studio, которое также восстановит недостающие пакеты.
Для NuGet.exe вы можете выполнить следующую команду для каждого проекта.
Оба они снимут пакеты. Однако файлы вашего проекта не будут изменены при запуске этой команды, поэтому в проекте уже должна быть ссылка на пакеты NuGet. Если это не так, вы можете использовать Visual Studio для установки пакетов.
При использовании NuGet 2.7 и более поздних версий Visual Studio автоматически восстанавливает отсутствующие пакеты NuGet при построении решения, поэтому использование NuGet.exe не требуется.
Чтобы обновить все пакеты в вашем решении, сначала восстановите их, а затем вы можете либо использовать NuGet.exe для обновления пакетов, либо из Visual Studio вы можете обновить пакеты из окна консоли диспетчера пакетов, или, наконец, вы можете использовать управление Диалог пакетов.
Обратите внимание, что при этом не будут запускаться сценарии PowerShell в каких-либо пакетах NuGet.
Вы также можете ограничить это одним проектом.
Если вы хотите переустановить пакеты до тех же версий, которые были установлены ранее, вы можете использовать аргумент -reinstall с командой Update-Package .
Вы также можете ограничить это одним проектом.
Параметр -reinstall сначала удалит, а затем снова установит пакет в проект.
Или вы можете обновить пакеты с помощью диалогового окна Manage Packages .
Обновления:
- 2013/07/10 - обновлена информация о восстановлении nuget в NuGet 2.7.
- 2014/07/06 - обновлена информация об автоматическом восстановлении пакетов в Visual Studio и обновлен ответ с другими изменениями в NuGet.
- 2014/11/21 - Обновлено с информацией о -reinstall
В Visual Studio 2017 - при компиляции с использованием IDE - все недостающие пакеты nuget будут загружены и сохранены в папке «пакеты».
Но на сборочной машине компиляция производилась с помощью msbuild.exe. В этом случае я скачал nuget.exe.
Во время каждого процесса сборки перед запуском msbuild.exe. Он выполнит -> nuget.exe восстановит NAME_OF_SLN_File (если есть только один файл .SLN, вы можете игнорировать этот параметр).
Не знаю, с каких пор, но в VS2019 это можно сделать проще:
- решение, щелкнув правой кнопкой мыши в обозревателе решений
- выберите Управление пакетами Nuget для решения
- есть 4 вкладки: Обзор, Установлено, Обновления, Объединить.
- Consolidate показывает, есть ли какие-либо проекты, использующие разные версии пакетов (и в большинстве случаев именно поэтому мы хотим обновить все пакеты)
- Обновления показывают, есть ли какие-либо обновления в ЛЮБЫХ проектах. Выберите все и нажмите «Обновить», работа будет выполнена.
Я знаю, что это старый пост, но подумал, что это может быть полезно. Если вам необходимо игнорировать определенные пакеты во время процесса обновления (например, любые пакеты, которые обновляют ссылки JavaScript), используйте следующий сценарий PowerShell (убедитесь, что для источника вашего пакета установлено значение «Все» в консоли диспетчера пакетов):
РЕДАКТИРОВАТЬ 2014-09-25 10:55 AM EST - Исправлена ошибка в скрипте.
В VS2012 V11, если я использую «-Reinstall» в конце строки, это не сработает.
Поэтому я просто использовал:
Теперь консоль диспетчера пакетов Nuget в Visual Studio 2012 автоматически дает вам кнопку «Восстановить», как только обнаруживает, что какой-либо пакет не установлен, но находится в package.config. Отличная особенность!
Я пробовал Update-Package -reinstall , но он не работал с пакетом и остановил обработку всех оставшихся пакетов проектов в моем решении.
Я закончил свой сценарий, который перечисляет все файлы package.config и запускает Update-Package -Reinstall -ProjectName prj -Id pkg для каждого проекта / пакета.
Надеюсь, это может быть полезно для кого-то:
Изменить: Это ошибка, которая у меня была: Update-Package: не удалось найти пакет EntityFramework.BulkInsert-ef6. Перед установкой или обновлением необходимо восстановить существующие пакеты. Ручной запуск Update-Package -Reinstall -ProjectName my_prj -Id EntityFramework.BulkInsert-ef6 работал очень хорошо.
Для тех, кто прибыл сюда из-за того, что сервер сборки не справился с этим, вы можете создать цель MSBuild, запустив команду exec для запуска команды nuget restore , как показано ниже (в этом случае nuget.exe находится в .nuget, а не по пути), который затем можно запустить на этапе сборки TeamCity непосредственно перед сборкой решения.
Я считаю, что первое, что вам нужно сделать, это включить функцию восстановления пакета. См. Также здесь. Это делается на уровне решения (а не проекта).
Но это не поможет вам полностью - я столкнулся с аналогичной проблемой после включения функции восстановления. (VS2013, NuGet 2.8.)
Оказалось, что я (непреднамеренно) передал пакеты в систему управления версиями, когда зафиксировал проект - но Visual Studio (и плагин системы управления версиями) услужливо проигнорировали двоичные файлы при выполнении возврата.
Проблема возникла, когда я создал ветку релиза. В моей локальной копии ветки dev / main / trunk были двоичные файлы, потому что я изначально установил / загрузил пакеты.
Однако в новой ветке выпуска
- все папки пакета и файлы .nupkg были там, поэтому NuGet не думал, что нужно что-то восстанавливать;
- но в то же время ни одна из DLL не присутствовала, т.е. отсутствовали сторонние ссылки, поэтому я не мог собрать.
Я удалил все папки пакетов в $(SolutionDir)/packages (в ветке выпуска), а затем выполнил полную перестройку, и на этот раз сборка прошла успешно.
. а затем, конечно, я вернулся и удалил папки пакетов из системы управления версиями (в ветке ствола и выпуска). Я (пока) не знаю, следует ли удалять и файл repositories.config .
Многие из компонентов, устанавливаемых для вас шаблонами проектов - по крайней мере, для веб-проектов - являются пакетами NuGet. То есть эта проблема не ограничивается добавленными вами пакетами.
Поэтому включите восстановление пакета сразу после создания проекта / решения и перед выполнением начальной регистрации очистите папку packages (и убедитесь, что вы зафиксировали папку .nuget в системе управления версиями).
Отказ от ответственности: я видел здесь еще один ответ на SO, который указывал, что очистка папки packages была частью решения. Это поставило меня на правильный путь, поэтому я хотел бы отдать должное автору, но я больше не могу найти этот вопрос / ответ. Я опубликую правку, если наткнусь на нее.
Также отмечу, что Update-Package -reinstall изменит файлы .sln и .csproj / .vbproj . По крайней мере, так было в моем случае. Что ИМХО делает этот вариант менее привлекательным.
После 3 часов поиска и расследования.
У меня были проблемы с этим, потому что у нас есть два члена в команде (с использованием системы управления версиями GitHub), потому что мы не ограничивали файлы для пакетов для отправки в удаленный репозиторий, один из членов команды отправлял пакеты на сервер, и я получил эти изменения в мой местный.
После этого у меня возникла та же проблема, что и у PO, также я не смог опубликовать свой проект API на сервере.
В и я только что использовал
Update-Package -Reinstall - запустите эту команду в консоли диспетчера пакетов.
Эта команда переустановит все ваши пакеты, которые вы использовали в своем решении. (Для каждого проекта)
Переустановите все пакеты во ВСЕХ ПРОЕКТАХ текущего решения:
Update-Package -ProjectName 'NameOfProject' -Reinstall - запустите эту команду в консоли диспетчера пакетов.
Эта команда переустановит все ваши пакеты, связанные с проектом, который вы указали после «-ProjectName». И я думаю, что это лучше, потому что мне пришлось ждать полчаса, чтобы переустановить все пакеты в решении.
За это большое спасибо Родольфо Броку.
Кроме того, я бы порекомендовал вам, когда вы получаете изменения с удаленного сервера, нажимать кнопку «Восстановить пакеты», которая будет отображаться Visual Studio.
Если вы устанавливаете Nuget 2.8, установите флажок
В Visual Studio. Если он отмечен, то просто перестройте проект, чтобы восстановить все ваши справочные библиотеки.
Читайте также:
- Уведомление о включении компьютера
- Не удается найти исполняемый файл компилятора в настроенном пути поиска для компилятора gnu gcc
- Закручивается провод от наушников для компьютера что делать
- Касперский добавить сертификат в доверенные
- Кроссворд на тему компьютерные сети как средство массовой коммуникации