Para ver as perguntas frequentes relacionadas ao NuGet.org, como perguntas a respeito da conta do NuGet.org, confira Perguntas frequentes sobre o NuGet.org.
Todas as informações sobre a interface do usuário e as ferramentas de linha de comando estão disponíveis na Guia de instalação.
A ferramenta de linha de comando, nuget.exe
, é compilada e executada normalmente no Windows. O NuGet pode ser executado em sistemas operacionais Unix usando mono
, mas não é oficialmente suportado pela Política de Suporte do NuGet.
O Mono transferiu a propriedade para o Wine e não é mais mantido pela Microsoft.
A origem primária para aprender sobre um pacote é a página de listagem em nuget.org (ou outro feed privado). Cada página do pacote em nuget.org inclui uma descrição do pacote, seu histórico de versão e as estatísticas de uso. A seção Informações na página do pacote também contém um link para o site da Web do projeto em que você normalmente encontrar muitos exemplos e documentação para ajudá-lo a aprender como o pacote é usado.
Para obter mais informações, consulte Localizando e escolhendo pacotes.
- O Visual Studio no Windows é compatível com a Interface do usuário do Gerenciador de Pacotes e o Console do Gerenciador de Pacotes.
- O Visual Studio para Mac tem recursos internos do NuGet, conforme descrito em Incluindo um pacote do NuGet em seu projeto.
- O Visual Studio Code (todas as plataformas) não tem nenhuma integração direta do NuGet. Usar a CLI do NuGet ou a CLI do dotnet.
- O Azure DevOps fornece uma etapa de build para restaurar os pacotes do NuGet. Você também pode hospedar feeds privados de pacote do NuGet no Azure DevOps.
No Visual Studio, use o comando Ajuda > Sobre o Microsoft Visual Studio e examine a versão exibida ao lado do Gerenciador de Pacotes do NuGet.
Como alternativa, inicie o Console do Gerenciador de Pacotes (Ferramentas > Gerenciador de Pacotes do NuGet > Console do Gerenciador de Pacotes) e digite $host
para ver informações sobre o NuGet, incluindo a versão.
O NuGet geralmente funciona para linguagens .NET e foi projetado para trazer bibliotecas .NET em um projeto. Como também há suporte para a automação do MSBuild e do Visual Studio em alguns tipos de projeto, também há suporte para outros projetos e idiomas em diversos níveis.
A versão mais recente do NuGet é compatível com C#, Visual Basic, F#, WiX, C++ e Q#.
O NuGet tem suporte completo para uma variedade de modelos de projeto como Windows, Web, Cloud, SharePoint, Wix e assim por diante.
Acesse a guia Atualizações na interface do usuário do Gerenciador de Pacotes e selecione Atualizar tudoou use o comando Update-Package
do Console do Gerenciador de Pacotes.
Para atualizar o próprio modelo, você precisa atualizar manualmente o repositório de modelos. Consulte o blog de Xavier Decoster sobre este assunto. Observe que isso é feito por seu próprio risco, pois atualizações manuais podem corromper o modelo se a versão mais recente de todas as dependências não forem compatível entre si.
Sim, o NuGet funciona diretamente da linha de comando. Consulte o Guia de instalação e a CLI de referência.
Consulte o Guia de instalação. Para verificar a versão atual instalada da ferramenta, use nuget help
.
Você pode redistribuir o nuget.exe sob os termos da licença do MIT. Você é responsável pela atualização e manutenção das cópias do nuget.exe que você escolhe redistribuir.
Sim, é possível adicionar comandos personalizados para nuget.exe
, conforme descrito na postagem de Rob Reynold disponível no Archive.org.
O objeto de nível superior no modelo de objeto de automação do Visual Studio é chamado o objeto DTE (Ambiente de Ferramentas de Desenvolvimento). O console fornece isso por meio de uma variável chamada $DTE
. Para obter mais informações, consulte Visão geral do modelo de automação na documentação de Extensibilidade do Visual Studio.
Tento converter a variável $DTE para o tipo DTE2, mas recebo um erro: não é possível converter o valor de “EnvDTE.DTEClass” do tipo “EnvDTE.DTEClass” para o tipo “EnvDTE80.DTE2”. Qual é o problema?
Este é um problema conhecido em como o PowerShell interage com um objeto COM. Experimente o seguinte:
`$dte2 = Get-Interface $dte ([EnvDTE80.DTE2])`
Get-Interface
é uma função auxiliar adicionada pelo host do NuGet PowerShell.
Consulte Criar e publicar um pacote.
Tenho várias versões da minha biblioteca que usam versões diferentes do .NET Framework. Como fazer para compilar um único pacote compatível com isso?
Consulte a Visão geral de hospedagem de pacotes.
Consulte Publicação de pacotes do NuGet em massa (jeffhandly.com).
Sim, consulte a postagem no blog de Scott Hanselman How to access NuGet when nuget.org is down (or you're on a plane) [Como acessar o NuGet quando o nuget.org estiver inativo (ou você estiver a bordo de um avião)] (hanselman.com).
Defina a configuração repositoryPath
em Nuget.Config
usando nuget config -set repositoryPath=<path>
.
Defina o disableSourceControlIntegration
em Nuget.Config
para true
. Essa chave funciona no nível da solução e, portanto, precisa ser adicionada ao arquivo $(Solutiondir)\.nuget\Nuget.Config
. Habilitando a restauração do pacote do Visual Studio cria esse arquivo automaticamente.
Por que recebo um “Não é possível resolver o erro de dependência” ao instalar um pacote local com dependências remotas?
Você precisa selecionar a origem Todos ao instalar um pacote local para o projeto. Isso agrega todos os feeds em vez de usar apenas um. O motivo pelo qual este erro ocorre é que os usuários de um repositório local geralmente desejam evitar instalar acidentalmente um pacote remoto devido a políticas corporativa.
Tenho vários projetos na mesma pasta, como posso usar arquivos packages.config separados para cada projeto?
Na maioria dos projetos em que projetos separados residem em pastas separadas, isso não é um problema, pois o NuGet identifica os arquivos packages.config
em cada projeto. Com o NuGet 3.3 e superior, e com vários projetos na mesma pasta, você pode inserir o nome do projeto nos nomes de arquivo packages.config
que usam o padrão packages.{project-name}.config
e o NuGet usará esse arquivo.
Isso não é um problema ao usar PackageReference, pois cada arquivo de projeto contém sua própria lista de dependências.
- Adicione
https://api.nuget.org/v3/index.json
à lista de origens ou - Exclua
%appdata%\.nuget\NuGet.Config
(Windows) ou~/.nuget/NuGet/NuGet.Config
(Mac/Linux) e deixe o NuGet recriá-lo.
Eu migrei para o PackageReference, por que minha compilação está falhando com “Este projeto faz referência a pacotes NuGet que estão ausentes neste computador.”?
Em projetos packages.config, quando um pacote com props build
ou destinos era instalado, o NuGet adicionava um destino EnsureNuGetPackageBuildImports
para verificar se o conteúdo msbuild dos pacotes foi importado antes de compilar.
Se o target
tiver sido modificado manualmente, o NuGet pode não conseguir detectar que ele precisa ser removido durante a migração.
Se o seu projeto é PackageReference
e você ainda tem esse destino no arquivo de projeto, ele deve ser seguro para remoção.