TFS kann das NuGet-Paket nicht wiederherstellen

Ich habe das auch gesehen. Es scheint ausgelöst zu werden, sobald die NuGet-Paketwiederherstellung in den internen Feed wechselt. Sobald dies der Fall ist, wird nicht mehr zum offiziellen Feed von nuget.org gewechselt und weiterhin nach den Paketen auf dem internen Feed gesucht.

Stellen Sie sicher, dass beide Paketquellen Ihrer NuGet.config-Datei hinzugefügt wurden. Stellen Sie außerdem sicher, dass beide Quellen "aktiv" sind.

Siehe NuGet-Konfigurationsdatei .

Matts Antwort hat mich auf den richtigen Weg gebracht, aber wir verwenden kein internes Futter, also musste ich noch mehr graben. Diese Antwort funktioniert mindestens für ein Projekt, das in Visual Studio 2015 erstellt und von TFS 2015 erstellt wurde.

Öffnen Sie in Visual Studio die NuGet-Paket-Manager-Einstellungen (Menü Extras & gt; NuGet Paket-Manager & gt; Paket-Manager-Einstellungen). Wählen Sie "Paketquellen" aus der Optionsliste auf der linken Seite.

Erstellen Sie die Datei nuget.config im Stammverzeichnis der Lösung. Dies sollte derselbe Ordnerpfad sein wie Ihre ".sln" -Lösungsdatei. Kopiere folgendes in die Konfigurationsdatei:

Erstellen Sie im <packageSources> -Tag einen <add key="" value="" /> -Eintrag für jede Quelle, die im Optionsfenster "Package Sources" aufgelistet ist. Der Schlüssel ist der Name der Quelle, der über der URL angezeigt wird, und der Wert ist die URL selbst. Fügen Sie diejenigen hinzu, die sowohl unter "Verfügbare Paketquellen" als auch "Maschinenweite Paketquellen" aufgeführt sind. Ich habe keinen Eintrag für das lokale Dateisystem erstellt, da es in dieser Lösung nicht verwendet wurde. Basierend auf dem obigen Screenshot enthält die vollständige Konfigurationsdatei nun Folgendes:

Nachdem TFS die Datei nuget.config an die Quellcodeverwaltung übergeben hat, konnte er alle erforderlichen NuGet-Pakete herunterladen und die Lösung erfolgreich erstellen.

Zusätzlich zu Matts Antwort möchte ich die folgenden gut versteckten Sachen aus der NuGet-Dokumentation hervorheben:

  

NuGet-Konfigurationsdateien werden in der folgenden Prioritätsreihenfolge behandelt   (am nächsten zu dem Ordner nuget.exe läuft von Wins), zum Beispiel unter der Annahme   Das Lösungsverzeichnis ist c:\a\b\c :

     

• c:\a\b\c\.nuget\nuget.config - Diese Datei wird nur für die Lösung verwendet   Level-Pakete, und wird nicht in nugget 3.0 - 3.4 unterstützt
  
• c:\a\b\c\nuget.config
  
• c:\a\b\nuget.config
  
• c:\a\nuget.config
  
• c:\nuget.config
  
• Benutzerspezifische Konfigurationsdatei,    %AppData%\NuGet\nuget.config .
  
• Oder die benutzerdefinierte Datei durch Option    -ConfigFile .
  

Dies könnte ein seltsames Verhalten in bestimmten Szenarien erklären, in denen eine Wiederherstellung einen konfigurierten Feed übernimmt oder nicht, je nachdem, ob Sie mit nuget 2.x oder 3.x

Bearbeiten: und ich fand noch einen weiteren Grund, warum Pakete möglicherweise nicht gefunden werden :

  

Ich habe das Paket "A" mit der Version 1.1.1.0 .

     

Vor 3.4 funktioniert dieser Befehl gut:

     

nuget install A -version 1.1.1.0

     

Mit NuGet 3.4 RC bekomme ich:

     

An error occurred while retrieving package metadata for 'A.1.1.1' from source 'N'. An error occurred while retrieving package metadata for 'A.1.1.1' from source 'N'. Data at the root level is invalid. Line 1, position 1.

     

...

     

Der Client behandelt 1.1, 1.1.0, 1.01.0 und 1.1.0.0 als die gleiche Version   Verwenden von SemVer-Regeln. Der Grund, warum nicht normalisierte Versionen speziell waren   in der Vergangenheit cased ist, weil für v2 http Anrufe der Client würde zuerst   Senden Sie die Versionszeichenfolge genau so, wie der Benutzer sie angegeben hat