In letzter Zeit habe ich an der Entwicklung einiger Erweiterungen für Visual Studio Team Services (VSTS) gearbeitet. Die Möglichkeit, benutzerdefinierte Erweiterungen zu entwickeln, ist großartig, denn sie ermöglicht es Ihnen, den Dienst um Funktionen zu erweitern, die Ihren Bedürfnissen entsprechen.
Die Erstellung einer Erweiterung für VSTS besteht aus ein paar Schritten:
- Entwickeln Sie den Code
- Verpacken Sie die Erweiterung
- Veröffentlichen Sie es auf dem Marktplatz
- Installieren Sie es in Ihrem VSTS-Konto
- Nutzen Sie Ihre Erweiterung!
Um Ihre Erweiterung innerhalb von VSTS verwenden zu können, müssen Sie all diese Schritte durchlaufen. Wenn Sie noch dabei sind, Ihren Code zu entwickeln und zu debuggen, ist das ein sehr mühsamer Prozess. Es gibt einen netten kleinen Trick, mit dem Sie dies umgehen können und der das Debuggen einer VSTS-Erweiterung sehr viel einfacher macht. Er ist zwar irgendwo in der Dokumentation beschrieben, aber er ist sehr gut versteckt, so dass ich dachte, ich schreibe einen Blogbeitrag darüber.
Wie Erweiterungen funktionieren
Erweiterungen für die VSTS-Weboberfläche sind eigentlich Webseiten, die innerhalb eines Iframe in der VSTS-Benutzeroberfläche geladen werden. VSTS unterstützt viele Erweiterungspunkte, und Sie können denjenigen verwenden, der für Ihren Zweck am besten geeignet ist. Zum Beispiel eine zusätzliche Registerkarte auf dem Workitem-Formular, ein Dashboard-Widget, eine zusätzliche Hub-Gruppe oder sogar ein ganzes Hub. Wenn VSTS die HTML-Seite für Ihre Erweiterung lädt, wird sie in der Benutzeroberfläche sichtbar. Innerhalb Ihrer HTML-Seite binden Sie das SDK für die VSTS-Erweiterung ein ("VSS.SDK.js"). Dieses sorgt für das ordnungsgemäße Laden Ihrer Erweiterung innerhalb der VSTS-Benutzeroberfläche und stellt Ihrer Erweiterung einige Dienste zur Verfügung, um Daten von und zu VSTS zu erhalten. Um das Ganze in ein Bild zu fassen:
Damit Ihre Erweiterung in VSTS geladen werden kann, muss VSTS einige Dinge über sie wissen, z.B. wo Ihre Erweiterung geladen werden soll (z.B. als Dashboard-Widget oder Hub-Gruppe), welche HTML-Seite geladen werden soll und welche Berechtigungen erforderlich sind. Diese Dinge werden in Ihrem Erweiterungsmanifest konfiguriert. Dieses Manifest wird beim Verpacken und Veröffentlichen Ihrer Erweiterung auf dem Marktplatz verwendet. Von dort aus kann sie dann in Ihrem VSTS-Konto installiert werden.
Das Manifest gibt auch an, von wo aus Ihre Erweiterung html geladen werden soll. Wenn Sie eine einfache Erweiterung mit nur ein paar statischen HTML-/Javascript-/Css-Dateien haben, können Sie diese mit Ihrer Erweiterung verpacken und sie werden innerhalb von VSTS gehostet. Wenn Ihre Erweiterung komplexer ist (z.B. wenn Sie einige ASP.NET-Seiten haben), müssen Sie Ihr eigenes Hosting bereitstellen und dies in Ihrem Manifest angeben.
Vorbereiten der Fehlersuche
Wenn ich eine Erweiterung entwickle, verwende ich Visual Studio. Natürlich möchte ich alle Debugging-Möglichkeiten von Visual Studio nutzen und schnelle Iterationen durchführen können (Code schreiben, F5 drücken, prüfen, ob er funktioniert). Damit das funktioniert, müssen wir VSTS dazu bringen, unsere Erweiterung html von unserem lokalen Rechner zu laden. Das funktioniert natürlich nicht in einem Produktionsszenario, aber zum Debuggen ist es fantastisch.
Zu diesem Zweck erstellen wir ein spezielles Manifest für die Entwicklung (in meinem Fall: "vss-extension-debug.json"). In diesem Manifest gibt es ein paar Eigenschaften, die wir speziell für Debugging-Zwecke ändern werden:
{
...,
"id": "devdemoextension",
"Name": "Dev: Demo Extension",
"baseUri": "https://localhost:44300",
...
}
- id: Die id muss für alle Ihre Erweiterungen eindeutig sein. Ich stelle normalerweise "dev" für meine Entwicklungsversionen voran.
- Name: Dieser Name wird im VSTS-Marktplatz angezeigt und wenn Sie die Erweiterung in Ihrem Konto installieren. Ich stelle normalerweise "Dev:" voran, damit ich die Entwicklungsversion identifizieren kann.
- baseUri: Hier geschieht die Magie. Damit wird VSTS angewiesen, die Erweiterung von Ihrem lokalen Host zu laden, auf dem Ihre Entwicklungsversion in IISExpress von Visual Studio aus läuft.
Hinweis: Sie müssen IISExpress im SSL-Modus ausführen, da VSTS verlangt, dass Ihre Erweiterung von einer sicheren Quelle bereitgestellt wird. Sie können den SSL-Modus in den Eigenschaften Ihres Projekts in Visual Studio aktivieren:
Verpacken Sie nun Ihre Erweiterung unter Verwendung des für die Fehlersuche geänderten Manifests:
vset package -m vss-extension-debug.json
Laden Sie die resultierende .vsix-Datei auf den Marktplatz hoch und teilen und installieren Sie sie in Ihrem Konto. Eine Anleitung dazu finden Sie auf der Visual Studio-Website.
Die Fehlersuche durchführen
Nun, da wir die Yak-Rasur hinter uns haben, können wir mit dem eigentlichen Debugging beginnen. Am einfachsten geht das, indem Sie die Eigenschaften Ihres Projekts in Visual Studio ändern und die Start-URL auf den Ort setzen, an dem Ihre Erweiterung geladen wird:
Damit stellen Sie sicher, dass der Debugger mit dem richtigen Browser-Prozess verbunden ist.
Drücken Sie nun F5 und Sie können die volle Leistung des Visual Studio Debugger nutzen!
Viel Spaß beim Debuggen!
Verfasst von

Kees Verhaar
Welcome to my blog! I am an ALM consultant for Xpirit Netherlands B.V. Sounds fancy, doesn’t it? Basically it means I help people to do their work as a software engineer better, faster and easier. In the past couple of years of working in the field, I have encountered many things of which I thought: “I should share this!â€. This blog is my way of doing that. You’ll find real life stories, tips & tricks, examples and probably even some code here. Hope you enjoy! If you have any suggestions, please feel free to drop me a line.
Contact