Per le domande frequenti relative a NuGet.org, ad esempio domande sull'account NuGet.org, vedere Domande frequenti su NuGet.org.
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.
Come è possibile determinare il contenuto di un pacchetto e se è stabile e utile per la mia applicazione?
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.
Qual è la procedura per ottenere la versione più recente dello strumento da riga di comando di NuGet?
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.
Quando si tenta di eseguire il cast della variabile $DTE al tipo DTE2 viene visualizzato un errore: Impossibile convertire il valore "EnvDTE.DTEClass" di tipo "EnvDTE.DTEClass" al tipo "EnvDTE80.DTE2". Qual è il problema?
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.
Sono disponibili più versioni di una libreria destinate a versioni diverse di .NET Framework. Qual è la procedura per compilare un singolo pacchetto che supporti questo scenario?
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).
Qual è la procedura per installare i pacchetti in un percorso diverso rispetto alla cartella packages predefinita?
Configurare l'impostazione repositoryPath
in Nuget.Config
con nuget config -set repositoryPath=<path>
.
Come è possibile evitare di aggiungere la cartella dei pacchetti NuGet nel controllo del codice sorgente?
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.
Perché viene visualizzato un errore "Non è possibile risolvere la dipendenza" durante l'installazione di un pacchetto locale con dipendenze remote?
È 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.
Se sono disponibili più progetti nella stessa cartella, in che modo è possibile usare file packages.config separati per ogni progetto?
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.
È stata eseguita la migrazione a PackageReference, perché la compilazione ha esito negativo "Questo progetto fa riferimento a pacchetti NuGet mancanti nel computer".
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.