Freigeben über

Transformieren von Sandkastenlösungen mit dem SharePoint-Add-In-Modell

  • Artikel

Zum Transformieren Ihrer Sandkastenlösungen in das SharePoint-Add-In-Modell gehört das Analysieren vorhandener Erweiterungen, das Entwerfen und Entwickeln Ihrer neuen SharePoint-Add-Ins sowie das Testen und Bereitstellen Ihres Add-Ins in Ihrer Produktionsumgebung.

Hinweis

Codebasierte Sandkastenlösungen sind seit 2014 veraltet, und in SharePoint Online wird diese Funktion Zug um Zug vollständig entfernt. Codebasierte Sandkastenlösungen sind auch in SharePoint 2013 und SharePoint 2016 veraltet.

Codebasierte Sandkastenlösungen in SharePoint Online

Sandkastenlösungen sind Anpassungspakete, die zum Bereitstellen von Anpassungen für SharePoint auf der Ebene der Websitesammlung verwendet werden können. Wenn eine Sandkastenlösung Code enthält, wurde dieser in einem speziellen isolierten Prozess mit einem begrenzten Satz APIs ausgeführt, um auf SharePoint-Dienste und -Inhalte zuzugreifen.

Es gibt zwei Arten von Sandkastenlösungen:

  • Codebasierte Sandkastenlösungen, die eine benutzerdefinierte Assembly im Paket enthalten.
  • Deklarative Sandkastenlösungen, die nur XML-basierte Konfigurationen und zugehörige Objekte enthalten.

Deklarative (XML-basierte) Sandkastenlösungen können basierend auf ihren Anwendungsfällen weiter in die folgenden Typen unterteilt werden:

  • Websitevorlage – Generiert mithilfe der Funktion „Diese Website als Vorlage speichern“ auf vorhandenen Websites.
  • Designpaket – Generiert unter Verwendung des Entwurfs-Managers auf der Veröffentlichungswebsite.
  • Benutzerdefinierte Sandkastenlösungen – Generiert in Visual Studio, z. B. für Branding-Objekte; enthält keine Assemblys.

Codebasierte Sandbox-Lösungen können basierend auf ihren Anwendungsfällen weiter in die folgenden Typen unterteilt werden:

  • Deklarative Sandkastenlösung mit leere Assembly
  • Sandkastenlösung mit InfoPath-Formular mit Code
  • Codebasierte Sandkastenlösungen mit Anpassungen z. B. Webparts, Ereignisempfänger und/oder Funktionsempfänger.
  • Sandkastenlösungen mit benutzerdefinierter Workflowaktion

Wenn Sie beabsichtigen, sich von Sandkastenlösungen weg zu bewegen, sollten Sie die funktionalen und geschäftlichen Anforderungen einer bestimmten Lösung auswerten und die künftige Designrichtung basierend darauf ermitteln.

Planen des Prozesses der Seitentransformation

Wenn Sie Sandkastenlösungen in das SharePoint-Add-In-Modell transformieren, sollten Sie sicherstellen, dass die Auswirkungen auf die Benutzer minimal sind. Analysieren Sie Ihre aktuellen Sandkastenlösungen sorgfältig, und entwerfen Sie dann Ihr neues SharePoint-Add-In so, dass die Anforderungen Ihrer Organisation erfüllt werden. Wir empfehlen den folgenden Prozess, um eine erfolgreiche Transformation sicherzustellen.

Bereitschaft

Informieren Sie sich über folgende Themen:

Bewertung der Lösung

Analysieren Sie die funktionalen und geschäftlichen Anforderungen, indem Sie:

  • Bereitgestellte Sandkastenlösungen in Ihrer aktuellen Umgebung identifizieren; hierfür können Sie eines der folgenden als Open Source bereitgestellten Tools vom SharePoint-PnP-Team verwenden:

  • Die Anforderungen mit Ihren Benutzern überprüfen. Bitten Sie Ihre Benutzer, Ihnen zu zeigen, wie sie die vorhandenen Sandkastenlösungen bei ihrer täglichen Arbeit verwenden.

  • Neue Funktionen identifizieren, dokumentieren und entwerfen, die in das neue SharePoint-Add-In eingeschlossen werden. Überprüfen Sie Ihre Liste neuer Featureanfragen von Benutzern, um weitere Ideen zu erhalten.

  • Nicht genutzte Features identifizieren und mit Ihren Benutzern vereinbaren, diese Funktion im neuen SharePoint-Add-In wegzulassen.

  • Legen Sie für jede Lösung fest, ob sie durch ein SharePoint-Add-In ersetzt oder implementiert werden soll, indem Sie sofort einsatzbereite Funktionen oder eine alternative Lösung verwenden.

Lösungsplanung

Entwerfen Sie mithilfe des SharePoint-Add-In-Modells die neue Anwendung basierend auf Folgendem:

  • Den im Schritt Bewertung der Lösung gesammelten Anforderungen.

  • Der Analyse des vorhandenen Codes. Bei der Codeanalyse sollten Sie Codeabschnitte identifizieren, die gelöscht werden können (weil der Code beispielsweise nicht mehr verwendet wird oder sich die Anforderungen geändert haben).

Entwickeln und Testen der Version des SharePoint-Add-In-Modells Ihrer Anwendung

Dies ist in der Regel der zeitaufwändigste Schritt beim Transformationsprozess.

Bereitstellen Ihres neuen Add-Ins

Stellen Sie sicher, dass Ihre Bereitstellung stabil ist, und senden Sie Ihren Benutzern entsprechende Mitteilungen.

