7
votes

Comment déboguer un rôle de travailleur en utilisant le bureau distant avec Windows Azure?

J'ai maintenant mon environnement Windows Azure configuré afin que je puisse accéder à mon rôle travailleur avec le bureau distant. Cependant, je ne suis pas sûr de savoir comment procéder pour le moment. Après beaucoup de creuser, j'ai trouvé un site Web hors ligne mais dans le cache de Google, il était mentionné d'attacher au rôle travailleur en cours d'exécution dans le nuage Azure à partir du débogueur Visual Studio. Mais je n'ai que Visual Developer (non studio) 2010 et j'ai cherché partout dans la mesure où je peux voir qu'il n'y a pas une telle option pour joindre à un serveur distant. Je suis capable de publier mon projet au cloud Azure sans erreur et j'ai une instance "saine" de mon rôle travailleur montrant comme actif et en cours d'exécution.

J'ai connecté avec RDP via le portail de gestion Azure. Le login a travaillé correctement et augmente la fenêtre de bureau à distance. J'ai cherché une grande partie de ce que je pouvais trouver et que je n'ai pas pu trouver le rôle de mon travailleur. Je dois avoir une mauvaise impression de RDP, car j'avais espéré voir le formulaire d'affichage principal du rôle de travailleur lorsque je me suis connecté, tout comme je le fais lorsque je le débogé localement dans l'émulateur de nuages. Mais tout ce que j'ai vu, tout ce que j'ai vu, c'était un bureau vierge avec des routines d'inspection et de gestion de serveur de niveau de base. J'ai même vérifié le visualiseur d'événements pour les messages liés à l'application et n'a vu aucun.

Alors maintenant, je suis coincé à me demander si mon rôle de travailleur est en train de courir ou non, malgré les messages d'état apparemment positifs du portail de gestion, et je souhaite toujours joindre à mon rôle de travail pour le débogage via le développeur visuel, s'il est possible que possible. , mais je suis incapable de comprendre comment.

Toute personne ayant une expérience dans ce domaine qui peut me donner des conseils solides sur quoi faire ensuite, s'il vous plaît répondre.

MISE À JOUR: Je pense que mon rôle de travailleur peut être en cours d'exécution car j'ai ouvert une fenêtre de commande et a fait un NetStat et l'a vu être écouté sur le bon port. Toutefois, cela peut être juste mon rôle de travailleur, classe shell qui commence l'EXE personnalisé que j'ai lancé en tant que procès engendré. Je n'ai toujours pas confirmé si mon EXE personnalisé fonctionne encore.

update-2: il suffit de faire connaître une liste de tâches à partir d'une fenêtre de commande et l'exe personnalisé est répertorié.

Mise à jour-3: Tout fonctionne car je viens de passer un test à distance du service afin que ce n'est pas un problème. Je souhaite toujours savoir comment attacher au rôle de travailleur de Visual Developer 2010 pour débogage à distance, et s'il est possible de voir le formulaire d'affichage de l'EXE personnalisé comme je le fais lors du débogage local dans l'émulateur de nuages.

- Roschler


3 commentaires

Devez-vous vous connecter à l'aide d'un débogueur? Ou est-ce suffisant pour voir les messages?


@ Anže Vodovnik - Je vais prendre ce que je peux obtenir pour le moment, mais éventuellement, j'aurai besoin de débogueraisaisais. Aussi, s'il vous plaît voir ma note de mise à jour à mon message d'origine. Si vous ne le voyez pas, c'est parce que je n'ai pas fini de taper.


Aussi, est-il possible de voir une présentation d'écran distant de mon écran principal de mon rôle de travailleur comme je vois quand je le débogerai localement (le RDP fait-il cela)?


5 Réponses :


1
votes

Je suppose que vous pouviez distant à votre VM, installez Visual Studio là-bas et déboguer le processus ...

Je suppose également qu'il serait possible d'activer le débogage à distance (pas sûr de ce qui y est impliqué, mais une telle chose existe, et cela fonctionne sur TCP) et déboguer à partir d'une instance locale de Visual Studio.

À ma connaissance, cela ne se fait pas non plus.


4 commentaires

J'ai fait du débogage à distance, mais c'était trop lent pour être pratique. Je pense que Winebug serait probablement la voie à aller, mais la courbe d'apprentissage est très raide.


Bonjour à nouveau @smarx. La page Web que j'ai trébutée à travers cela a parlé de cela mentionné sur la cuisson dans certaines dll supplémentaires dans le rôle de travailleur. Mais j'ai la réponse que je cherchais. Ce n'est pas pratique. Je voudrais toujours pouvoir voir l'interface graphique d'EXE personnalisée qui, pour une raison quelconque, est invisible lorsque je me connecte avec RDP.


Lorsque vous RDP dans, vous n'êtes pas dans le même contexte d'interface graphique que lorsque votre EXE est en cours d'exécution. (Vous n'êtes même pas connecté comme le même utilisateur.) Je ne suis même pas sûr que votre exe a un contexte d'interface graphique pour que vous puissiez regarder.


