Warum wurde bei einem Visual Studio Web Deploy der Fehler "Unerwarteter Fehler beim Senden" bei der Veröffentlichung auf einer Intranetsite angezeigt, die als IPv6-Adresse aufgelöst wird? Ich gehe davon aus, dass IPv6 etwas damit zu tun hat, da das Hinzufügen der IPv4-Adresse zur hosts-Datei das Problem behebt und die Webbereitstellung erfolgreich ist.Warum würde IPv6 einen Web Deploy stören?
Details:
- Zunächst wird die Build-Fehler kamen von einem Teamcity Build-Agenten, aber das gleiche Problem tritt auf, wenn (oder nur bestätigt die Verbindung im Profil veröffentlichen) von Visual Studio zu veröffentlichen versuchen.
- Ein Ping (erfolgreich) an den Zielcomputer wird an eine IPv6-Adresse aufgelöst, die mit der Adresse identisch ist, die beim Ausführen von "ipconfig" auf dem Zielcomputer selbst gefunden wurde, mit Ausnahme einer anderen Bereichskennung am Ende.
- Windows UNC Freigaben Pfade zu den Zielmaschinen funktionieren
- Die Zielmaschine ist eigentlich der Host der VM, auf dem der Build-Agent ausgeführt wird.
Unten ist der Fehler beim Überprüfen der Verbindung im Veröffentlichungsprofil.
Und Detail aus dem ursprünglichen Build/deploy Versuch.
C: \ Program Files (x86) \ MSBuild \ Microsoft \ Visualstudio \ v14.0 \ Web \ Microsoft.Web.Publishing.targets (4276, 5): Web-Deployment-Task fehlgeschlagen. (Die Anforderung konnte nicht an die Remote-Agent-URL "https://tapserver:8172/msdeploy.axd?site=MealPlannerCIAPI" gesendet werden.) Dieser Fehler weist darauf hin, dass Sie keine Verbindung zum Server herstellen können. Stellen Sie sicher, dass die Service-URL korrekt ist, Firewall- und Netzwerkeinstellungen auf diesem Computer und auf dem Servercomputer ordnungsgemäß konfiguriert sind und die entsprechenden Dienste auf dem Server gestartet wurden. Fehlerdetails: Die Anforderung konnte nicht an die URL des Remoteagenten 'https://tapserver:8172/msdeploy.axd?site=MealPlannerCIAPI' gesendet werden. Die zugrunde liegende Verbindung wurde geschlossen: Beim Senden ist ein unerwarteter Fehler aufgetreten. Daten von der Transportverbindung konnten nicht gelesen werden: Eine bestehende Verbindung wurde vom Remote-Host zwangsweise geschlossen. Eine bestehende Verbindung wurde von der Remote-Host
wieder gewaltsam geschlossen ich das Problem behoben habe, aber es ist ein sehr verwirrendes fix für mich. Was würde einen der Msdeploy-Aufrufe, die behoben wurden, unterbrechen, indem die IPv4-Adresse zur hosts-Datei hinzugefügt wird, wenn sie diesen Host bereits mit v6 erreicht?
weil nicht nur Ihre Maschine und der Server ipv6 fähig sein müssen, müssen alle Router zwischen Ihnen und dem Server auch sein. Wenn es keinen passenden Dienst gibt, der zwischen Ihnen und dem Server v6-> v4-> v6 überbrückt, gehen Ihre Pakete einfach irgendwo verloren. z.B.es kann eine 10-spurige Autobahn von Ihrem Haus zum Stadtrand geben, und eine weitere 10-spurige Autobahn vom Rand der Serverstadt bis zur Haustür, aber Ihre Städte sind durch einen Ozean und einen schlammigen Ziegenpfad getrennt. –
Ah, und das gilt auch ohne Internet? Das ist alles im selben LAN, von einer VM zu ihrem Host [obwohl ja, ich bin mir sicher, dass es den Router treffen muss, also ist das vielleicht genug]. Es ist nur überraschend, dass es scheitern würde, wenn Ping, gemeinsame Pfade und der Zugriff auf vorhandene Webendpunkte auf diesem Rechner funktionieren. Nur nicht diese Msdeploy ruft Port 8172 auf. Selbst wenn ich den Msdeploy-Endpunkt in einen Browser einfüge, kann ich sehen, dass der Endpunkt * dort * ... –
ist, wenn alles lokal ist und du IPv6 nicht brauchst, könnte es einfach versuchen ipv6 an beiden Enden ausschalten. –