Windows Azure WebRole oder WorkerRole remote Debuggen

Wenn man für Microsoft Windows Azure Cloud Dienste entwickelt, kommt man doch relativ bald in die Situation, wo man sich wünscht die Applikation auch in der wirklichen Laufzeitumgebung von Windows Azure debuggen zu können. Natürlich ist es ein sehr großer Vorteil von Windows Azure, dass man mit dem Azure SDK und Visual Studio eine lokale Emulation der Windows Azure Laufzeitumgebung zur Verfügung hat, aber das bleibt halt eine Emulation. Manchmal verhält sich die „echte“ Umgebung halt doch etwas anders, oder ich möchte wirklich mehrere Instanzen parallel debuggen, was so in der lokalen Umgebung auch nicht möglich ist. Zunächst hier die Liste der Vorrausetzungen, die ich erfüllen muss um das Ganze Szenario nachvollziehen zu können. Wichtig an der Stelle ist zu erwähnen, dass dies alles kostenfrei möglich ist.

1. Man braucht natürlich einen Azure Account über den man seine Cloud Services anlegen, verwalten und deployen kann. Es reicht auch ein Windows Azure Test Account den man sich auf der Windows Azure Webseite holen kann.

2. Eine Visual Studio Version mindestens Visual Studio 2010 oder Visual Studio 2012, es reicht auch die Express Version oder Visual Studio Web Developer 2010.

3. Das entsprechende Azure SDK das man im Windows Azure Develoer Center herunterladen kann. Wenn Visual Studio 2010 verwendet wird sollte man noch APS.NET MVC 4 nachinstallieren.

Im Weiteren verwende ich Visual Studio 2012 sowie die Applikation aus dem Tutorial: „.NET Multi-Tier Application Using Service Bus Queues“. Dort wird auch nochmal beschrieben wie man die Tools und das SDK installiert.

Wenn man also diese App lokal mit ServiceBus fertig hat dann sind folgende Schritte notwendig um das Debuggen in der Cloud zu ermöglichen.

1. Im neuen Management Portal einen neuen Cloud Service anlegen:  

2. Namen des Dienstes angeben und das Datacenter auswählen wo der Cloud Dienst betrieben werden soll.  

3. Um den Netzwerkzugriff für das Remote Debuggen zu ermöglichen, ist es notwendig Windows Azure Connect zu verwenden, wenn man auf den doch größeren Aufwand für eine Virtuelle VPN Umgebung vermeiden möchte. Windows Azure Connect wird leider im Moment vom neuen Management Portal (noch) nicht unterstützt. Also muss man auf die Vorgängerversion des Portals umschalten:  

4. Im alten Management Portal dann auf Verbinden klicken um Windows Azure Connect anzuschalten:  

5. Auf der dann angezeigten Seite findet man die Ressourcen rund um Windows Azure Connect. Der nächste Schritt zum Verwenden von Windows Azure Connect ist. Den Windows Azure Account unter Verbinden im Menü links auszuwählen und dann das Aktivierungstoken herunterladen.

6. In der folgenden Box dann auf „Token in Zwischenablage kopieren“ klicken und dann mit Ok beenden.

7. Das Aktivierungstoken muss man dann noch in die Konfiguration der zu debuggenden Rolle übernehmen. Dazu in Visual Studio bei den Rollen mit rechtem Mausklick auf die Rolle in den Properties bzw. Eigenschaften unter Virtual Network das Aktivierungstoken übernehmen. Dies erzeugt die nötigen Einträge in der Datei ServiceDefinition.csdef. Hier kann man auch weitere Einstellungen für die Rollen vornehmen, aber für mein Beispiel reichen die Default Einstellungen.

8. Jetzt kann man das Package direkt von Visual Studio aus veröffentlichen. Dazu bei den Rollen auf Publish bzw. Veröffentlichen klicken.

9. Wenn man dies das erste Mal macht muss man zunächst über den Link „Sign In“ mit seinem Microsoft Account eine Datei mit „Publish Settings“ herunterladen und diese dann über den Import Button in Visual Studio übernehmen. Dann einen Storage Account anlegen und nach Möglichkeit dieselbe Region für alle Komponenten verwenden. Also auch Northern Europe. Dann unter Cloud Service den im Portal angelegten Dienst auswählen. Build Configuration ist klar, muss natürlich Debug sein. Dann unbedingt Remote Desktop für die Rollen einschalten, da wir die Remote Debugging Komponenten von Visual Studio auf die VMs bekommen müssen. Also mit Settings einen Account zum Remote Access auf die VMs einrichten. Wenn man dann auf Next klickt bekommt man nochmals eine Übersicht aller Settings und kann mit Publish das Apllikationspaket zu Azure hochladen. Bis die Applikation dann bereit ist kann es schon einige Minuten dauern.