@smarx - Droite. J'ai oublié le simple fait que RDP ne soit pas comme un programme de moniteur injecté, mais un utilisateur enregistré séparément, merci.



1
votes

Quand vous dites:

Mais tout ce que j'ai vu, il s'agissait d'un bureau vierge avec des routines d'inspection et de gestion de serveur de base.

C'est exactement ce que vous obtenez avec un VM Azure. C'est une installation de base du système d'exploitation, plus le strict minimum de choses d'azur qu'il faut exécuter et le code que vous avez téléchargé. Il n'y a pas de surveillance fantaisie ou de chèques de santé disponibles sur la machine par défaut, vous devriez avoir fourni à ceux-ci vous-même les avoir disponibles sans avoir à RDP dans la machine pour vérifier.

RDP est très bon pour suivre certains problèmes, comme la vérification d'une tâche de démarrage exécutera, vérifiant quelles répertoires sont installées et qu'elles sont généralement curatives. Si vous avez besoin d'outils supplémentaires pour suivre un problème, vous pouvez simplement les installer lorsque vous êtes connecté au serveur. Par exemple, j'ai RCPED dans un serveur et installé le Outils de débogage Microsoft , Pour suivre un problème de mémoire.


3 commentaires

Lorsque j'ai débogué, l'exe personnalisé a engendré le code de rôle de l'ouvrier C # localement, dans l'émulateur de nuages, il apparaît avec un formulaire d'affichage qui a une fenêtre de journalisation et quelques autres choses; L'écran d'application principal si vous voulez. C'est le même comportement que si l'EXE était exécuté autonome. En d'autres termes, ce n'est pas un service de fond sans fenêtre ou même une application de console. C'est une application complète Windows GUI. Lorsque je me connecte à la console RDP, je ne vois pas l'interface graphique de l'application, même si cela fonctionne bien. J'essaie de savoir pourquoi je ne vois pas cet élément d'interface graphique et s'il y a une façon de pouvoir.


@knightpfor - Merci pour le lien Microsoft Débogage Outils. Si vous savez avoir un didacticiel indiquant comment l'installation avec Azure et Visual Developer 2010, merci de me le faire savoir.


Lorsque vous RDP dans votre VM, vous le faites en tant qu'utilisateur particulier que vous avez spécifié dans la configuration RDP. Votre rôle travailleur ne fonctionne pas comme cet utilisateur, il fonctionne comme l'un des comptes système (je ne me souviens plus de celui de la tête de ma tête). Donc, comme toute autre session RDP, vous ne pouvez pas voir le bureau des autres utilisateurs.



1
votes

Basé sur d'autres réponses, vous feriez mieux d'écrire un fichier journal à un stockage local. Vous pouvez lire le fichier de RDP si vous voulez vraiment. Gardez à l'esprit, le débogage sur Azure n'est pas vraiment simple, et à juste titre.

Ce que je pensais, ce que je pensais, c'était peut-être pourriez-vous exécuter le processus en utilisant les informations d'identification de l'utilisateur. Je ne peut pas vérifier pour le moment, mais vous avez un meilleur coup de voir l'interface utilisateur lorsque vous RDP.


1 commentaires

Idée intéressante sur les informations d'identification de l'utilisateur. On dirait que mon prochain projet doit creuser dans le stockage local, puis le stockage SQL. Espérons que Azure SQL n'est pas trop différente de MySQL.



4
votes

Il y a un ensemble d'articles ici qui passe en longueur sur la manière de mettre en place pour le débogage à distance à Azure:

http://blogs.u2u.be/peter/post/2011/06/21/Remote-debugging-an-AZURE-Role-upérer- Azure-Connect-Remote-Desktop-et-The-Remote-Debugger.aspx

http://blogs.u2u.be/peter/post/2011/06/24/Remote-debugging-an-Azure-worker-role- Utilisation-AZURE-Connect-Connect-Remote-Duktop-and-Remote-Debugger-Part-2.AspX

http://blogs.u2u.be/peter/post/2011/06/26/Remote-debugging-a-windows- Azure-Worker-Worker-Worker-Work-Feher-Connect-Connect-Connect-Remote-Desktop-et-The-Débogueur-Part-3.AspX

La touche à emporter est que vous n'avez pas besoin d'installer Visual Studio sur Azure, il vous suffit de copier les bits de débogueur à distance, puis d'utiliser Azure Connect pour ajouter votre machine de développeur au réseau virtuel.


1 commentaires

@Urtimay: l'application blogs.u2u.be est nulle, mais vous pouvez obtenir le contenu utile de la vue de la page sural: blogs.u2u.be/peter/?page=2 et blogs.u2u.be/peter/?page=1



2
votes

Vous pouvez configurer le débogage à distance avec Visual Studio 2012
http://code.msdn.microsoft.com/remote-debugging-windows-dedaaec9


2 commentaires

Un peu d'un résumé ici serait utile


La libération de Windows Azure SDK 2.2 ajoute la prise en charge de débogage à distance de nombreux types de ressources Windows Azure. weblogs.asp.net/scottgu/archive/2013/10/22/...