Häufig gestellte Fragen in Bezug auf NuGet.org, z. B. Fragen zum NuGet.org-Konto, finden Sie unter Häufig gestellte Fragen zu NuGet.org.
Sämtliche Informationen zur Benutzeroberfläche und zu den Befehlszeilentools sind im Installationshandbuch verfügbar.
Das Befehlszeilentool, nuget.exe
erstellt und wird in der Regel unter Windows ausgeführt. NuGet kann auf Unix-Betriebssystemen unter Verwendung mono
ausgeführt werden, wird aber nicht offiziell von der NuGet-Supportrichtlinie unterstützt.
Mono hat das Eigentum an Wine übertragen und wird nicht mehr von Microsoft verwaltet.
Wie kann bestimmt werden, was in einem Paket enthalten ist und ob die Inhalte stabil und nützlich für meine Anwendung sind?
Die Primärquelle für Informationen zu einem Paket ist dessen Angebotsseite auf nuget.org (oder einem anderen privaten Feed). Jede Seite für ein Paket auf nuget.org enthält eine Beschreibung des Pakets, den Versionsverlauf und Nutzungsstatistiken. Der Abschnitt Info auf der Seite des Pakets enthält ebenfalls einen Link zur Website des Projekts, auf der Sie in der Regel zahlreiche Beispiele und weitere Dokumentationen finden, die Sie beim Verwenden des Pakets unterstützen.
Weitere Informationen finden Sie unter Finding and choosing packages (Suchen und Auswählen von Paketen).
- Visual Studio unter Windows unterstützt die Benutzeroberfläche des Paket-Managers und die Konsole des Paket-Managers.
- Visual Studio für Mac verfügt wie unter Including a NuGet package in your project (Einschließen eines NuGet-Pakets in Ihr Projekt) beschrieben über integrierte NuGet-Funktionen.
- Visual Studio Code (alle Plattformen) verfügt nicht über eine direkte NuGet-Integration. Verwenden Sie die NuGet-CLI oder die dotnet-CLI.
- Azure DevOps stellt einen Buildschritt für das Wiederherstellen von NuGet-Paketen bereit. Sie können auch private NuGet-Paketfeeds auf Azure DevOps hosten.
Verwenden Sie in Visual Studio den Befehl Hilfe > Info Microsoft Visual Studio und achten Sie auf die Version, die neben dem NuGet-Paket-Manager angezeigt wird.
Führen Sie alternativ die Konsole des Paket-Managers (Tools > NuGet-Paket-Manager > Paket-Manager-Konsole) aus, und geben Sie $host
ein, um Informationen über NuGet anzuzeigen, die ebenfalls die Version enthalten.
NuGet funktioniert im Allgemeinen mit .NET-Sprachen und wurde dafür entwickelt, .NET-Bibliotheken in Projekte einzubinden. Da NuGet ebenfalls die MSBuild- und Visual Studio-Automatisierung für einige Projekttypen unterstützt, werden teilweise auch andere Projekte und Sprachen unterstützt.
Die neueste Version von NuGet unterstützt C#, Visual Basic, F#, WiX, C++ und Q#.
NuGet unterstützt eine Vielzahl von Projektvorlagen vollständig, z.B. Windows, Web, Cloud, SharePoint, WiX usw.
Wechseln Sie zur Registerkarte Updates in der Benutzeroberfläche des Paket-Managers, und klicken Sie auf Alle aktualisieren. Verwenden Sie alternativ den Befehl Update-Package
über die Konsole des Paket-Managers.
Sie müssen das Repository der Vorlage manuell aktualisieren, um die Vorlage zu aktualisieren. Weitere Informationen zu diesem Thema finden Sie in diesem Blogbeitrag von Xavier Decoster. Beachten Sie, dass Sie diesen Vorgang auf Ihr eigenes Risiko durchführen, denn manuelle Updates können die Vorlage beschädigen, wenn die aktuellen Versionen aller Abhängigkeiten nicht miteinander kompatibel sind.
Ja, NuGet funktioniert direkt über die Befehlszeile. Weitere Informationen finden Sie im Installationshandbuch und in der CLI-Referenz.
Weitere Informationen finden Sie im Installationshandbuch. Um die aktuell installierte Version des Tools zu überprüfen, verwenden Sie nuget help
.
Sie dürfen „nuget.exe“ unter den Bedingungen der MIT-Lizenz weiterverteilen. Sie sind für das Aktualisieren und Warten aller Kopien von „nuget.exe“ verantwortlich, die Sie weiterverteilen.
Ja, es ist möglich, benutzerdefinierte Befehle zu nuget.exe
hinzuzufügen. Dieser Vorgang wird in einem Blogbeitrag von Rob Reynold beschrieben, der über Archive.org aufrufbar ist.
Das Objekt auf der obersten Ebene des Visual Studio-Automatisierungsobjektmodells wird als DTE-Objekt (Development Tools Environment) bezeichnet. Die Konsole stellt dieses Objekt über die Variable $DTE
bereit. Weitere Informationen finden Sie in der Dokumentation zur Erweiterbarkeit von Visual Studio unter Automation Model Overview (Übersicht über das Automatisierungsmodell).
Beim Versuch, die $DTE-Variable in den Typ DTE2 umzuwandeln, wird eine Fehlermeldung ausgegeben: „Der Wert ‚EnvDTE.DTEClass‘ vom Typ ‚EnvDTE.DTEClass‘ kann nicht in den Typ ‚EnvDTE80.DTE2‘ konvertiert werden.“ Wo liegt der Fehler?
Dabei handelt es sich um ein bekanntes Problem bei der Interaktion von PowerShell mit COM-Objekten. Probieren Sie Folgendes aus:
`$dte2 = Get-Interface $dte ([EnvDTE80.DTE2])`
Bei Get-Interface
handelt es sich um eine Hilfsfunktionen, die vom PowerShell-Host für NuGet hinzugefügt wurde.
Weitere Informationen finden Sie unter Creating and publishing a package (Erstellen und Veröffentlichen von Paketen).
Es gibt mehrere Versionen meiner Bibliothek, die verschiedene Versionen von .NET-Framework anzielen. Wie kann ein einziges Paket erstellt werden, das dies unterstützt?
Weitere Informationen finden Sie unter Supporting Multiple .NET Framework Versions and Profiles (Unterstützen mehrerer .NET Framework-Versionen und -Profile).
Weitere Informationen finden Sie unter Hosting packages overview (Übersicht über das Hosten von Paketen).
Weitere Informationen finden Sie unter Bulk publishing NuGet packages (Massenveröffentlichen von NuGet-Paketen) (jeffhandly.com).
Ja. Weitere Informationen dazu finden Sie im Blogbeitrag How to access NuGet when nuget.org is down (or you're on a plane) (Zugriff auf NuGet, wenn nuget.org offline ist (oder wenn Sie sich in einem Flugzeug befinden)) von Scott Hanselman (hanselman.com).
Wie können Pakete an einem anderen Speicherort als dem Standardordner für Pakete installiert werden?
Legen Sie die Einstellung repositoryPath
in Nuget.Config
mithilfe von nuget config -set repositoryPath=<path>
fest.
Wie kann vermieden werden, dass der Ordner für NuGet-Pakete der Quellcodeverwaltung hinzugefügt wird?
Legen Sie die Einstellung disableSourceControlIntegration
in Nuget.Config
auf true
fest. Dieser Schlüssel funktioniert auf Projektmappenebene und muss daher zur $(Solutiondir)\.nuget\Nuget.Config
-Datei hinzugefügt werden. Durch das Aktivieren der Paketwiederherstellung in Visual Studio wird diese Datei automatisch erstellt.
Weitere Informationen finden Sie unter Enabling and disabling package restore (Aktivieren und Deaktivieren der Paketwiederherstellung).
Warum wird die Fehlermeldung „Der Abhängigkeitsfehler kann nicht aufgelöst werden.“ angezeigt, wenn ein lokales Paket mit Remoteabhängigkeiten installiert wird?
Sie müssen die Quelle Alle auswählen, wenn Sie ein lokales Paket im Projekt installieren. Dadurch werden alle Feeds anstelle von einem einzigen verwendet. Diese Fehlermeldung wird angezeigt, weil Benutzer von lokalen Repositorys aufgrund von Unternehmensrichtlinien häufig verhindern möchten, dass ein Remotepaket versehentlich installiert wird.
Es gibt mehrere Projekte im selben Ordner, wie können für jedes Projekt separate PACKAGES.CONFIG-Dateien verwendet werden?
In den meisten Projekten, in denen sich separate Projekte in separaten Ordnern befinden, ist dies kein Problem, da NuGet die packages.config
-Dateien in jedem Projekt identifiziert. Wenn sich ab NuGet 3.3 und höher mehrere Projekte im gleichen Ordner befinden, können Sie den Namen des Projekts zu den packages.config
-Dateinamen hinzufügen, damit NuGet diese Datei verwendet. Verwenden Sie dabei das Muster packages.{project-name}.config
.
Dies stellt kein Problem dar, wenn Sie PackageReference verwenden, da jede Projektdatei eine eigene Liste der Abhängigkeiten enthält.
- Fügen Sie
https://api.nuget.org/v3/index.json
zur Liste der Quellen hinzu, oder - Löschen Sie
%appdata%\.nuget\NuGet.Config
(Windows) oder~/.nuget/NuGet/NuGet.Config
(Mac/Linux), damit NuGet diese Dateien neu erstellen kann.
Ich habe zu PackageReference migriert, warum ist mein Build-Fehler "Dieses Projekt verweist auf NuGet-Pakete, die auf diesem Computer fehlen".
In packages.config-Projekten wird bei Installation eines Pakets mit build
-Eigenschaften oder -Zielen von NuGet ein EnsureNuGetPackageBuildImports
-Ziel hinzugefügt, um zu überprüfen, ob die MSBuild-Inhalte des Pakets vor der Erstellung importiert wurden.
Wenn target
manuell bearbeitet wurde, kann NuGet möglicherweise nicht erkennen, dass das Ziel bei der Migration entfernt werden muss.
Wenn es sich bei Ihrem Projekt um PackageReference
handelt und sich dieses Ziel noch in der Projektdatei befindet, sollte es sicher entfernt werden können.