2009-09-07 5 views
4

Nous avons deux serveurs Win2k3 ici, l'un est un contrôleur de domaine et l'autre notre serveur web. J'exécute une configuration d'application Web ASP.NET MVC en tant que site Web dans IIS sur le serveur Web.Débogage à distance sur IIS - Accès refusé Nightmare!

J'ai copié les outils de débogage à distance x86 sur le serveur Web, je me suis connecté à un compte administrateur et j'ai exécuté msvsmon. J'ai ajouté l'utilisateur que je suis connecté à mon poste de travail en ce qui concerne la liste des autorisations.

a ouvert le projet de l'application Web dans VS2008 et est allé à Attacher au processus, voici mes paramètres:

Transport: Default 
Qualifier: OURDOMAIN\[email protected] 
Attach To: Managed Code 

Selected: w3wp.exe 

Après avoir cliqué sur Attachez, les fenêtres clignotent pendant quelques secondes, puis je reçois :

Unable to attach to the process. Access is denied. 

J'ai essayé msvsmon clic droit et en utilisant exécuter en tant que pour l'exécuter sous le même compte que je suis logg ed dans ma machine, mais toujours pas de différence.

Cependant, si je change le Pour champ Attacher à automatique: code natif, il se fixe bien, mais je ne peux pas déboguer tout mon code managé .NET.

Cela m'a déconcerté - des idées?

Anthony

Répondre

3
+0

+1 pour le lien .. C'est l'article le plus détaillé sur la mise en place de débogage à distance que j'ai vu.Merci! –

+1

Page est en baisse maintenant ... S'il vous plaît afficher la viande de l'article sur SO prochaine fois – John

+0

C'est probablement cette page https://support.microsoft.com/en-us/kb/833977 – archgl

0

Le code est assis précompilée sur le serveur ou dans des fichiers individuels .cs non compilés?

+0

Précompilé. J'ai essentiellement frappé Build Solution dans VS2008, puis copié le dossier bin sur le serveur. – littlecharva

+0

Je pense que cela pourrait être le problème. Essayez de placer les fichiers .cs dans le dossier sur le serveur au lieu des fichiers précompilés. – Jaelebi

+0

Pas de joie, je ai peur :( – littlecharva

1

On ne sait pas de votre question, mais le débogage à distance exige que l'utilisateur que vous êtes connecté sur la machine distante existe sur votre machine locale. Vous devez essentiellement créer un compte local sur votre machine dev (oui, cela sonne à l'envers). Je ne suis pas sûr que cela respecte les comptes de domaine.

+0

D'accord avec cela, et plus loin, vous devez vous assurer que les utilisateurs ne disposent pas * de mots de passe *. ils le font, une politique de groupe spéciale doit être définie. –

0

J'ai essayé msvsmon clic droit et en utilisant Exécuter en tant que pour l'exécuter sous le même compte que je suis connecté sur ma machine, mais toujours pas de différence.

Avez-vous ajouté ce compte en tant qu'administrateur sur le serveur? Je voudrais essayer cela, et au lieu de faire Run As, je me connecterais effectivement avec ce compte. Lors de l'exécution du serveur et du client dans différents domaines, l'intrigue s'épaissit légèrement. Dans ces cas, l'astuce que j'utilise est de créer un compte local avec le même nom et le même mot de passe sur les deux machines. Connectez-vous avec le même compte (ce n'est pas vraiment le même compte) dans les deux machines et lancez le débogueur distant sur le serveur et VS sur le client. Si l'une des machines de ce scénario exécute Windows XP, vous devez modifier la stratégie de sécurité locale, «Accès réseau: modèle de partage et de sécurité pour les comptes locaux», sous «Options de sécurité», à «Classique - les utilisateurs locaux s'authentifient». .

0

Je n'ai pas encore vu ce travail à travers les domaines.Comme avec @ paul-mrozowski, j'ai été capable de le faire sur le même domaine tant que l'utilisateur qui exécute le serveur de débogage correspond à votre utilisateur local ET que vous êtes capable de l'authentifier correctement contre la machine. Ce dernier bit peut être gêné par les configurations de pare-feu.