Freigeben über

Bekannte Probleme mit NuGet

  • Artikel

Im Folgenden finden Sie die häufigsten bekannten Probleme mit NuGet, die wiederholt gemeldet werden. Wenn Sie Probleme beim Installieren von NuGet oder dem Verwalten von Paketen haben, lesen Sie sich diese bekannten Probleme und ihre Lösungen durch.

Hinweis

Ab NuGet 4.0 sind bekannte Probleme Teil der Anmerkungen zur jeweiligen Version.

NuGet-Überwachungseinstellungen werden für Projekte mit packages.config in Visual Studio 17.10 möglicherweise nicht korrekt angewendet

Die NuGet-Überwachungsunterstützung wurde für packages.config-Projekte ab NuGet 6.10 und Visual Studio 17.10 hinzugefügt. Informationen zum Konfigurieren der NuGet-Überwachung finden Sie in unseren Dokumenten zu Überwachungspaketen.

Problem:

Wenn zwei oder mehr Projekte, die packages.config in der Projektmappe verwenden, denselben Projektnamen verwenden, wählt NuGet Audit eines aus und verwendet dieselben NuGet-Überwachungseinstellungen für beide Projekte.

Das Tracking-Problem zum Entfernen dieser Einschränkung ist auf GitHub verfügbar.

Problemumgehung:

Wenn alle Projekte mit demselben Namen dieselben Konfigurationswerte verwenden, gibt es keinen funktionalen Unterschied, wenn NuGet ein Projekt mit der Konfiguration eines anderen Projekts wiederherstellt.

NuGet.exe hat diese Einschränkung nicht. Sie können also NuGet.exe herunterladen und NuGet.exe restore in Ihrer Lösung ausführen, um zu sehen, ob sich die NuGet-Überwachungswarnungen in der Befehlszeile von den Meldungen in Visual Studio unterscheiden.

Wenn es möglich ist, die Projekte so umzubenennen, dass sie unterschiedliche Projektnamen haben, wird dieses Problemszenario nicht auftauchen.

Authentifizierungsprobleme mit NuGet-Feeds in VSTS mit „nuget.exe“ (Version 3.4.3)

Problem:

Wenn der folgende Befehl verwendet wird, um die Anmeldeinformationen zu speichern, wird das persönliche Zugriffstoken doppelt verschlüsselt.

$PAT = "Ihr persönliches Zugriffstoken" $Feed = "Ihre URL" .\nuget.exe sources add -Name Test -Source $Feed -UserName $UserName -Password $PAT

Problemumgehung:

Speichern Sie Kennwörter in Klartext mithilfe der Option -StorePasswordInClearText.

Fehler beim Installieren von Paketen mit NuGet 3.4 und 3.4.1

Problem:

In NuGet 3.4 und 3.4.1 werden keine Quellen als verfügbar gemeldet, wenn das NuGet-Add-In verwendet wird, und es ist nicht möglich, neue Quellen im Konfigurationsfenster hinzuzufügen. Das Ergebnis ähnelt der folgenden Abbildung:

NuGet-Konfigurationsfenster ohne Quellen

Die NuGet.Config-Datei in Ihrem %AppData%\NuGet\-Ordner (Windows) oder ~/.nuget/-Ordner (Mac oder Linux) wurde versehentlich geleert. Schließen Sie Visual Studio (unter Windows), löschen Sie die NuGet.Config-Datei, und wiederholen Sie den Vorgang, um dieses Problem zu beheben. NuGet erstellt eine neue NuGet.Config-Datei, und Sie können nun weitermachen.

Fehler beim Installieren von Paketen mit NuGet 2.7

Problem:

In NuGet 2.7 wird beim Installieren eines Pakets, das Assemblyverweise enthält, wie im Folgenden dargestellt möglicherweise die Fehlermeldung „Die Eingabezeichenfolge hat das falsche Format.“ angezeigt:

