Débogage à distance dans Visual Studio (VS2008), application Windows Forms

Question

Je suis en train de distance Débogage une application Windows Forms (C #), mais je suis toujours à obtenir cette erreur:

  

Impossible de se connecter au moniteur de débogage à distance Microsoft Visual Studio   nommé « XXX. La télécommande Visual Studio   Debugger sur l'ordinateur cible ne peut pas   reconnecter à cet ordinateur.   Authentification échouée. S'il vous plaît voir Aide   de l'aide.

J'ai essayé de config selon les guides MSDN, mais je n'ai pas pu le faire fonctionner.

Ma configuration:

• Ordinateur de développement - XP (x86) que est connecté à un domaine.
• Test de l'ordinateur - Vista (x86) qui est pas     connecté à un domaine.
• Je connexion réseau entre     les machines.
• J'ai créé un utilisateur local dans le test     ordinateur (user1) avec le nom de mon domaine     utilisateur que je lance le Visual Studio (mydomain \ user1). configurer le même mot de passe.

• Le test de l'ordinateur je suis en cours d'exécution "msvsmon.exe" comme application (pas en tant que services), je suis en cours d'exécution à l'aide de "runas" commande avec l'utilisateur que j'ai créé. (User1):

  runas / u: user1 msvsmon.exe

Quelqu'un peut me aider s'il vous plaît?

Merci.

Answer 1

Voici comment cela a fonctionné pour moi:

L'ordinateur distant: Microsoft Virtual PC, "IHS \ GMD" attaché à mon domaine d'entreprise, connecté en tant jdoe, compte administrateur

.

Ordinateur local. Rattaché au domaine local, connecté en tant jdoe, compte administrateur

1) ordinateur distant: installer rdbgsetup.exe (à partir de Visual Studio 2005 \ disque 2 \ Remote Debugger \ x86)

2) ordinateur à distance: runas / user MYDOMAIN \ jdoe / netonly msvsmon

3) Ordinateur à distance: msvsmon-> Outils-> autorisations ajouter un utilisateur "MYDOMAIN \ jdoe" (je dois le faire à chaque fois que je re-démarrage)

4) ordinateur local:. Msvsmon run

5) ordinateur local, msvsmon-> Outils-> autorisations, ajouter des types d'objets: "ordinateurs", "IHS \ GMD"

6) ordinateur local, vs2005-> Debug-> attacher à traiter. Transport: Par défaut, Qualifier: jdoe @ GMD

7) Actualiser, et voilà; une liste de processus!

Answer 2

Le problème est que j'avais que j'avais 2 utilisateurs:

mydomain\user1
mytestmachine\user1

ce n'est pas correct (selon Gregg Miskely) i besoin de définir un utilisateur local dans mon ordinateur de développement, par exemple:

mydevcomputer\debug
mytestmachine\debug

avec le même mot de passe et exécuter le VS2008 et le Debugging Monitor avec cet utilisateur:

Answer 3

Gregg Miskely a une blog pourquoi le compte de service doit avoir des privilèges d'administrateur (lorsqu'il est réglé de cette façon). L'un des points est que le compte utilisateur, dans votre cas, l'utilisateur sur la machine de test, doit avoir des privilèges pour connecter revenir à l'autre ordinateur. On dirait que vous frappez un cas où le compte mydomain \ user1 a des privilèges suffisants pour se connecter à votre ordinateur de développement.

Si cela ne vous aide pas lisant attentivement les messages du blog de Gregg, l'envoi de courrier pourrait aider.

Answer 4

Est-ce que TESTCOMPUTER\user1 le même mot de passe mydomain\user1?

Vous pouvez également essayer d'exécuter msvsmon.exe sur l'ordinateur cible au lieu du service de débogage à distance. Vous pouvez utiliser « Exécuter en tant que ... » pour l'exécuter sous divers titres de compétence. Une fois que vous obtenez des choses de travail avec msvsmon,exe vous devriez être en mesure d'installer (ou réactiver) le service Remote Debugger l'avoir exécuté sous ces informations d'identification.

EDIT:

Vous devriez être en mesure d'utiliser la page de propriétés Permission de msvsmon.exe pour configurer les autorisations de débogage appropriées pour votre utilisateur de domaine sur la machine cible:

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

Answer 5

Vous êtes un développeur et un de vos utilisateurs a obtenu une exception, et que vous voulez déboguer à distance sans fermer la fenêtre d'exception, mais ils sont connectés en tant que compte d'utilisateur différent. Comme il se trouve, vous pouvez déboguer leur application, mais il devient délicat.

0) Vous devez toujours correspondre les comptes locaux sur la machine d'application à distance et la machine Visual Studio local, ce qui signifie que l'ajout d'un compte à l'ordinateur de l'utilisateur.

1) Vous devez utiliser runas avec l'option / netonly. Ouvrez une invite de commande dans le dossier où msvsmon est et le type

runas /user:[user] /netonly msvsmon

Cela provoque msvsmon d'utiliser les informations d'identification de l'utilisateur que lorsque l'accès au réseau (par exemple lorsque msvsmon se connecte à la machine locale VS). msvsmon va se fâcher si vous l'appelez avec runas sans utiliser / netonly.

2) Vous devez ajouter des autorisations pour la machine Visual Studio local pour se connecter la machine d'application à distance, via la télécommande Outils- de Debug Monitor> Menu Autorisations.

Answer 6

Je ne peux pas répondre sans compte, et je ne peux pas répondre à mes propres commentaires, mais mon compte enregistré est distinct du compte anonyme que j'ai posté de, donc ce doit être une « nouvelle réponse ». Désolé.

Baget - quand j'ai fait ce travail plus tôt aujourd'hui, j'ai créé un compte local à la fois le moniteur de débogage à distance PC et PC Visual Studio. GMD n'a pas été sur le domaine, VS était. Les deux comptes locaux sont administrateur des informations d'identification identiques à mon compte de domaine. D'un autre compte (administrateur aussi) j'ai appelé runas à partir d'une invite élevée avec le commutateur netonly. Vous pouvez ou pas besoin de fournir votre domaine avec le nom d'utilisateur, mais étant donné que les mots de passe doivent tout le match, je ne pense pas qu'il ait beaucoup d'importance.

Ne pas oublier d'ajuster vos autorisations dans le GMD pour permettre au compte utilisateur exécutant VS pour se connecter avec des privilèges de débogage. Il est assez pointilleux sur qui il vous permet d'ajouter à la liste, donc si vous ne créez pas le compte local d'abord, vous aurez assez frustré. Et si vous utilisez GMD sous un autre nom de compte utilisateur, vous devez utiliser le nom complet du serveur lorsque vous essayez de joindre à l'ordinateur distant; si vous exécutez à la fois et GMD VS à partir du même compte utilisateur, vous pouvez vous en sortir avec juste le nom de l'ordinateur.