Ausführen von Visual Studio Remote Debugger in Windows-Container (Docker verwaltet)

Question

Ich versuche, die Visual Studio Remote Debugger in einem Windows-Container auf Windows Server 2016 TP4 auszuführen. Da es in einem Container ausgeführt wird, gibt es keine Benutzeroberfläche.

Ich versuche, den Remote-Debugger über auszuführen:

.\msvsmon.exe /nostatus /silent /nosecuritywarn /nofirewallwarn /noclrwarn /port 4020 

Ich Ausführung des oben als Administrator-Benutzer (NT AUTHORITY \ System). Dies funktioniert auf dem Host-Computer, aber es funktioniert nicht innerhalb des Containers. Das Windows-Ereignisprotokoll zeigt das folgende Fehlerereignis an.

Msvsmon was unable to start a server named "`6D2D071453C5:4020`". 
The following error occurred: The parameter is incorrect. 

komplettes Ereignisprotokoll:

Get-EventLog -LogName Application -EntryType Error | format-list 

Index    : 1718 
EntryType   : Error 
InstanceId   : 3221226473 
Message   : The description for Event ID '-1073740823' in Source 'Visual Studio Remote Debugger' cannot be found. The local computer may not have the necessary registry information or message DLL 
        files to display the message, or you may not have permission to access them. The following information is part of the event:'Msvsmon was unable to start a server named 
        '6D2D071453C5:4020'. The following error occurred: The parameter is incorrect. 

        View Msvsmon's help for more information.' 