10. Um Connect mit der VM-Rolle zu verwenden, müssen Sie die Connect Endpoint-Software auf dem Computer, der zum Erstellen des VM-Image verwendet wird, über den folgenden Link installieren: https://waconnect.blob.core.windows.net/client/latest/x64/wacendpointpackagefull.exe . Oder man klickt im alten Portal einfach auf „Lokalen Endpunkt installieren“ klicken. Damit wird dann gleich das richtige Token mitübergeben.

11. Im folgenden Dialog dann den Link kopieren und im Browser eingeben und die Software installieren. Nach der Installation erscheint das Connect Symbol in der Taskleiste und nach einigen Sekunden zeigt das Symbol auch an dass man mit Windows Azure Connect verbunden ist.

12. Jetzt muss man noch eine Servergruppe anlegen um die Verbindung zu ermöglichen.

13. Im nachfolgenden Dialog die lokale Maschine auswählen und die entsprechende Rolle asuwählen zu der man die Verbindung ermöglichen möchte. Die Check Box nicht vergessen damit man die Verbindung auch zulässt.

14. Wenn dies erfolgreich abgeschlossen wurde muss man noch im Windows Azure Connect Client auf „Richtlinie aktuakisieren“ klicken, damit die Änderungen von Azure übernommen werden. Nach einigen Minuten kann man dann den Netzwerkzugriff auf die VM z.B. mittels ping testen. Wenn dies funktioniert hat man Windows Azure Connect erfolgreich eingerichtet.

15. Zum weiteren Vorgehen ist es einfacher wieder in das neue Management von Windows Azure zu wechseln. Dazu in der Statuszeile auf den Link „Zum neuen Portal“ klicken. Dann den entsprechenden Clouddienst anklicken. Auf „Wird bereitgestellt“ klicken, da wir in die Staging Umgebung deployed haben. Dann in der oberen Zeile auf Instanzen klicken. Die Worker Rolle anklicken und dann in der Statuszeile auf verbinden klicken.

16. Die RDP auf dem lokalen PC z.B. auf dem Desktop abspeichern. Danach mit rechter Maustaste anklicken und Context Menü dann „Edit“ bzw. „Bearbeiten“ auswählen. Dann denn Reiter Local Resources anklicken und auf den More Button klicken.

17. Dann hier den Zugriff auf die lokale Platte ermöglichen, damit man die Remote Debugging Komponenten auf die VM der Worker Role kopieren kann.

18. Dann mit „Connect“ die Remote Desktop Verbindung starten und mit den im Schritt 9 angelegten Account anmelden . In der Virtuellen Maschine dann den Explorer starten und über die eingebundene lokale Platte zu den Remote Debug Komponenten von Visual Studio navigieren. Diese befinden sich bei einer Standardinstallation im Verzeichnis: C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger Dort gibt es dann zumindest zwei Unterverzeichnisse X86 und x64. Am einfachsten ist es das Verzeichnis x64 auf die VM zu kopieren. Dann auf der virtuellen Maschine das Verzeichnis öffnen und die Datei msvsmon.exe lokalisieren und diese dann starten.

19. Beim ersten Start wird folgende Dialogbox angezeigt. Damit wird die Firewall automatisch für das Remote Debuggen konfiguriert.

20. Dass die Virtuelle Maschine zum Debuggen bereit ist sieht man an dem anschließend angezeigten Fenster, wo dann steht, dass auf eingehende Verbindungen gewartet wird.

21. Jetzt zurück zu Visual Studio wo man jetzt im Debug Menü unter „Attach to Process“ den Dialog startet, um den Debugger mit dem Remote Debugger zu verbinden. Dazu den Rechnernamen der VM mit :portnummer eingeben also z.B.: RD0015D520D9D:4016 eingebe, dann muss man sich wiederum mit seinem Account anmelden und dann in der Prozessliste den Prozess WaWorkerHost.exe auswählen und auf Attach klicken.

22. In Visual Studio z.B. die Source Datei WorkerRole.cs im Projekt OrderProcessingRole öffnen und einen Breakpoint setzen.

23. Dann im Management Portal auf Dashboard klicken und die SiteURL im rechten Bereich anklicken damit die Site im Browser gestartet wird.

24. Dann in der App eine Eingabe machen und auf Create klicken, dann sollte nach einigen Sekunden der Debugger am vorher gesetzten Breakpoint anhalten.

25. Im Visual Studio Debugger kann man, wie sonst auch, auf die Variablen und alle Debugging Features zugreifen.

BINGO!