SharePoint Framework SPFx Entwicklung - Versionen & Docker
Das SharePoint Framework (kurz: SPFx), das im Jahr 2017 offiziell mit der ersten Version 1.0 eingeführt wurde, ermöglicht die Realisierung reiner clientseitigen SharePoint Erweiterungen. Damit hat es Microsoft final geschafft, Lösungen für den Microsoft SharePoint Server umzusetzen, die in keiner Art und Weise direkten serverseitigen Code ausführen.´
SharePoint kann auf vielfältige Art und Weise um eigene Funktionen erweitertet werden. Die Möglichkeiten und Methodiken für die spezifische Erweiterungen haben sich im Laufe der SharePoint Versionen laufend geändert. Erweiterungen im Sinne sog. Farmlösungen, die auf serverbasierte Technologien - wie .NET C# oder auch VB.NET basieren - sind schon lange mögliche. Die serverseitige Ausführung von Farmlösungen im SharePoint Prozessraum (konkret im IIS-Workerprozess / W3WP.exe) birgt allerdings immer die Gefahr, das eigene Erweiterungen durch einen Fehler (Bug), die gesamte SharePoint Farm negativ beeinflussen. Ebenso ist die Bereitstellung von Farmlösungen oft mit einem SharePoint Farm-Unterbruch (Server-Downtime) verbunden. Dieser Umstand hat sich zwar mit der aktuellen SharePoint Version verbessert, aber je nach Farmlösungstyp und Farmstruktur kann es noch zu Unterbrechungen kommen. Um diese Probleme zu beheben, führte Microsoft die sog. Sandkastenlösungen ein. Sandkastenlösungen, die im SharePoint User Code Solution Arbeitsprozess (SPUCWorkerProcess.exe) gehostet werden, führen Code aus, der sich nur auf die Websitesammlung der Lösung auswirken kann. Da Sandkastenlösungen nicht direkt im IIS-Arbeitsprozess ausgeführt werden, müssen weder der IIS-Anwendungspool noch der IIS-Server neu gestartet werden. Die Realisierung und Bereitstellung von solchen Sandkastenlösungen ist allerdings aufwendiger, so dass viele Entwickler weiterhin Farmlösungen realisieren. Im nächsten Schritt wurde SharePoint um ein App-Modell, bezeichnet als „SharePoint Add-Ins“, ergänzt (siehe SharePoint Add-Ins). Unterschieden werden dabei die möglichen Add-In Typen in SharePoint-hosted und provider-hosted. Ein SharePoint-Add-In ist dabei eine eigenständige Funktion, die die Funktionen von SharePoint-Websites erweitert, um ein klar definiertes Geschäftsproblem zu lösen. Serverseitige Code ist bei diesem Erweiterungsmodell auch möglich, dieser wird aber nicht mehr auf dem SharePoint Server ausgeführt. Schlussendlich wurde mit dem SPFx-Framework ein einfacheres Modell eingeführt, um SharePoint zu erweitern. Das SharePoint Framework (SPFx) ist ein Seiten- und Webpart-Modell, das vollständige Unterstützung für die clientseitige SharePoint-Entwicklung, einfache Integration in SharePoint-Daten und Erweiterung von Microsoft Teams bietet. Das SPFx-Framework stellt aktuell das empfohlene SharePoint-Anpassung- und Erweiterbarkeitsmodell für die Entwicklung von modernen SharePoint Erweiterungen dar. Neben SharePoint können ebenfalls die Produkte Microsoft Teams und Microsoft Viva Connections erweitert werden. SPFx Lösungen können für SharePoint online sowie auch für lokale SharePoint Farmen realisiert und bereitgestellt werden
Viele Versionen - Herausforderung für Entwickler
Ein wesentlicher Nachteil der SPFx basierten Entwicklung liegt allerdings in den kurzen Release-Zyklen der eingesetzten Laufzeitumgebungen und Bibliotheken. Die SPFx basierte Entwicklung ist im Wesentlichen von den folgenden Tools und Bibliotheken abhängig:
- Node.js (LTS)
- NPM
- TypeScript
- React
| SPFx | Node.js (LTS) | NPM | TypeScript | React |
|---|---|---|---|---|
| 1.16.0 | v16.13 und höher | v5, v6, v7, v8 | v4.5 | v17.0.1 |
| 1.15.2 | v12, v14, v16 | v5, v6, v7, v8 | v4.5 | v16.13.1 |
| 1.15.0 | v12, v14, v16 | v5, v6, v7, v8 | v4.5 | v16.13.1 |
| 1.14.0 | v12, v14 | v5, v6 | v3.9 | v16.13.1 |
| 1.13.1 | v12, v14 | v5, v6 | v3.9 | v16.13.1 |
| 1.13.0 | v12, v14 | v5, v6 | v3.9 | v16.13.1 |
| 1.12.1 | v10, v12, v14 | v5, v6 | v3.7 | v16.9.0 |
Die vollständige Liste ist hier zu finden: Kompatibilität von Entwicklungstools und Bibliotheken für das SharePoint-Framework
Wie aus der Tabelle hervorgeht, ändern sich die Versionen ständig. Zudem ist zu beachten, dass nicht immer die neueste Version des SPFx-Framework eingesetzt werden kann. Je nach Zielplattform muss die richtige SPFx-Version gewählt werden. Für die Entscheidungshilfe gibt die nachfolgende Tabelle Auskunft:
| SharePoint-Version | Unterstützte SPFx-Version | Unterstützte Features |
|---|---|---|
| SharePoint Online | Alle Versionen | Alle Funktionen |
| SharePoint Server-Abonnementedition | v 1.4.1 oder niedriger | SPFx-clientseitige Webparts auf klassischen und modernen Seiten sowie Erweiterungen auf modernen Seiten. |
| SharePoint Server 2019 | v 1.4.1 oder niedriger | SPFx-clientseitige Webparts auf klassischen und modernen Seiten sowie Erweiterungen auf modernen Seiten. |
| SharePoint 2016 Feature Pack 2 | v1.1 | SPFx-clientseitige Webparts, die auf klassischen SharePoint-Seiten gehostet werden. |
Siehe auch: Kompatibilität von SharePoint Framework-Versionen
Wenn eine Lösung ausschließlich für SharePoint Online ausgelegt ist, dann kann immer das neueste SPFx-Framework verwendet werden. Ansonsten ist die Version einzusetzen, die aktuell für eine bestimmte Plattform von Microsoft zugelassen ist.
Entwicklungsumgebung
Um herauszufinden welche Versionen aktuell auf der Entwicklermaschine installiert sind, kann das folgende Kommando verwendet werden:
npm ls -g --depth=0
Dieses zeigt die installierten Versionen an. Das Tool @microsoft/generator-sharepoint zeigt dabei die Version der installierten SPFx-Version an.
Für den Entwickler von SPFx-basierten Lösungen ergibt sich durch die zahlreichen Versionen Probleme. Müssen zum Beispiel Lösungen für mehrere Kunden verwaltet werden oder Lösungen für SharePoint Online und SharePoint Server bereitgestellt werden, so müssen verschiedene Versionen der oben gelisteten Tools und Bibliotheken verfügbar sein. Dies ist aber nicht immer möglich, da einige Tools nicht in unterschiedlichen Versionen einfach auf einer Maschine parallel installiert werden können. Eine Variante besteht dann in dem Einsatz einer virtuellen Maschine. Dazu kann zum Beispiel ein Hyper-V Datenträgerabbild (Image) als Basis - ohne SPFx-Framework Komponenten - vorbereitet werden. Anschließend kann dieses Image immer als Ausgangsbasis für eine neue virtuelle Maschine verwendet werden. Auf dieser kann dann ein bestimmtes SPFx-Framework installiert werden.
Der Einsatz einer VM für die Entwicklung unter SharePoint Server On-Premise ist ein gängiges Vorgehen. Die Verwendung einer virtuellen Maschine für jede mögliche Umgebung löst auch hier das Problem und es stehen unterschiedliche SPFx-Entwicklungsumgebungen bereit. Jedoch benötigen VM's eine Menge an Ressourcen und zudem muss das Betriebssystem verwaltet und auch ständig mit Updates versorgt werden.
Docker
Für eine rein clientseitige Entwicklung und zur Beseitigung der Versionskonflikte eignet sich für SPFx-Framework Lösungen eher eine reduzierte virtuelle Umgebung mittels Docker. Im Gegensatz zu klassischen virtuellen Computern oder Servern, stellt ein Docker Image nur eine benötigte Laufzeitumgebung bereit und nutzt das bereits installierte Betriebssystem der Host-Maschine. Somit entfällt unter Docker die Bereitstellung und Wartung eines gesamten Rechners und natürlich benötigt ein Docker Datenträgerabbild auch nicht so viele Ressourcen wie eine VM. Auch ist der gesamte Speicherplatzbedarf erheblich reduziert, dass auch die Weitergabe an andere Entwickler erheblich erleichtert.
Für das SPFx-Framework stehen auch schon einsatzbereite Docker-Datenträgerabbilder zum Einsatz bereit. Mittlerweile existiert auch für jede SPFx-Framework Version ein direkt einsatzfähiges Image:
Docker Images für das SharePoint Framework
Die Verwendung der Images ist nicht kompliziert. Nachfolgend exemplarisch die durchzuführenden Schritte:
- Installation und Einrichtung Docker falls noch nicht vorhanden
- Sicherstellen, dass das Laufwerk mit dem Projektverzeichnis (siehe nächster Schritt) als freigegebenes (shared) eingerichtet ist. Dieser Schritt entfällt, wenn man Docker mit der Einstellung Use the WSL 2 based Engine betreibt.
- Anlage eines Projektverzeichnisses für das SPFx-Framework Projekt
- Je nach verwendeten Docker-Image (siehe nächsten Punkt) existieren teilweise Beschränkungen bzw. bekannte Probleme. Daher sollte immer auf der Seite Alle Docker Images für SPFx am Ende geprüft werden, ob die eingesetzte Version zusätzliche Einstellungen benötigt. So wird bei der SharePoint Framework Version ab 1.14.0 noch folgender Eintrag in der serve.json benötigt:
ipAddress": "0.0.0.0"
Ansonsten gibt es Probleme bei Zugriff auf die lokale Workbench. - Starten des Docker-Images über folgendes Kommando:
docker run -it --rm --name [NAME] -v ${PWD}:/usr/app/spfx -p 4321:4321 -p 35729:35729 m365pnp/spfx
Die Parameter bedeuten hierbei folgendes
it für "interactive": Image wird im Terminal gestartet und man verbleibt im Prozess
rm für "remove": Container wird nach Verwendung gelöscht
v für "Volume": Mapping des Laufwerks
p für "Port": Umleitung der Ports vom Docker Container zum Host
Der letzte Parameter stellt den Namen des gewünschten Images dar. In diesem Fall die letzte verfügbare Image Version - Installation des Entwickler-Zertifikats (virtuell&lokal)
- Start der Entwicklung und Anlage eines Projektes via: yo @microsoft/sharepoint
Wurde der Projektrahmen erstellt, kann das Projekt über gulp serve --nobrowser gestartet werden. Der Testsite unter SharePoint Online kann dann der folgende QueryString Parameter angehängt werden:
?debug=true&noredir=true&debugManifestsFile=https://localhost:4321/temp/manifests.js
Dieser lädt dann die Komponente und das WebPart kann der Seite zum Testen hinzugefügt werden. Der nachfolgende Screenshot zeigt ein geladenes neues WebPart, welches über Docker bereitgestellt wird.
Kommentare