Domande frequenti su NuGet

Tutte le informazioni sia sull'interfaccia utente che sugli strumenti da riga di comando sono disponibili in Installazione degli strumenti client di NuGet.

Lo strumento da riga di comando, nuget.exe, compila ed esegue in genere in Windows. NuGet può essere eseguito nei sistemi operativi Unix usando mono, ma non è ufficialmente supportato dai criteri di supporto di NuGet.

Mono ha trasferito la proprietà a Wine e non è più gestita da Microsoft.

La fonte principale di informazioni su un pacchetto è la relativa pagina di presentazione in nuget.org (o un altro feed privato). Ogni pagina di pacchetto in nuget.org include una descrizione del pacchetto, la cronologia delle versioni e le statistiche di utilizzo. La sezione Info nella pagina del pacchetto contiene anche un collegamento al sito Web del progetto in cui è in genere possibile trovare numerosi esempi e documentazione per scoprire di più su come viene usato il pacchetto.

Per altre informazioni, vedere Ricerca e scelta di pacchetti.

• Visual Studio in Windows supporta l'interfaccia utente di Gestione pacchetti e la console di Gestione pacchetti.
• Visual Studio per Mac include funzionalità incorporate di NuGet come descritto in Inserimento di un pacchetto NuGet nel progetto.
• Visual Studio Code (tutte le piattaforme) non include alcuna integrazione diretta di NuGet. Usare l'interfaccia della riga di comando di NuGet o l'interfaccia della riga di comando di dotnet.
• Azure DevOps offre un passaggio di compilazione per il ripristino dei pacchetti NuGet. È anche possibile ospitare feed di pacchetti NuGet privati in Azure DevOps.

In Visual Studio usare il comando ? > informazioni su Microsoft Visual Studio e osservare la versione visualizzata accanto a NuGet Gestione pacchetti.

In alternativa, avviare la console di Gestione pacchetti (Strumenti > NuGet Gestione pacchetti > console Gestione pacchetti) e immettere $host per visualizzare le informazioni su NuGet inclusa la versione.

NuGet funziona in generale per i linguaggi .NET ed è progettato per integrare le librerie .NET in un progetto. Dato che supporta anche l'automazione di MSBuild e Visual Studio in alcuni tipi di progetto, sono supportati anche altri progetti e linguaggi a vari livelli.

La versione più recente di NuGet supporta C#, Visual Basic, F#, WiX, C++e Q#.

NuGet offre il supporto completo per un'ampia gamma di modelli di progetto come Windows, Web, Cloud, SharePoint, Wix e così via.

Passare alla scheda Aggiornamenti nell'interfaccia utente di Gestione pacchetti e selezionare Aggiorna tutto oppure usare il comando Update-Package dalla console di Gestione pacchetti.

Per aggiornare il modello stesso, è necessario aggiornare manualmente il repository del modello. Vedere il blog di Xavier Decoster su questo argomento. Si noti che questa operazione viene eseguita a proprio rischio, poiché gli aggiornamenti manuali potrebbero danneggiare il modello, se le versioni più recenti di tutte le dipendenze non sono compatibili tra loro.

Sì, NuGet funziona direttamente dalla riga di comando. Vedere la guida all'installazione e le informazioni di riferimento sull'interfaccia della riga di comando.

Vedere la guida all'installazione. Per controllare la versione installata corrente dello strumento, usare nuget help.

È possibile ridistribuire nuget.exe ai sensi della licenza MIT. L'utente è responsabile dell'aggiornamento e della manutenzione di qualsiasi copia di nuget.exe che si sceglie di ridistribuire.

Sì, è possibile aggiungere comandi personalizzati a nuget.exe, come descritto nel post di Rob Reynold disponibile tramite Archive.org.

L'oggetto di primo livello nel modello a oggetti di automazione di Visual Studio viene chiamato oggetto DTE (Development Tools Environment). La console rende disponibile questo oggetto tramite una variabile denominata $DTE. Per altre informazioni, vedere Cenni preliminari sul modello di automazione nella documentazione sull'estendibilità di Visual Studio.

Si tratta di un problema noto correlato alla modalità di interazione di PowerShell con un oggetto COM. Attenersi alla procedura seguente:

`$dte2 = Get-Interface $dte ([EnvDTE80.DTE2])`

Get-Interface è una funzione helper aggiunta dall'host di PowerShell di NuGet.

Vedere Creare e pubblicare un pacchetto.

Vedere Supporto di più versioni di .NET Framework.

Vedere la panoramica dell'hosting dei pacchetti.

Vedere Bulk publishing NuGet packages (Pubblicazione in blocco di pacchetti NuGet) (jeffhandly.com).

Sì, vedere il post di blog di Scott Hanselman How to access NuGet when nuget.org is down (or you're on a plane) (Come accedere a NuGet quando il sito nuget.org non è disponibile oppure sei in aereo) (hanselman.com).

Configurare l'impostazione repositoryPath in Nuget.Config con nuget config -set repositoryPath=<path>.

Impostare disableSourceControlIntegration in Nuget.Config su true. Questa chiave funziona a livello di soluzione e quindi deve essere aggiunta al file $(Solutiondir)\.nuget\Nuget.Config. Quando si abilita il ripristino dei pacchetti da Visual Studio, questo file viene creato automaticamente.

Vedere Abilitazione e disabilitazione del ripristino dei pacchetti.

È necessario selezionare l'origine Tutti quando si installa un pacchetto locale nel progetto. In questo modo vengono aggregati tutti i feed anziché usarne solo uno. Il motivo per cui viene visualizzato questo errore è che gli utenti di un repository locale spesso vogliono evitare l'installazione accidentale di un pacchetto remoto a causa di criteri aziendali.

Nella maggior parte dei progetti in cui progetti separati risiedono in cartelle separate, questo non costituisce un problema perché NuGet identifica i file packages.config in ogni progetto. Con NuGet 3.3 + e più progetti nella stessa cartella, è possibile inserire il nome del progetto nei nomi di file packages.config usando il modello packages.{project-name}.config, e NuGet usa tale file.

Questo non è un problema quando si usa PackageReference, perché ogni file di progetto contiene il proprio elenco di dipendenze.

• Aggiungere https://api.nuget.org/v3/index.json all'elenco di origini, o
• Eliminare %appdata%\.nuget\NuGet.Config (Windows) o ~/.nuget/NuGet/NuGet.Config (Mac/Linux) e consentire a NuGet di ricrearlo.

Nei progetti packages.config, quando è stato installato un pacchetto con build proprietà o destinazioni, NuGet aggiunge una EnsureNuGetPackageBuildImports destinazione per verificare che il contenuto msbuild dei pacchetti sia stato importato prima della compilazione. Se è target stato modificato manualmente, NuGet potrebbe non essere in grado di rilevare che è necessario rimuoverlo durante la migrazione.

Se il progetto è PackageReference e si dispone ancora di questa destinazione nel file di progetto, dovrebbe essere sicuro da rimuovere.