14

provo a fare funzionare il di Visual Studio Remote Debugger in un di Windows contenitore su Windows Server 2016 TP4. Poiché viene eseguito all'interno di un contenitore, non esiste un'interfaccia utente.esecuzione di Visual Studio Remote Debugger in Windows Container (Docker gestito)

provo a fare funzionare il debugger remoto tramite:

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

sto eseguendo quanto sopra come utente amministratore (NT AUTHORITY \ system). Funziona bene sul computer host, ma non funziona all'interno del contenitore. Il registro eventi di Windows mostra il seguente evento di errore.

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

Complete registro eventi:

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 

ho notato un problema che riguarda l'hostname del contenitore, ma questo può essere risolto:

6D2D071453C5 è l'ID contenitore del mio contenitore di Windows (finestra mobile gestita):

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 

Di solito, in Docker, questo ID contenitore sarà anche il nome host all'interno del contenitore.

Così, quando corro docker inspect 6d2d071453c5, ottengo questo nell'output:

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

Ma poi, all'interno del contenitore, di tipo I "hostname" nella riga di comando e ottenere:

PS C:> hostname 
test2016 

Questo è un bug specifico per Windows Server 2016 Contenitori TP4/Windows al momento. Il nome host non deve essere test2016 (il nome dell'host contenitore, il mio server fisico effettivo Win2016) ma l'id contenitore (6d2d071453c5). Almeno, questo sarebbe il mio comportamento previsto e questo è anche il caso quando eseguo qualsiasi altro contenitore, ad esempio un contenitore Ubuntu, su Windows che richiede una VM. L'ho appena ricontrollato.

Tuttavia, per aggirare il problema, ho regolare il file host, aggiungendo:

172.16.0.2  6d2d071453c5 

ora posso rumore metallico il mio proprio nome host, almeno.

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 

Tuttavia, il debugger remoto ancora non si avvia, e dice ancora:

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

non vedo cosa c'è di sbagliato con uno qualsiasi dei parametri, in base al file di aiuto accompagnati che elenca tutti i parametri e le opzioni. Lo stesso comando funziona bene sull'host del contenitore, ma non all'interno del contenitore.

Qualcuno ha ottenuto che il debugger remoto funzionasse all'interno di un container?

Aggiornamento ======= ======

Come suggeriscono di seguito, ho provato il parametro hostname. Non vedo più alcun errore nel registro eventi, ma non vedo nulla che stia ascoltando sulla porta 4020.

Eseguito all'interno del contenitore nella directory C: \ Programmi \ 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" 

> 
+0

Aggiunto problema di docker relativo al nome host: https://github.com/docker/docker/issues/21762 –

+0

Il problema dell'hostname sembra essere un problema noto di Container Windows in Server 2016 TP4, vedere https://github.com/docker/docker/temi/21762 # issuecomment-205.904.128. Tuttavia, la mia domanda originale rimane. –

+0

Il problema dell'hostname è stato risolto in Server 2016 TP5, tuttavia, non ha ancora ottenuto il debugger remoto su cui lavorare. –

risposta

1

hai provato a "codificare" il nome host utilizzando l'opzione msvsmon/hostname?

Secondo la documentazione msvsmon:. "/ hostname hostname_value incarica il debugger remoto per ascoltare sulla rete che utilizza il valore nome host specificato, o il valore indirizzo IP su un computer con più schede di rete, o con più host DNS assegnato nomi, questa opzione può essere utilizzata per limitare quali di questi consentiranno il debug remoto. Ad esempio, un server potrebbe avere un indirizzo Internet e un indirizzo interno. Utilizzando '/ hostname private_ip_address', il debug remoto non sarà disponibile attraverso indirizzo internet. "

+0

Vedere il mio OP aggiornato sopra. –

1

Ok, buttare fuori l'ovvio qui. Dal tuo post, il comando

"\ Msvsmon.exe/nostatus/silent/nosecuritywarn/nofirewallwarn/noclrwarn/porta 4020/hostname WIN-DE6U4068NAF"

sarà solo la stampa che esattamente lo stesso stringa in powershell. In realtà non avvia il debugger. L'output dell'eco mostra questo. (Potrei leggerlo troppo)

Quindi /nofirewallwarn sopprime solo l'avviso del firewall bloccato (YMMV) e in realtà non passa attraverso il firewall. Hai eseguito prima con /prepcomputer?

Hai provato /anyuser per ignorare l'autenticazione e consentire solo il funzionamento di TCP?

msvsmon è effettivamente associato all'interfaccia di rete corretta? A volte, essere associato all'adattatore loopback significa che può essere raggiungibile solo localmente. Quando si visualizza netstat per l'ascolto su tutte le interfacce (0.0.0.0)?

Hai provato a utilizzarlo come servizio con l'opzione /service? Ci potrebbero essere altri trucchi, però. Di solito ho avuto difficoltà a farlo funzionare sul campo.

+0

Grazie per la risposta. Non ho più questo ambiente installato e funzionante, quindi non posso più testarlo adesso. Il progetto è diventato obsoleto nel frattempo. Penso di averlo eseguito anche senza i due punti "", ma non sono sicuro, perché è così che l'ho eseguito sull'host per testarlo anche lì (vedi la mia prima riga di comando). Hai fatto in modo che il debugger scorresse dentro il contenitore dalla tua parte? Dal momento che hai menzionato "In genere ho avuto difficoltà a farlo funzionare sul campo". –

+0

Ho provato a farlo funzionare in Windows Server senza testa su una VPN (TAP), e questi erano alcune delle cose che avrei provato – Asti

+0

Le mie scuse, Mathias Ho appena notato la data della pubblicazione originale – Asti

0

Per eseguire il debug è necessario installare gli strumenti remoti nell'immagine, eseguire normalmente il contenitore e quindi avviare il debugger remoto utilizzando docker exec.

La riga di comando è la seguente:

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

Ho più dettagliatamente in a blog post, e sì, spegnendo autenticazione sul computer locale dev fa portare qualche rischio (non importa quanto piccolo) ma questo dovrebbe almeno darti un'idea di come farlo. Puoi sempre modificare le opzioni della riga di comando per farlo funzionare nel modo desiderato.

0

ho trovato questa sequenza di lavoro:

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

Il comando start-Service sarà scoreggiare fuori un errore su come il servizio non può iniziare quando si esegue in un Windows 10 ha ospitato il contenitore di Windows. Tuttavia, dopo aver inserito il secondo comando, le porte vengono visualizzate come bloccate in netstat -ab e Visual Studio 2017 può rilevare l'unità del debugger.

Problemi correlati