visual tools studio remote how debugger debug c# .net visual-studio-2008 debugging remote-debugging

c# - tools - Depuración remota en Visual Studio(VS2008), aplicación Windows Forms



visual studio debug remote (6)

Estoy intentando depurar remotamente una aplicación de Windows Forms (C #), pero siempre obtengo este error:

No se puede conectar al Monitor de depuración remota de Microsoft Visual Studio llamado ''XXX. El depurador remoto de Visual Studio en la computadora de destino no se puede conectar nuevamente a esta computadora. Autenticación fallida Por favor, consulte Ayuda para obtener ayuda.

Traté de configurar según las guías de MSDN, pero no pude hacerlo funcionar.

Mi configuración:

  • Computadora de desarrollo - XP (x86) que está conectada a un dominio.
  • Computadora de prueba - Vista (x86) que NO está conectada a un dominio.
  • Tengo conexión de red entre las máquinas.
  • Creé un usuario local en la computadora de prueba (usuario1) con el nombre del usuario de mi dominio que ejecutaba Visual Studio (mydomain / user1). configurar la misma contraseña
  • En la computadora de prueba estoy ejecutando "msvsmon.exe" como aplicación (no como servicios), lo estoy ejecutando con el comando "runas" con el usuario que he creado. (usuario1):

    runas / u: user1 msvsmon.exe

¿Puede alguien ayudarme por favor?

Gracias.


¿ TESTCOMPUTER/user1 tiene la misma contraseña que mydomain/user1 ?

También puede intentar ejecutar msvsmon.exe en la computadora de destino en lugar del servicio de depuración remota. Puede usar "Ejecutar como ..." para ejecutarlo bajo varias credenciales. Una vez que trabaje con msvsmon,exe , debería poder instalar (o volver a habilitar) el servicio del depurador remoto ejecutándolo bajo esas credenciales.

EDITAR:

Debería poder usar la página de propiedades Permisos en msvsmon.exe para configurar los permisos de depuración apropiados para su usuario de dominio en la máquina de destino:

http://msdn.microsoft.com/en-us/library/ms164722.aspx


Gregg Miskely tiene una publicación de blog sobre por qué la cuenta de servicio debe tener privilegios de administrador (cuando se configura de esa manera). Uno de los puntos es que la cuenta de usuario, en su caso el usuario en la máquina de prueba, debe tener privilegios para conectarse de nuevo a la otra computadora. Parece que está abordando un caso en el que la cuenta mydomain / user1 tiene privilegios insuficientes para conectarse a su computadora de desarrollo.

Si eso no ayuda a leer detenidamente las publicaciones del blog de Gregg, enviarle correos podría ser útil.


El problema que tuve es que tuve 2 usuarios:

mydomain/user1 mytestmachine/user1

eso no es correcto (según Gregg Miskely). Necesitaba definir un usuario local en mi computadora de desarrollo, por ejemplo:

mydevcomputer/debug mytestmachine/debug

con la misma contraseña y ejecuta el VS2008 y el Monitor de depuración con este usuario:


Entonces, usted es un desarrollador y uno de sus usuarios recibió una excepción, y desea depurarlo de manera remota sin cerrar la ventana de excepción, pero están conectados como una cuenta de usuario diferente. Como resultado, puede depurar su aplicación, pero se vuelve complicado.

0) Aún necesita cuentas locales coincidentes tanto en la máquina de aplicación remota como en la máquina local de Visual Studio, lo que significa agregar una cuenta a la computadora del usuario.

1) Necesita usar runas con la opción / netonly. Abra un símbolo del sistema en la carpeta donde está msvsmon y escriba

runas /user:[user] /netonly msvsmon

Esto hace que msvsmon use las credenciales del usuario solo cuando accede a la red (por ejemplo, cuando msvsmon se conecta de nuevo a la máquina VS local). msvsmon se molestará si lo llamas con runas sin usar / netonly.

2) Debe agregar permisos para la máquina local de Visual Studio para conectar la máquina de aplicación remota, a través del menú Herramientas del monitor de depuración remota-> Permisos.


Así que no puedo responder sin una cuenta, y solo puedo responder a mis propios comentarios, pero mi cuenta registrada es independiente de la cuenta anónima que publiqué, por lo que esta debe ser una "nueva respuesta". Lo siento.

baget: cuando hice esto hoy, creé una cuenta local tanto en Remote Debug Monitor PC como en Visual Studio PC. RDM no estaba en el dominio, VS lo estaba. Ambas cuentas locales son administradores con credenciales idénticas a mi cuenta de dominio. Desde una cuenta diferente (también administrador) llamé a runas desde un prompt elevado con el interruptor netonly. Puede o no necesitar proporcionarle a su dominio el nombre de usuario, pero dado que las contraseñas deberían coincidir, no creo que importe mucho.

No olvide ajustar sus permisos en el RDM para permitir que la cuenta de usuario que ejecuta VS se conecte con privilegios de depuración. Es bastante quisquilloso sobre a quién le permite agregar a la lista, por lo que si no crea la cuenta local primero, se sentirá bastante frustrado. Y si está ejecutando RDM con un nombre de cuenta de usuario diferente, debe usar el nombre completo del servidor cuando intente conectarse a la computadora remota; Si ejecuta tanto RDM como VS desde la misma cuenta de usuario, puede salirse con la suya solo con el nombre de la computadora.


Así es como funcionó para mí:

Computadora remota: Microsoft Virtual PC, "IHS / RDM" conectada a mi dominio corporativo, iniciada como jdoe, cuenta de administrador.

Computadora local: conectada al dominio local, iniciada como jdoe, cuenta de administrador.

1) computadora remota: instale rdbgsetup.exe (desde Visual Studio 2005 / Disk 2 / Remote Debugger / x86)

2) Computadora remota: RUNAS / usuario MYDOMAIN / jdoe / netonly msvsmon

3) Computadora remota: msvsmon-> Herramientas-> permisos agregar usuario "MYDOMAIN / jdoe" (Tengo que hacer esto cada vez que reinicio)

4) computadora local: ejecuta msvsmon.

5) computadora local, msvsmon-> Herramientas-> permisos, agregar tipos de objetos: "computadoras", "IHS / RDM"

6) computadora local, vs2005-> depuración-> adjuntar al proceso. Transporte: Predeterminado, Calificador: jdoe @ RDM

7) Refrescar, y voila; una lista de procesos!