Ersetzen von Webparts in Sandboxlösungen
Einer der Gründe, warum viele Entwickler codebasierte Sandboxlösungen genutzt haben, ist der Wunsch, visuelle Webparts zu verwenden. Dies bietet eine hervorragende Möglichkeit, Code vom Layout zu trennen und die ASP.NET-Steuerelemente zu nutzen. Sie können weiterhin visuelle Webparts in einem vom Anbieter gehosteten Add-In über Clientwebparts verwenden. Dies ist ein hervorragender Ansatz und bietet einen direkten Migrationspfad für viele Anwendungen.
Eine weitere Möglichkeit besteht darin, das Webpart als clientseitige Lösung neu zu schreiben. Dies umfasst die Neugestaltung der Lösung für die Verwendung von JavaScript, HTML-Fragmenten und mindestens einem unterstützenden Framework. Obwohl dies neue Arbeit ist, hat es den zusätzlichen Vorteil, dass Sie Ihre Lösung so einrichten, dass sie problemlos in die bevorstehenden SharePoint-Framework integriert werden kann. Dies ist eine gute Wahl für einfache Anzeige- oder Dateneingabe-Webparts und kann auf ganzseitige Clientanwendungen skaliert werden.
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.
Optionen zum Ersetzen von Webparts
Ansatz | Überlegungen zum Entwurf und weitere Informationen |
---|---|
Vom Anbieter gehostetes Add-In-Clientwebpart |
|
Clientseitige Lösung |
|
Entfernen von Sandkastencode von Ihrer Website
Wenn Sie Ihre vorhandene Sandboxlösung von Ihren Websites deaktivieren, werden alle Ressourcen oder Dateien, die mithilfe deklarativer Optionen bereitgestellt werden, nicht entfernt. Die Features in der Sandboxlösung werden jedoch automatisch deaktiviert, und der Ereignisempfänger wird entfernt.