• Theo Tzaferis
• 18.11.2019
• DE

How-To: Remote debugging mit JetBrains Rider

Für einen Softwareentwickler führt so gut wie kein Weg an einer IDE vorbei. Die zwei Big Player für .NET sind hierbei Microsoft's Visual Studio und JetBrains' Rider. Entwickler, die bereits in anderen Sprachen entwickelt haben sind unter Umständen bereits schon über IDEs von JetBrains gestoßen, wissen das Feature-Set zu schätzen und möchten nun auch Rider für die .NET-Entwicklung einsetzen.

Da Remote Debugging im Kontext von WSM aber sehr wichtig is und Windows Server von Haus aus keinen SSH Server mitliefert ist ein Debugging mit Rider nicht ohne weiteres möglich, denn Rider unterstützt Verbindungen nur per SSH, während Visual Studio auch per Domain und ohne Authentifizierung auf externe Systeme zugreifen kann.

Da OpenText eine Windows-Applikation ist und bei einem Windows Server standardmäßig kein SSH Server vorinstalliert ist, sind einige Schritte nötig, um auch mit JetBrains eine OpenText Applikation remote debuggen zu können. Dieser Artikel beschreibt, wie es möglich ist den besagten SSH Server auf dem Windows Server zu installieren um Rider zum Remote Debugging zu verwenden. Das vorgegebene Setting hierbei ist, dass Rider auf dem Host-System des Anwenders liegt, während OpenText in einem Windows Server guest in einer VirtualBox VM auf dem Host-System läuft. 

Um eine OpenText-Umgebung mit SSH Server zu konfigurieren gibt es mehrere Möglichkeiten, allerdings konzentrieren wir uns mit diesem Artikel auf die manuelle Installation. Ebenso ist es auch möglich die SSH-Authentifizierung per private/public key authentication durchzuführen, in diesem Artikel wird jedoch nur die password authentication beschrieben.
 

SSH Server auf Windows Server installieren

Um einen SSH Server auf dem Windows Server zu installieren brauchen wir zunächst die Assemblies für den Server. Dafür bietet Microsoft ein git-Repository an, bei dem die aktuellste Version (v8.0.0.0p1-Beta; Stand 11/2019) heruntergeladen werden kann. 

Achtung: In der README des verlinkten Repository steht zwar, dass die aktive Entwicklung in einem anderen Repository stattfindet, das verlinkte enthält allerdings die fertigen Releases mit den Assemblies.

Da wir die VM nur zu Entwicklungszwecken nutzen ist es okay sich ein pre-release herunterzuladen. Im Optimalfall ist die lokale Entwicklungsumgebung jedoch so nah am Produktionssystem wie möglich, um etwaige umgebungsbedingte Fehler zu minimieren. 

Auf der Releases-Seite kann zum Beispiel das Archiv OpenSSH-Win64.zip heruntergeladen werden. Dieser Ordner kann an eine beliebige Stelle geschoben werden, zum Beispiel nach C:\OpenSSH. Entpackt sollte es dann wie folgt aussehen:

Microsoft war so nett und hat dem OpenSSH Release auch ein paar PowerShell-Scripts beigefügt, um den Server zu installieren.

Die Befehle gibt es hier noch einmal in Textform

$ cd C:\OpenSSH\
$ .\install-sshd.ps1

Das PowerShell-Script install-sshd.ps1 sollte auch einen Service erstellt haben, den wir jetzt noch konfigurieren und starten müssen. Dazu im Windows-Server einmal die Services starten und nach dem Service mit dem Namen OpenSSH SSH Server suchen. Per Rechtsklick Properties auswählen und den Startup type auf Automatic setzen und den Service anschließend starten.
 

Port 22 freigeben

Windows Firewall

Um von außen auf den Port 22 (was der default port für ssh ist) zugreifen zu können, müssen wir diesen Port noch in der Firewall freigeben. Dafür muss in der Firewall eine neue EINGEHENDE Regel erstellt werden, die für TCP den Port 22 freigibt. 

VirtualBox VM

Falls der Windows Server nicht in einer VM laufen sollte, kann dieser Schritt übersprungen werden. Alle anderen müssen in der VirtualBox VM den Port 22 freigeben, damit er nach Windows durchgereicht werden kann wie hier in einer wunderschönen Grafik zu erkennen.

Zum Testen kann nun per Shell - ob WSL, PowerShell oder sonstiges ist egal - getestet werden ob per ssh username@localhost auf den Server zugegriffen werden kann.
 

Rider für Remote Debugging einstellen

Um nun auch von Rider aus debuggen zu können müssen wir den Remote Debug Server einrichten. Dafür in die Settings unter File | Settings | Build, Execution, Deployment | Debugger | Remote debug einen neuen Server

Wenn das nun getan ist, muss einmal über die Navigation auf Run | Attach to remote process geklickt werden und ein Fenster mit einer Liste von den konfigurierten Servern sollte aufgehen. Wählt man nun den eben konfigurierten Server, wird nach dem Fingerprint gefragt. Diesen Request kann man bestätigen, wenn man sicher ist, dass die dort angezeigten Informationen in Ordnung sind. JetBrains Rider wird außerdem vorschlagen die Remote Debug Tools auf dem Server zu installieren installieren, sodass - nachdem alles eingerichtet wurde - ihr eine Liste von möglichen Prozessen, an die sich Rider hängen kann, angezeigt bekommt.

Ran ans debuggen!

Nachdem wir nun also den SSH Server, die Firewall, die Portfreigabe UND Rider konfiguriert haben, können wir uns nun endlich ans debuggen machen! Dafür muss in Rider wie oben beschrieben der Prozess attached werden. Wichtig ist, dass wenn der Prozess abgeschossen wird, der Prozess neu attached werden muss. Dies ist zum Beispiel bei RenderTags der Fall, da der ObjectProcessService neugestartet werden muss um die Tags neu einzulesen.

In Rider kann nun an einer beliebigen Stelle in der IDE ein Breakpoint gesetzt werden. Wird im WSM jetzt Code ausgeführt, der mit der Zeile des Quellcodes übereinstimmt und über den Breakpoint läuft hat man sein gewohntes UI zum Debuggen.

Abschlussinformation

Ich hoffe, dass der Artikel hilfreich war und Entwickler anspricht, die entweder gerne mal eine alternative IDE zu Visual Studio testen möchten, oder die zwar gerne Rider nutzen würden, es aber wegen nicht konfiguriertem SSH Server nie testen konnten.