install-package log4net
    Installing 'log4net 2.0.0'.
    Successfully installed 'log4net 2.0.0'.
    Adding 'log4net 2.0.0' to Tyson.OperatorUpload.
    Install failed. Rolling back...
    install-package : Input string was not in a correct format.
    At line:1 char:1
        install-package log4net
        ~~~~~~~~~~~~~~~~~~~~~~~
        CategoryInfo : NotSpecified: (:) [Install-Package], FormatException
        FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.InstallPackageCommand

Dies wird durch die Typbibliothek für die COM-Komponente VSLangProj.dll verursacht, deren Registrierung auf Ihrem System aufgehoben wurde. Dies kann beispielsweise vorkommen, wenn Sie zwei Versionen von Visual Studio parallel installiert haben und die ältere Version deinstallieren. Dadurch kann die Registrierung der oben genannten COM-Bibliothek versehentlich aufgehoben werden.

Lösung:

Führen Sie diesen Befehl für eine Eingabeaufforderung mit erhöhten Rechten aus, um die Typbibliothek für VSLangProj.dll erneut zu registrieren.

regsvr32 "C:\Program Files (x86)\Common Files\microsoft shared\MSEnv\VsLangproj.olb"

Wenn der Befehl fehlschlägt, überprüfen Sie, ob die Datei an diesem Speicherort vorhanden ist.

Weitere Informationen zu diesem Fehler finden Sie hier [work item](https://nuget.codeplex.com/workitem/3609 "Work item 3609").

Buildfehler nach dem Aktualisieren des Pakets in Visual Studio 2012

Das Problem: Sie verwenden Visual Studio 2012 RTM. Beim Aktualisieren von NuGet-Paketen erhalten Sie diese Meldung: „Ein oder mehrere Pakete konnten nicht vollständig deinstalliert werden“ und Sie werden aufgefordert, Visual Studio neu zu starten. Nach dem Neustart von Visual Studio erhalten Sie merkwürdige Buildfehler.

Dies wird durch bestimmte Dateien in alten Paketen verursacht, die durch einen MSBuild-Hintergrundprozess gesperrt sind. Auch nach dem Neustart von Visual Studio verwendet der MSBuild-Hintergrundprozess diese Dateien noch in den alten Paketen, wodurch die Buildfehler verursacht werden.

Dieses Problem kann durch die Installation eines Updates für Visual Studio 2012 behoben werden (z.B. Update 2 für Visual Studio 2012).

Das Upgrade auf die aktuelle NuGet-Version von einer älteren Version verursacht einen Signaturüberprüfungsfehler

Wenn Sie Visual Studio 2010 SP1 ausführen, wird Ihnen möglicherweise folgende Fehlermeldung angezeigt, wenn Sie versuchen, ein Upgrade für NuGet durchzuführen und eine ältere Version installiert ist.

Installer für Visual Studio-Erweiterungen

In den Protokollen wird möglicherweise SignatureMismatchException angezeigt.

Es gibt einen Visual Studio 2010 SP1 hotfix (Hotfix für Visual Studio 2010 SP1), den Sie installieren können, um dies zu vermeiden. Alternativ können Sie das Problem einfach umgehen, indem Sie NuGet zuerst deinstallieren (während Visual Studio als Administrator ausgeführt wird) und dann über den Erweiterungskatalog von Visual Studio erneut installieren. Weitere Informationen finden Sie unter https://support.microsoft.com/kb/2581019.

Die Konsole des Paket-Managers löst eine Ausnahme aus, wenn das Visual Studio-Add-In „Reflector“ ebenfalls installiert ist.

Wenn Sie die Konsole des Paket-Managers ausführen, wird Ihnen möglicherweise folgende Fehlermeldung angezeigt, wenn das Visual Studio-Add-In „Reflector“ installiert ist.

The following error occurred while loading the extended type data file:
Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2950) :
Error in type "System.Security.AccessControl.ObjectSecurity":
Exception: Cannot convert the "Microsoft.PowerShell.Commands.SecurityDescriptorCommandsBase"
value of type "System.String" to type "System.Type".
System.Management.Automation.ActionPreferenceStopException:
Command execution stopped because the preference variable "ErrorActionPreference" or common parameter
is set to Stop: Unable to find type

