Der Remote-Debugger in Visual Studio 2008 analysiert Code-Probleme dort, wo sie auftauchen. Der Entwickler kann Visual Studio auf seinem Rechner verwenden und eine Verbindung zu Problemcode auf einem Remote-Host herstellen. Dadurch lassen sich Probleme entdecken, die in dieser Host-Umgebung auftauchen.
Beim Setup ist es wichtig, die richtigen Konten mit den nötigen Zugriffsrechten zu verwenden. Für Situationen, in denen Probleme auftauchen, die es nur in dieser bestimmten Anwendungsumgebung gibt, sollte der Remote-Debugger zur Entwickler-Toolbox hinzugefügt werden.
Fallbeispiel
Eine Anwendung wird erstellt und auf einem entfernten Server installiert. Doch plötzlich tritt ein Problem auf. In der eigenen Entwicklungsumgebung funktioniert der Code. Das macht es noch komplizierter, den Fehler zu finden. Auch wenn der Entwickler eventuell Zugriff auf die Anwendungsumgebung hat, möchte er wohl nur in den seltensten Fällen eine vollständige Kopie von Visual Studio auf dem Server installieren. Genau hier kommt der Remote-Debugger ins Spiel.
So bringt man den Remote-Debugger zum Laufen
Um den Remote-Debugger zu verwenden, muss er auf dem entfernten Rechner installiert und konfiguriert werden. Das ist etwas kompliziert, da die Arbeit mit dem Remote-Debugger eine gegenseitige Authentifizierung erfordert. Das heißt, der Rechner, auf dem Visual Studio läuft, muss sich beim entfernten Rechner authentifizieren – und umgekehrt.
Installation
Bei der Installation von Visual Studio 2008 werden die Remote-Debugging-Komponenten standardmäßig mitinstalliert. Außerdem ist der Remote-Debugger bereits im Installationspaket von Visual Studio enthalten. Auf der Installations-CD gibt es ein Verzeichnis namens Remote Debugger mit zwei Ordnern: x64 und x86. Sie enthalten die Setup-Anwendung für die jeweilige Plattform. Damit wird der Remote-Debugging-Monitor (msvsmon.exe) installiert. In geschilderten Fall erfolgt die Installation auf einem Server.
Wird das Setup aufgerufen, startet auch der Konfigurationsassistent. Mit ihm lässt sich festlegen, ob der Remote-Debugger als Dienst oder als Anwendung installiert werden soll. Als Dienst läuft er ununterbrochen. Daher erscheint es sinnvoller, ihn als Anwendung zu installieren. So läuft er nur, wenn es nötig ist.
Sicherheit
Für den Remote-Debugger ist ein Benutzerkonto mit den nötigen Rechten erforderlich. Es muss mindestens über dieselben Rechte verfügen wie das Konto, das für die Ausführung der fehlerhaften Anwendung zuständig ist.
Bei ASP.NET-Anwendungen wird der Worker Process (aspnet_wp.exe) in der Regel auf einem Konto namens ASPNET ausgeführt. Daher muss beim Remote-Debugging auch dieses Konto oder ein Konto mit denselben oder mehr Rechten verwendet werden. Läuft der Remote-Debugger mit den Zugriffsrechten eines Administrators, ist man in jedem Fall auf der sicheren Seite.
Für ein Produktionsumfeld ist das allerdings nicht zu empfehlen. Denn der Remote-Debugger kommuniziert mit dem lokalen Debugger über das Netzwerk. Damit besteht die Gefahr, dass der Server gehackt wird. Es ist also ratsam, ein gesondertes Benutzerkonto für den Remote-Debugger zu erstellen. Es kann beispielsweise den Namen „VSDebugger“ erhalten.
Page: 1 2
Bösartige QR-Codes, die per E-Mail versendet werden, eignen sich sehr gut, um Spam-Filter zu umgehen.
Unsichere Websites und Phishing-Mails in Verbindung mit Black Friday können kauffreudigen Konsumenten zum Verhängnis werden.
Malware SmokeLoader wird weiterhin von Bedrohungsakteuren genutzt, um Payloads über neue C2-Infrastrukturen zu verbreiten.
Bankhaus Metzler und Telekom-Tochter MMS testen, inwieweit Bitcoin-Miner das deutsche Stromnetz stabilisieren könnten.
Mit 1,7 Exaflops ist El Capitan nun der dritte Exascale-Supercomputer weltweit. Deutschland stellt erneut den…
Der deutsche Hyperscaler erweitert sein Server-Portfolio um vier Angebote mit den neuen AMD EPYC 4004…