Часто задаваемые вопросы, относящиеся к NuGet.org, например вопросы об учетных записях NuGet.org, см. в разделе Вопросы и ответы по NuGet.org.
Все данные по пользовательскому интерфейсу и средствам командной строки доступны в руководстве по установке.
Средство командной строки, nuget.exe
сборка и запуск обычно выполняется в Windows. NuGet может работать в операционных системах Unix с помощью mono
, но официально не поддерживается политикой поддержки NuGet.
Mono перенесла владение в Wine и больше не поддерживается корпорацией Майкрософт.
Как можно определить, что содержит пакет, и является ли он стабильным и полезным для моего приложения?
Основным источником информации о пакете является его страница сведений на веб-сайте nuget.org (или в другом закрытом веб-канале). На странице каждого пакета на веб-сайте nuget.org приводится описание проекта, история его версий и статистика использования. В разделе Сведения на странице пакета также приводится ссылка на веб-сайт проекта, где обычно можно найти много примеров и других документов, с помощью которых можно оценить полезность пакета.
Дополнительные сведения см. в разделе Поиск и выбор пакетов.
- Visual Studio для Windows поддерживает пользовательский интерфейс диспетчера пакетов и консоль диспетчера пакетов.
- Visual Studio для Mac реализует встроенные возможности NuGet, которые описываются в разделе Включение пакета NuGet в проект.
- Visual Studio Code для всех платформ не поддерживает прямую интеграцию с NuGet. Используйте интерфейс командной строки NuGet или интерфейс командной строки dotnet.
- Azure DevOps реализует шаг построения для восстановления пакетов NuGet. Также вы можете разместить закрытые веб-каналы NuGet в Azure DevOps.
В Visual Studio используйте команду "Справка > о Microsoft Visual Studio" и просмотрите версию, отображаемую рядом с диспетчер пакетов NuGet.
Кроме того, запустите консоль диспетчер пакетов (инструменты > NuGet диспетчер пакетов диспетчер пакетов > консоль) и введите $host
сведения о NuGet, включая версию.
NuGet обычно работает с языками платформы .NET и предназначен для использования библиотек .NET в проекте. Поскольку для проектов некоторых типов также поддерживаются средства автоматизации MSBuild и Visual Studio, в определенной степени также поддерживаются другие проекты и языки.
Последняя версия NuGet поддерживает C#, Visual Basic, F#, WiX, C++и Q#.
NuGet обеспечивает полную поддержку множества шаблонов проектов, включая Windows, Интернет, облако, SharePoint, Wix и другие.
Перейдите на вкладку Обновления в пользовательском интерфейсе диспетчера проектов и выберите Обновить все или воспользуйтесь командой Update-Package
в консоли диспетчера проектов.
Чтобы обновить сам шаблон, необходимо вручную обновить репозиторий шаблонов. Дополнительные сведения по этой теме см. в блоге Ксавье Декостера (Xavier Decoster). Обратите внимание, что все это вы делаете на свой страх и риск, поскольку ручное обновление может привести к повреждению шаблона в том случае, если последние версии всех зависимостей несовместимы друг с другом.
Да. NuGet работает непосредственно из командной строки. См. руководство по установке и справочник по интерфейсу командной строки.
См. руководство по установке. Чтобы проверить текущую установленную версию средства, выполните команду nuget help
.
Вы можете распространить nuget.exe в соответствии с условиями лицензии MIT. Вы несете ответственность за обновление и обслуживание всех распространяемых вами копий nuget.exe.
Да, можно добавить пользовательские команды nuget.exe
в , как описано в публикации Rob Reynold, доступной через Archive.org.
Объект верхнего уровня в объектной модели автоматизации Visual Studio называется объектом DTE (среда средств разработки). Этот объект предоставляется консолью с помощью переменной $DTE
. Дополнительные сведения см. в разделе Общие сведения о модели автоматизации в документации по расширению среды Visual Studio.
При попытке привести переменную $DTE к типу DTE2 возникает ошибка: "Не удается преобразовать значение "EnvDTE.DTEClass" типа "EnvDTE.DTEClass" в тип "EnvDTE80.DTE2"". Что я делаю не так?
Это известная проблема, связанная с взаимодействием PowerShell с COM-объектом. Попробуйте сделать следующее.
`$dte2 = Get-Interface $dte ([EnvDTE80.DTE2])`
Get-Interface
— это вспомогательная функция, добавляемая узлом PowerShell NuGet.
См. раздел Создание и публикация пакетов.
У меня есть несколько версий библиотеки, предназначенных для различных версий платформы .NET Framework. Как построить единый пакет, поддерживающий такую реализацию?
См. раздел Общие сведения о размещении пакетов.
См. раздел Массовая публикация пакетов NuGet (jeffhandly.com).
Да. См. статью блога Скотта Ханселмана (Scott Hanselman), посвященную доступу к NuGet при неработающем веб-сайте nuget.org или во время полета на самолете (hanselman.com).
Задайте параметр repositoryPath
в файле Nuget.Config
, используя nuget config -set repositoryPath=<path>
.
Присвойте свойству disableSourceControlIntegration
в файле Nuget.Config
значение true
. Этот ключ работает на уровне решения и поэтому должен добавляться в файл $(Solutiondir)\.nuget\Nuget.Config
. Если включить восстановление пакета из Visual Studio, этот файл будет создан автоматически.
См. раздел Включение и отключение восстановления пакетов.
Почему при установке локального пакета с удаленными зависимостями возникает ошибка "Не удается разрешить зависимость"?
При установке локального пакета в проект выберите источник Все. При этом вместо использования одного веб-канала будут объединены все веб-каналы. Причиной этой ошибки обычно является то, что пользователи локального репозитория часто стремятся избежать случайной установки удаленного пакета из-за требований корпоративной политики.
У меня есть несколько проектов, расположенных в одной папке. Как использовать отдельные файлы packages.config для каждого проекта?
В большинстве случаев, когда отдельные проекты располагаются в отдельных папках, это не проблема, поскольку NuGet идентифицирует файлы packages.config
в каждом проекте. Если вы работаете с NuGet версии 3.3 или более поздней и размещаете несколько проектов в одной папке, вы можете вставить имя проекта в имена файлов packages.config
, используя шаблон packages.{project-name}.config
. NuGet будет использовать этот файл.
Это также не проблема при использовании PackageReference, поскольку каждый файл проекта содержит собственный список зависимостей.
- Добавьте
https://api.nuget.org/v3/index.json
в список источников или - Удалите файл
%appdata%\.nuget\NuGet.Config
(Windows) или~/.nuget/NuGet/NuGet.Config
(Mac/Linux) и дождитесь, пока NuGet снова создаст его.
Я перенесен в PackageReference, почему сбой сборки : "Этот проект ссылается на пакеты NuGet, отсутствующие на этом компьютере."
Когда в проектах packages.config устанавливался пакет с целевыми объектами или свойствами build
, NuGet добавлял целевой объект EnsureNuGetPackageBuildImports
для проверки, что содержимое msbuild пакетов было импортировано перед сборкой.
Если target
был изменен вручную, NuGet, возможно, не удается обнаружить, что при миграции его необходимо удалить.
Если ваш проект — PackageReference
, и этот целевой объект еще присутствует в файле проекта, его следует удалить.