Category   : (0) 
CategoryNumber  : 0 
ReplacementStrings : {Msvsmon was unable to start a server named '6D2D071453C5:4020'. The following error occurred: The parameter is incorrect. 

        View Msvsmon's help for more information.} 
Source    : Visual Studio Remote Debugger 
TimeGenerated  : 05.04.2016 9:47:19 AM 
TimeWritten  : 05.04.2016 9:47:19 AM 
UserName   : NT AUTHORITY\SYSTEM 

bemerkte ich eine Frage in Bezug auf den Hostnamen des Behälters, aber dieses Problem behoben werden kann:

6D2D071453C5 ist der Container ID von meinen Windows-Containern (Docker verwaltet):

PS C:> docker ps -a 
CONTAINER ID  IMAGE    COMMAND     CREATED    STATUS     PORTS    NAMES 
6d2d071453c5  d9d15fbca6d7  "cmd /S /C 'C:\\myprg-" 6 days ago   Up 3 days          derrin 

Normalerweise wird in Docker diese Container-ID auch der Hostname innerhalb/des Containers sein.

Also, wenn ich docker inspect 6d2d071453c5 laufen, bekomme ich dies in der Ausgabe:

"Config": { 
    "Hostname": "6d2d071453c5", 
    "Domainname": "", 

Aber dann, im Inneren des Behälters, I-Typ "hostname" in der Befehlszeile und erhalten:

PS C:> hostname 
test2016 

Dies ist ein Bug, der derzeit für Windows Server 2016 TP4/Windows Container spezifisch ist. Der Hostname sollte nicht test2016 (der Name des Containerhosts, mein tatsächlicher physischer Win2016-Server) sein, sondern die Container-ID (6d2d071453c5). Zumindest wäre dies mein erwartetes Verhalten, und dies ist auch der Fall, wenn ich einen anderen Container, d. H. Einen Ubuntu-Container, unter Windows ausführe, die eine VM benötigen. Ich habe es nur noch einmal überprüft.

Dennoch, das Problem zu umgehen, stelle ich die Host-Datei und fügt hinzu:

172.16.0.2  6d2d071453c5 

Jetzt kann ich meine eigenen Hostnamen mindestens ping.

PS C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64> ping 6D2D071453C5 

Pinging 6d2d071453c5 [172.16.0.2] with 32 bytes of data: 
Reply from 172.16.0.2: bytes=32 time<1ms TTL=128 
Reply from 172.16.0.2: bytes=32 time<1ms TTL=128 

Dennoch ist der Remote-Debugger immer noch nicht startet, und sagt noch:

Msvsmon was unable to start a server named "`6D2D071453C5:4020`". 
The following error occurred: The parameter is incorrect. 

Ich sehe nicht, was mit einem der Parameter falsch ist, nach der Datei begleitet Hilfe, die alle Listen die Parameter und Optionen. Derselbe Befehl funktioniert auf dem Container-Host, nur nicht innerhalb des Containers.

Hat jemand den Remote-Debugger in einem Container arbeiten lassen?

======= ====== aktualisieren

Wie vorschlagen unten, ich den Hostnamen Parameter versucht. Ich sehe keinen Fehler im Ereignisprotokoll mehr, aber ich sehe auch nicht, dass irgendetwas auf Anschluss 4020 hört.

Ausgeführt im Container im Verzeichnis C: \ Programme \ Microsoft Visual Studio 14.0 \ Common7 \ IDE \ Remote Debugger \ x64:

> hostname 
WIN-DE6U4068NAF 

> ".\msvsmon.exe /nostatus /silent /nosecuritywarn /nofirewallwarn /noclrwarn /port 4020 /hostname WIN-DE6U4068NAF" 
.\msvsmon.exe /nostatus /silent /nosecuritywarn /nofirewallwarn /noclrwarn /port 4020 /hostname WIN-DE6U4068NAF 

> netstat -ab | find "4020" 

> 

Answer 1

Haben Sie versucht, zu "hart codieren" den Hostnamen der msvsmon/Hostname-Option?

Nach der msvsmon Dokumentation. „/ Host-Name hostname_value Weist den Remote-Debugger auf dem Netzwerk mit dem angegebenen Host-Namen-Wert oder die IP-Adresse Wert hört auf einem Computer mit mehreren Netzwerkkarten oder mit mehrer DNS-Host zugewiesen Diese Option kann verwendet werden, um einzuschränken, welche davon das Remote - Debuggen erlaubt (beispielsweise kann ein Server eine Internet - Adresse und eine interne Adresse haben. Mit '/ hostname private_ip_address' ist Remote - Debugging nicht über das Internet möglich) Internet-Adresse. "

Answer 2

Okay, werfen Sie das wirklich offensichtlich hier raus. Von Ihrem Beitrag, der Befehl

"\ msvsmon.exe/NOSTATUS/silent/nosecuritywarn/nofirewallwarn/noclrwarn/Port 4020/Host-Namen WIN-DE6U4068NAF"

wird genau die gleiche drucken nur, dass String in Powershell. Es startet den Debugger nicht tatsächlich. Die Echoausgabe zeigt dies an. (Ich könnte zu viel in das Lesen)

So unterdrückt /nofirewallwarn nur die durch Firewall-Warnung blockiert (YMMV), und nicht tatsächlich durch die Firewall. Hast du es zuerst mit /prepcomputer ausgeführt?

Haben Sie versucht /anyuser umgehen auth und erlauben nur TCP zu arbeiten?

Ist msvsmon tatsächlich an die richtige Netzwerkschnittstelle gebunden? Manchmal ist die Bindung an den Loopback-Adapter nur lokal erreichbar. Wenn Sie netstat zeigt es auf allen Schnittstellen hören (0.0.0.0)?

Haben Sie versucht, es als ein Service mit der /service Option laufen zu lassen? Es könnte jedoch noch einige weitere Fehler geben. Ich hatte es normalerweise schwer, es auf dem Feld zur Arbeit zu bringen.

Answer 3

Zum Debuggen müssen Sie die Remote-Tools in das Image installieren, führen Sie den Container wie normal aus, und starten Sie den Remote-Debugger mit docker exec.

Die Kommandozeile ist wie folgt:

docker exec -it <container id/name> "C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe" /nostatus /silent /noauth /anyuser /nosecuritywarn

ich ausführlicher in a blog post haben, und ja, Auth auf Ihrem lokalen dev Maschine ausschalten nicht trägt ein gewisses Risiko (egal wie klein) aber das sollte dir wenigstens eine Vorstellung davon geben, wie es geht. Sie können die Befehlszeilenoptionen immer anpassen, damit sie so funktionieren, wie Sie möchten.

Answer 4

fand ich diese Sequenz an der Arbeit:

PS C:\> start-service msvsmon150 
PS C:\Program Files\Microsoft Visual Studio 15.0\Common7\IDE\Remote Debugger\x64> .\msvsmon /noauth /anyuser /silent 

Der Start-Service-Befehl kann einen Fehler, wie der Dienst Furz aus nicht gestartet werden, wenn sie in einem Windows 10 gehostete Windows-Container ausgeführt wird. Nach Eingabe des zweiten Befehls werden die Ports jedoch in netstat -ab als blockiert angezeigt, und Visual Studio 2017 kann die Debugger-Einheit ausspionieren.