2014-11-14 44 views
9

Während nuget Pakete wiederherzustellen versuchen, ich folgendes bin immer: -Die zugrunde liegende Verbindung wurde geschlossen: Ein unerwarteter Fehler ist aufgetreten auf einem Sende .--- NuGet

Fehler 1 Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Bei einem Sendevorgang ist ein Fehler aufgetreten.

Fehler 2 Die zugrunde liegende Verbindung wurde geschlossen: Es konnte keine Vertrauensstellung für den sicheren SSL/TLS-Kanal hergestellt werden.

Fehler 3 Der Befehl "" D: \ root \ .nuget \ NuGet.exe "installieren" D: \ root \ packages.config "-source" "-NonInteractive -RequireConsent -solutionDir" D: \ root \ " "verlassen mit Code 1.

Fehler 4 Metadaten Datei \ root \ project.UnitTests \ CSC

ich habe versucht, die Lösungen: 'D: \ root \ project.Website.dll' nicht D gefunden werden konnte Bereitgestellt auf: Visual Studio 2010 nuget error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel

Ich habe versucht, die Lösungen zur Verfügung gestellt: https://nuget.codeplex.com/discussions/275537

Keiner von ihnen funktioniert, ich frage mich, ob jemand anderes dieses Problem derzeit hat? Wenn ja, hat jemand eine Lösung gefunden?

Es scheint, möglicherweise ein warten Spiel, für die SSL-Zertifikate behoben werden.

Nach einigen weiteren Debuggen mit Fiddler bekam ich folgende Antwort:

fiddler.network.https> HTTPS-Handshake fehlgeschlagen az320820.vo.msecnd.net. System.IO.IOException Daten von der Transportverbindung konnten nicht gelesen werden: Eine bestehende Verbindung wurde vom Remote-Host zwangsweise geschlossen. < Eine bestehende Verbindung wurde vom Remote-Host

geschlossen wurde Wenn ich richtig bin, scheint es, wie ich abgelehnt habe ist aber der Server, nicht sicher, warum, und ich bin zuversichtlich, dies wird es bald selbst lösen.

Für jetzt habe ich es geschafft, Kopien von Paketen von anderen Entwicklern zu bekommen, die ihren Paket-Cache nicht gelöscht hatten und diese Entwicklung fortsetzen.

Jemand hat das Problem auf Code freundlich angehoben hoffentlich plex, so dass wir irgendwo bald bekommen: https://nuget.codeplex.com/workitem/4372

aktualisieren

Ab 17. November scheint dies wieder zu arbeiten. NuGet richtig sagen mir, dass es Probleme gibt, eine ältere Version von Ninject.Web.Common.3.2.0.0 zu bekommen, aber wir haben die aktualisierte Ausgabe, die in Ordnung ist.

+3

Ich bin in der gleichen Frage läuft gerade erst ab heute. Ich habe alle anderen Korrekturen ausprobiert und nichts funktioniert. Hast du das schon gelöst? –

+0

Sorry, nein, es scheint, als wäre einer der Knoten Knoten ausgefallen. Wir haben es geschafft, eine Kopie unserer Pakete von einem anderen Entwickler-Rechner zu bekommen, und wir entfernen diese. Mit Fiddler können Sie feststellen, welche Pakete fehlen, und diese Pakete manuell herunterladen und in Ihren Paketordner kopieren. – Anicho

+0

Ich habe versucht, auf Build nuget wiederherstellen zu deaktivieren, aber jetzt bekomme ich eine Fehlermeldung, dass nuget Paket wiederherstellen deaktiviert ist und die Build wird nicht fortgesetzt. Wer weiß, wie man das schafft, während wir darauf warten, dass nugget das Problem löst? – voidsstr

Antwort

3

Ich hatte das gleiche Problem, bis ich meine Netzwerkadministratoren angerufen habe. Wir haben festgestellt, dass unser IPS die Domain als Malware gekennzeichnet hat, und wir haben sie auf unserer internen Netzwerkebene blockiert.

Sobald wir den Block entfernt haben, funktioniert jetzt alles wieder.

Wir hatten auch Probleme, Bilder und CSS von Codeplex-Projekt-Websites zu bekommen, und das behob dieses Problem auch.

+0

Ja, das ist, was ich zuerst dachte, aber die Fiddle Logs erklärten klar, dass der entfernte Host mich ablehnte. Wenn es eine interne Blockierung wäre, würde ich einen Host nicht finden oder nicht in der Lage sein, zielbezogene Probleme zu erreichen. – Anicho

+0

Hängt davon ab, welche Art von Blockierung vorhanden ist. Meine Netzwerkadministratoren haben die Domain im Grunde in ein internes DNS-Schwarzes Loch gesteckt. Ich habe herausgefunden, was das Problem an meinem Ende war, weil die IP-Adresse in einem der privaten IP-Bereiche (172.16.x.x) war. –

+0

Wahrer Punkt. Ich habe mit unseren Netzwerkadministratoren bestätigt, dass es für mich kein Problem ist. Up'd, weil es ein potenzielles Problem für Menschen ist. – Anicho

0

Überprüfen Sie, ob Ihre Internetverbindung funktioniert und Ihre Proxy-Setup und im Internet Explorer LAN-Einstellungen aktiviert. In meinem Fall versuchte es, es aus dem Internet herunterzuladen und fehlzuschlagen, da mein Proxy deaktiviert war! Hoffe, das hilft ...

5

Ich sehe dieses Problem hinter einem Corporate Proxy mit Visual Studio 2015, die die neue v3 API (https://api.nuget.org/v3/index.json) verwendet. In meinem Fall hat es mit einem SSL-Abfangen Organ- (BlueCoat) zu tun, die nicht wissen, wie eine neuere Verschlüsselungsprotokoll verarbeiten (zB: TLS 1.2 sowie einige neuere Schlüsselaustausch Chiffre) von dieser API-Endpunkt verhandelt, glaube ich.

1

Eine schnelle Lösung für Visual Studio 2015-Benutzer ist die URL von https zu http zu ändern. Ich habe das Gefühl, dass dies nicht funktioniert, wenn das Paket eine https-Lizenzdatei hat.

Alternativ wechseln Sie zu Visual Studio 2013 für die Paketinstallation und Updates.

+1

Ja. Von https: // zu http: // url gewechselt und die Pakete sind heruntergeflossen. (Hinweis: Dies war bei der Kommunikation mit einem internen "ProGet" nugget-Server.) – jeremysawesome

0

Geben Sie diesen Befehl

Unter Linux die folgende in der Befehlszeile vor der Ausführung des Git Befehl ausführen :

export GIT_TRACE_PACKET=1;export GIT_TRACE=1;export GIT_CURL_VERBOSE=1 

Unter Windows die folgende in der Befehlszeile ausführen, bevor Sie das Git Befehl ausführen:

set GIT_TRACE_PACKET=1 set GIT_TRACE=1 set GIT_CURL_VERBOSE=1 
+0

Was macht das? – Anicho

+1

Was hat git mit nugget zu tun? – Anicho