Ersetzen von Anpassungen von Sandkastenlösungen

Nachfolgend finden Sie typische Anpassungen, die in Sandkastenlösungen enthalten sind, sowie mögliche Transformationsoptionen. Wir planen, weitere Informationen für jeden Anpassungstyp hinzuzufügen, damit Sie reale Beispiele für die Transformationsoptionen erhalten.

Anpassung Transformationsoptionen
Deklarative Lösung mit leerer Assembly

Sie können die Assemblyerstellung aus den Projekteigenschaften der Visual Studio-Lösung steuern. Weitere Informationen erhalten Sie unter Entfernen des Assemblyverweises aus der in Visual Studio erstellten Sandkastenlösung.



Wichtig: Wenn Sie den Scanner für SharePoint-Sandkastenlösungen verwenden, wird in der Scannerausgabe aufgeführt, welche Lösungen eine leere Assembly haben, und das Tool erstellt aktualisierte Sandkastenlösungspakete für Sie, in denen die Assembly gelöscht wurde. Sie können die vorhandene Sandkastenlösung dann einfach durch die aktualisierte ersetzen.
InfoPath-Formular mit Code

Wenn Sie ein InfoPath-Formular vom InfoPath-Client veröffentlicht haben, das Code enthält, so wird dieses tatsächlich als Sandkastenlösung in SharePoint veröffentlicht. Dies bedeutet, dass der Formularcode tatsächlich vom Sandkastenmodul in SharePoint ausgeführt wird.

Wenn Sie die codebasierten InfoPath-Formulare nicht mehr verwenden möchten, ist dies von dem tatsächliche Anwendungsfall abhängig. Es gibt mehrere Optionen, vom Generieren benutzerdefinierter UI als Add-In bis hin zur Verwendung anderer Formulartechniken.

Weitere Informationen finden Sie unter Korrigieren von InfoPath in Sandkastenlösungen.
Webpart

Webparts werden in der Regel entweder in Add-In-Parts konvertiert, oder sie werden mit vollständig clientseitigen Technologien mithilfe des JavaScript-Einbettungsmusters implementiert.

Weitere Informationen finden Sie unter:
Visuelles Webpart

Visuelle Webparts werden auf ähnliche Weise wie normale Webparts transformiert. Benutzersteuerelemente, die in visuellen Webparts verwendet werden, müssen ersetzt werden, da diese im Falle von Sandkastenlösungen in der Assembly enthalten sind.
Ereignisempfänger

Ereignisempfänger können in vielen Fällen durch die Implementierung des Remoteereignisempfängers ersetzt werden. Remoteereignisempfänger müssen aber auf einer Plattform gehostet werden, in der Regel auf bestimmten vom Anbieter gehosteten Add-Ins.

Weitere Informationen finden Sie unter:
Funktionsempfänger

Funktionsempfänger werden in der Regel durch einen auf einer Remote-API basierenden Vorgang ersetzt, z. B. die Verwendung von CSOM oder REST zum Anwenden der erforderlichen Anpassung oder Konfiguration auf der Websiteebene. Wenn eine erforderliche API in den Remote-APIs (CSOM/REST) fehlt, melden Sie diese Lücke über SharePoint UserVoice.

Funktionsempfänger werden beispielsweise verwendet, um eine benutzerdefinierte Masterseite oder ein Design auf eine Website anzuwenden, wenn diese aktiviert sind. Diese Art von Vorgängen kann problemlos durch auf Remotecode basierenden Lösungen oder mithilfe von PnP PowerShell ersetzt werden, was einfache Befehle zum Steuern der Websitekonfiguration enthält.
Benutzerdefinierte Workflowaktion

Der typische Migrationspfad für diese Art von Anpassungen besteht darin, SharePoint-Workflows oder alternative Lösungen wie Microsoft Flow oder Drittanbieterlösungen zu verwenden.

Entfernen von Sandkastencode von Ihrer Website

Wenn Sie Ihre vorhandene Sandkastenlösung auf Websites deaktivieren, werden Objekte oder Dateien, die mithilfe deklarativer Optionen bereitgestellt wurden, nicht entfernt. Wenn Sie Sandkastenlösungen verwendet haben, um neue codebasierte Webparts einzuführen, werden diese Funktionen auf den Websites deaktiviert. Dies bedeutet, dass die Seiten immer noch normal gerendert werden, es aber keine direkten Auswirkungen auf den Endbenutzer gibt, wenn die Lösung deaktiviert wird, abgesehen davon, dass codebasierte Funktionen wie Webparts deaktiviert werden.

Entfernen der Unterstützung für codebasierte Sandkastenlösungen

Die Unterstützung codebasierter Sandkastenlösungen wird in SharePoint Online entfernt, indem codebasierte Vorgänge deaktiviert werden, die von Code ausgeführt werden, der auf Sandkastenlösungen basiert. Dies bedeutet, dass Ihre Sandkastenlösungen nicht explizit im Lösungsspeicher deaktiviert werden, es werden aber keine codebasierten Vorgänge mehr ausgeführt. Sandkastenlösungen verbleiben im Lösungskatalog im aktivierten Status. Features, die mit Sandkastenlösungen bereitgestellt wurden, werden nicht automatisch deaktiviert, was bedeutet, dass Code, der mit der Featuredeaktivierung verknüpft ist, oder Deinstallationshandler nicht ausgeführt werden.

Alle deklarativen Definitionen in der Sandkastenlösung funktionieren weiter, nachdem diese Änderung in SharePoint Online angewendet wurde.

Inhalt dieses Abschnitts

Siehe auch