oder

System.Management.Automation.CmdletInvocationException: Could not load file or assembly 'Scripts\nuget.psm1' or one of its dependencies. <br />The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG)) ---&gt; System.IO.FileLoadException: Could not load file or <br />assembly 'Scripts\nuget.psm1' or one of its dependencies. The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG)) <br />---&gt; System.ArgumentException: Illegal characters in path.
    at System.IO.Path.CheckInvalidPathChars(String path)
    at System.IO.Path.Combine(String path1, String path2)
    at Microsoft.VisualStudio.Platform.VsAppDomainManager.<AssemblyPaths>d__1.MoveNext()
    at Microsoft.VisualStudio.Platform.VsAppDomainManager.InnerResolveHandler(String name)
    at Microsoft.VisualStudio.Platform.VsAppDomainManager.ResolveHandler(Object sender, ResolveEventArgs args)
    at System.AppDomain.OnAssemblyResolveEvent(RuntimeAssembly assembly, String assemblyFullName)
    --- End of inner exception stack trace ---
    at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadBinaryModule(Boolean trySnapInName, String moduleName, String fileName, <br />Assembly assemblyToLoad, String moduleBase, SessionState ss, String prefix, Boolean loadTypes, Boolean loadFormats, Boolean&amp; found)
    at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleNamedInManifest(String moduleName, String moduleBase, <br />Boolean searchModulePath, <br />String prefix, SessionState ss, Boolean loadTypesFiles, Boolean loadFormatFiles, Boolean&amp; found)
    at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleManifest(ExternalScriptInfo scriptInfo, ManifestProcessingFlags <br />manifestProcessingFlags, Version version)
    at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModule(String fileName, String moduleBase, String prefix, SessionState ss, <br />Boolean&amp; found)
    at Microsoft.PowerShell.Commands.ImportModuleCommand.ProcessRecord()
    at System.Management.Automation.Cmdlet.DoProcessRecord()
    at System.Management.Automation.CommandProcessor.ProcessRecord()
    --- End of inner exception stack trace ---
    at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
    at System.Management.Automation.Runspaces.Pipeline.Invoke()
    at NuGetConsole.Host.PowerShell.Implementation.PowerShellHost.Invoke(String command, Object input, Boolean outputResults)
    at NuGetConsole.Host.PowerShell.Implementation.PowerShellHostExtensions.ImportModule(PowerShellHost host, String modulePath)
    at NuGetConsole.Host.PowerShell.Implementation.PowerShellHost.LoadStartupScripts()
    at NuGetConsole.Host.PowerShell.Implementation.PowerShellHost.Initialize()
    at NuGetConsole.Implementation.Console.ConsoleDispatcher.Start()
    at NuGetConsole.Implementation.PowerConsoleToolWindow.MoveFocus(FrameworkElement consolePane)

Der Autor des Add-Ins wurde in der Hoffnung kontaktiert, dass dieser eine Lösung dafür ausarbeiten kann.

Update: Es wurde festgestellt, dass die aktuelle Version von Reflector (6.5) diese Ausnahme nicht mehr in der Konsole auslöst.

Das Öffnen der Konsole des Paket-Managers schlägt mit der Ausnahme „ObjectSecurity“ fehl

Möglicherweise werden Ihnen diese Fehler angezeigt, wenn Sie die Konsole des Paket-Managers öffnen:

The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2977) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2984) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2991) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(2998) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\SysWOW64\WindowsPowerShell\v1.0\types.ps1xml(3005) : Error in type "System.Security.AccessControl.ObjectSecurity": Exception: The getter method should be public, non void, static, and have one parameter of type PSObject.
The term 'Get-ExecutionPolicy' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Wenn dies der Fall ist, befolgen Sie die auf StackOverflow erläuterte Lösung, um das Problem zu beheben.

Das Dialogfeld „Add Package Library Reference“ (Bibliotheksverweis zum Paket hinzufügen) löst eine Ausnahme aus, wenn die Projektmappe ein InstallShield Limited Edition-Projekt enthält.

Wenn Ihre Projektmappe mindestens ein InstallShield Limited Edition-Projekt enthält, löst das Dialogfeld Add Package Library Reference (Bibliotheksverweis zum Paket hinzufügen) beim Öffnen eine Ausnahme aus. Es gibt derzeit keine Problemumgehung außer dem Entfernen und Entladen der InstallShield-Projekte.

Ist die Schaltfläche „Deinstallieren“ abgeblendet? NuGet erfordert Administratorrechte für die Installation/Deinstallation

Wenn Sie versuchen, NuGet über den Erweiterungs-Manager in Visual Studio zu deinstallieren, werden Sie feststellen, dass die Schaltfläche „Deinstallieren“ deaktiviert ist. NuGet erfordert Administratorrechte für die Installation und Deinstallation. Starten Sie Visual Studio als Administrator erneut, um die Erweiterung zu deinstallieren. Das Verwenden von NuGet erfordert keinen Administratorzugriff.

Die Konsole des Paket-Managers stürzt ab, wenn sie in Windows XP geöffnet wird. Wo liegt der Fehler?

NuGet erfordert die Runtime von PowerShell 2.0. Windows XP verfügt standardmäßig nicht über PowerShell 2.0. Sie können die Powershell 2.0-Runtime unter PowerShell 2.0 Download herunterladen. Starten Sie Visual Studio nach der Installation neu. Es sollte dann möglich sein, die Konsole des Paket-Managers zu öffnen.

Die Betaversion von Visual Studio 2010 SP1 stürzt beim Beenden ab, wenn die Konsole des Paket-Managers geöffnet ist.

Wenn Sie die Betaversion von Visual Studio 2010 SP1 installiert haben, werden Sie möglicherweise feststellen, dass Visual Studio abstürzt, wenn Sie die Konsole des Paket-Managers geöffnet lassen und das Programm beenden. Dabei handelt es sich um ein bekanntes Problem von Visual Studio, das im Release SP1 RTM behoben wird. Ignorieren Sie den Absturz vorerst, oder deinstallieren Sie wenn möglich die Betaversion von SP1.

Die Ausnahme „Das Element ‚metadata‘ hat ein ungültiges untergeordnetes Element“ tritt auf

Wenn Sie Pakete installiert haben, die mit einer Vorabversion von NuGet erstellt wurden, wird Ihnen möglicherweise die Fehlermeldung „Das Element ‚metadata‘ im Namespace ‚schemas.microsoft.com/packaging/2010/07/nuspec.xsd‘ hat ein ungültiges untergeordnetes Element“ angezeigt, wenn Sie die RTM-Version von NuGet mit diesem Projekt ausführen. Sie müssen jedes Paket, das die RTM-Version von NuGet verwendet, deinstallieren und erneut installieren.

Beim Versuch einer Installation oder Deinstallation wird die Fehlermeldung „Eine Datei kann nicht erstellt werden, wenn sie bereits vorhanden ist.“ angezeigt.

Aus unbekannten Gründen können Visual Studio-Erweiterungen einen merkwürdigen Status aufweisen, bei dem die Erweiterung für VSIX zwar deinstalliert wurde, aber einige Dateien verbleiben. So umgehen Sie dieses Problem:

  1. Visual Studio beenden

  2. Öffnen Sie folgenden Ordner (dieser könnte sich auf Ihrem Computer auf einem anderen Laufwerk befinden):

    C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft Corporation\NuGet Package Manager<version>\

  3. Löschen Sie alle Dateien mit der Erweiterung DELETEME.

  4. Öffnen Sie Visual Studio erneut.

Nachdem Sie diese Schritte befolgt haben, sollten Sie den Vorgang fortsetzen können.

In seltenen Fällen verursacht das Kompilieren mit aktivierter Codeanalyse Fehler.

Ihnen wird möglicherweise folgende Fehlermeldung angezeigt, wenn Sie „FluentNHibernate“ über die Konsole des Paket-Managers installieren und Ihr Projekt anschließend mit aktivierter Codeanalyse kompilieren.

Error 3 CA0058 : The referenced assembly
'NHibernate, Version=3.0.0.2001, Culture=neutral, PublicKeyToken=aa95f207798dfdb4'
could not be found. This assembly is required for analysis and was referenced by:
C:\temp\Scratch\src\MyProject.UnitTests\bin\Debug\MyProject.UnitTests.dll.
MyProject.UnitTests

Standardmäßig erfordert FluentNHibernate NHibernate 3.0.0.2001. Entwurfsbedingt installiert NuGet jedoch NHibernate 3.0.0.4000 in Ihrem Projekt und fügt die entsprechenden Bindungsumleitungen hinzu, sodass das Paket funktioniert. Ihr Projekt wird problemlos kompiliert, wenn die Codeanalyse deaktiviert ist. Im Gegensatz zum Compiler folgt das Codeanalysetool den Bindungsumleitungen, um 3.0.0.4000 statt 3.0.0.2001 zu verwenden, nicht ordnungsgemäß. Sie können dieses Problem umgehen, indem Sie entweder NHibernate 3.0.0.2001 installieren oder das Codeanalysetool folgendermaßen dafür konfigurieren, sich genau wie der Compiler zu verhalten:

  1. Wechseln Sie zu %PROGRAMFILES%\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop.
  2. Öffnen Sie „FxCopCmd.exe.config“, und ändern Sie AssemblyReferenceResolveMode von StrongName in StrongNameIgnoringVersion.
  3. Speichern Sie die Änderung, und erstellen Sie das Projekt erneut.

Der Befehl „Write-Error“ funktioniert innerhalb von „install.ps1/uninstall.ps1/init.ps1“ nicht

Dies ist ein bekanntes Problem. Versuchen Sie, „throw“ statt „Write-Error“ aufzurufen.

throw "My error message"

Das Installieren von NuGet mit eingeschränktem Zugriff unter Windows 2003 kann zu einem Absturz von Visual Studio führen

Wenn Sie versuchen, NuGet über den Visual Studio Extension Manager zu installieren und nicht als Administrator ausgeführt werden, wird das Dialogfeld „Ausführen als“ angezeigt, in dem standardmäßig das Kontrollkästchen „Dieses Programm mit eingeschränktem Zugriff ausführen“ aktiviert ist.

Dialogfeld „Programm mit eingeschränktem Zugriff ausführen“

Wenn dieses Kontrollkästchen aktiviert ist, und Sie auf OK klicken, stürzt Visual Studio ab. Stellen Sie sicher, dass Sie diese Option nicht deaktivieren, bevor Sie NuGet installieren.

NuGet-Tools für Windows Phone können nicht deinstalliert werden

Windows Phone-Tools unterstützen den Erweiterungs-Manager für Visual Studio nicht. Führen Sie folgenden Befehl aus, um NuGet zu deinstallieren.

vsixinstaller.exe /uninstall:NuPackToolsVsix.Microsoft.67e54e40-0ae3-42c5-a949-fddf5739e7a5

Das Ändern der Groß-/Kleinschreibung von NuGet-Paket-IDs unterbricht die Paketwiederherstellung

Wie in diesem GitHub-Problem ausführlich erläutert wird, kann eine Änderung der Groß-/Kleinschreibung von NuGet-Paketen vom NuGet-Support durchgeführt werden. Dies führt jedoch zu Komplikationen während der Paketwiederherstellung für Benutzer mit vorhandenen Paketen mit unterschiedlicher Groß-/Kleinschreibung im Ordner global-packages. Es wird empfohlen, nur eine Änderung der Groß-/Kleinschreibung anzufordern, wenn Sie mit den Benutzern Ihrer Pakete kommunizieren können, um diese über die Unterbrechung zu informieren, die bei der Paketwiederherstellung zur Buildzeit auftreten kann.

Melden von Problemen

Unter https://github.com/nuget/home/issues können Sie Probleme mit NuGet melden.