Architektur von Sandkastenlösungen

In diesem Thema wird die Architektur eines Sandkastenlösungssystems in SharePoint vorgestellt.

Letzte Änderung: Donnerstag, 14. April 2011

Gilt für: SharePoint Foundation 2010

Inhalt dieses Artikels
Übersicht
Pack- und Installationssystem für Sandkastenlösungen
Prozessmodell für Sandkastenlösungen
Codeausführung und Ressourcenzugriff im Sandkasten-Arbeitsprozess
Einschränkungen für Sandkastenlösungen bei der Ressourcenverwendung
Rendersystem für aufgeteilte Seiten
Umgehen der für Sandkastenlösungen geltenden Einschränkungen
Das Framework für die Lösungsüberprüfung

Verfügbar in SharePoint Online

Sie finden Beschreibungen des Packsystems, des Verarbeitungsmodells, des Rendersystems für aufgeteilte Seiten, der Einschränkungen bei der Ressourcenverwendung, der Codeausführung und Zugriffsbeschränkungen sowie des Frameworks zur Lösungsüberprüfung. Details zu diesen Punkten finden Sie in anderen Themen im Knoten Sandkastenlösungen des SDK.

Übersicht

Eine Lösung mit eingeschränkter Sicherheitsstufe ermöglicht Websitesammlungsadministratoren im Gegensatz zu einer Farmlösung die Installation benutzerdefinierter Lösungen in Microsoft SharePoint Foundation, ohne dass ein übergeordneter Administrator hinzugezogen worden muss. Diese Flexibilität erfordert jedoch, dass Sandkastenlösungen dahingehend eingeschränkt werden müssen, welche Funktionalität sie bereitstellen, welchen Code sie ausführen und auf welche Ressourcen sie zugreifen können.

Hinweis

Der Begriff "User" (Benutzer) wird mitunter anstelle von "Sandbox" (Sandkasten) verwendet, insbesondere im Objektmodell des Sandkastenlösungssystems. Der Namespace mit den primären APIs für das System heißt beispielsweise Microsoft.SharePoint.UserCode, und der Dienst, der die Ausführung der Sandkastenlösung steuert, heißt im Windows-Dialogfeld Dienste auf Front-End-Webservern SharePoint 2010 User Code Host. (In der Zentraladministration lautet der Name SharePoint Foundation-Sandkasten-Codedienst.) Dies bezieht sich auf einen früheren Namen von Lösungen, die nun als "Sandkastenlösungen" bezeichnet werden.

Pack- und Installationssystem für Sandkastenlösungen

Wie eine Farmlösung ist eine Sandkastenlösung für die Installation in einer Lösungspaketdatei (.wsp) gepackt. Anstatt im Lösungsspeicher der Farm werden Sandkastenlösungen jedoch vom Websitesammlungsadministrator in einem für die Websitesammlung spezifischen Lösungskatalog bereitgestellt. Der Katalog ist eine spezielle SharePoint-Liste, die deshalb in der Inhaltsdatenbank enthalten ist. Die Bereitstellung von Lösungen im Katalog erfolgt über den Menübefehl Websiteaktionen für die Websitesammlung oder die SharePoint-Verwaltungsshell. Weitere Informationen zum Installationsprozess von Sandkastenlösungen finden Sie unter Installieren, Deinstallieren und Upgraden von Sandkastenlösungen.

Die Typen von Elementen von Sandkastenlösungen und deren Bereitstellung unterliegen Einschränkungen. So können keine Elemente aus einer Sandkastenlösung auf den Dateisystemen der Server bereitgestellt werden. Diese Einschränkung hat mehrere Auswirkungen:

• Anwendungsseiten, Benutzersteuerelemente (.ascx-Dateien) und Ressourcendateien für die Lokalisierung (.resx-Dateien) können nicht mithilfe einer Sandkastenlösung bereitgestellt werden. (Es gibt allerdings andere Möglichkeiten zum Lokalisieren von Sandkastenlösungen. Weitere Informationen finden Sie unter Lokalisierung von Sandkastenlösungen)

• Bilder, Skriptdateien und Features in Sandkastenlösungen werden in der Inhaltsdatenbank und nicht im Dateisystem der Front-End-Server bereitgestellt.

• Websitedefinitionen können in Sandkastenlösungen nicht bereitgestellt werden, Webvorlagen (die funktionell vergleichbar sind) hingegen schon. Weitere Informationen finden Sie unter How to: Deploy a Web Template in a Sandboxed Solution.

• Assemblys in Sandkastenlösungen werden ebenfalls in der Inhaltsdatenbank bereitgestellt. Doch bei ihrer Verwendung werden sie vorübergehend im Dateisystem des Servers zwischengespeichert, der die Anforderung verarbeitet. Weitere Informationen finden Sie unter Wo werden Assemblys in Sandkastenlösungen bereitgestellt?.

Eine vollständigere Darstellung dessen, was in einer Sandkastenlösung bereitgestellt werden kann, finden Sie unter Möglichkeiten und Einschränkungen von Sandkastenlösungen.

Eine Sandkastenlösung darf auch auf keine Elemente außerhalb der Websitesammlung zugreifen, in der sie bereitgestellt wird. Eine Auswirkung davon ist, dass in Sandkastenlösungen bereitgestellte Features als Gültigkeitsbereich nur eine Websitesammlung oder Website haben dürfen.

Prozessmodell für Sandkastenlösungen

SharePoint ist eine ASP.NET-Anwendung. Wie bei anderen ASP.NET-Anwendungen erkennt der spezielle Treiber HTTP.SYS beim Empfang einer HTTP-Anforderung von einem Front-End-Server diese Anforderung und leitet sie an den Anwendungspool weiter, der Anforderungen für die vorgesehene IIS-Website und demzufolge für die vorgesehene SharePoint-Webanwendung verarbeitet. Jeder Anwendungspool hat einen IIS-Arbeitsprozess (w3wp.exe), in dem die Anforderungspipeline jeder Anforderung ausgeführt wird. (Weitere Informationen zu IIS 7.0-Arbeitsprozessen und Anwendungspools finden Sie unter Introduction to IIS 7 Architecture.) Der IIS-Arbeitsprozess wird auf einem SharePoint-Server im Anwendungspoolkonto ausgeführt. Dies ist normalerweise das Farmkonto, weshalb der Prozess über Lese- und Schreibberechtigungen für SharePoint-Ressourcen verfügt. Bei einer Farm mit mehreren Servern ist das Farmkonto in der Regel ein Domänenbenutzerkonto. Dieses entspricht dem Konto, das auf die Inhaltsdatenbanken zugreift. Der SharePoint 2010-Timerdienst wird im Kontext desselben Kontos ausgeführt.

Farmlösungen werden wie andere ASP.NET-Anwendungen im IIS-Arbeitsprozess ausgeführt. Sandkastenlösungen werden hingegen in einer speziellen eingeschränkten Ausführungsumgebung ausgeführt. Dies ist erforderlich, um nicht autorisierten oder schlecht funktionierenden Code daran zu hindern, den Anwendungspool auszubremsen oder zum Absturz zu bringen. Demzufolge legt SharePoint Einschränkungen dahingehend auf, welcher Code in einer Sandkastenlösung ausgeführt werden darf. Als wesentlicher Punkt der Implementierung dieses Systems müssen Sandkastenlösungen in einem speziellen Sandkasten-Arbeitsprozess (SPUCWorkerProcess.exe) ausgeführt werden.

Wenn eine Anforderung versucht, auf eine Sandkastenlösung zuzugreifen, findet der im IIS-Arbeitsprozess ausgeführte SharePoint-Ausführungs-Manager einen Sandkasten-Arbeitsprozess (bzw. startet einen, wenn keiner ausgeführt wird), in dem der Code der Sandkastenlösung ausgeführt wird. Grundsätzlich kann dieser Sandkasten-Arbeitsprozess auf einem beliebigen Server in der Farm gestartet werden, auf dem der SharePoint Foundation-Sandkasten-Codedienst (SPUCHostService.exe) ausgeführt wird. Im Windows-Dialogfeld Dienste heißt dieser Dienst SharePoint 2010-User Code Host.

Der Server, auf dem der SharePoint Foundation-Sandkasten-Codedienst ausgeführt wird, kann (muss aber nicht) ein Front-End-Webserver sein, auf dem der IIS-Arbeitsprozess ausgeführt wird. Der zu verwendende Server kann in der SharePoint-Zentraladministration festgelegt werden. Administratoren können jeden Sandkastenprozess im "lokalen Modus" ausführen, was bedeutet, dass jede Anforderung einer Sandkastenlösung auf dem Front-End-Webserver verarbeitet wird, auf dem der IIS-Arbeitsprozess ausgeführt wird. Administratoren können aber auch den Ausführungs-Manager jeden Sandkastenprozess im "Remotemodus" starten lassen, der auch als "Affinitätsmodus" bezeichnet wird. In diesem Modus sucht der Ausführungs-Manager einen Server, auf dem der SharePoint Foundation-Sandkasten-Codedienst ausgeführt wird und der bereits eine Anwendungsdomäne in seinem Prozess SPUCWorkerProcess.exe für die betreffende Sandkastenlösung erstellt hat. (Dies wäre der Fall, wenn dieselbe Sandkastenlösung zuvor bereits angefordert worden wäre, z. B. von einem anderen Benutzer in einer anderen Websitesammlung.) Wenn es eine übereinstimmende Anwendungsdomäne gibt, wird die Anforderung zur Verarbeitung an diese entsprechende Anwendungsdomäne übermittelt. Wenn noch keiner der Server mit dem SharePoint Foundation-Sandkasten-Codedienst über eine Anwendungsdomäne für die Sandkastenlösung verfügt, weist der Ausführungs-Manager die Anforderungen dem Server zu, der unter den Servern am wenigsten ausgelastet ist. Der Server erstellt anschließend die benötigte Anwendungsdomäne und verarbeitet die Anforderung für die Sandkastenlösung. Unabhängig davon, ob der lokale oder Affinitätsmodus verwendet wird, bleibt die Anwendungsdomäne im Arbeitsprozess der Sandkastenlösung nach der Verarbeitung der Anforderung aktiv und wird wiederverwendet, wenn es eine weitere Anforderung derselben Sandkastenlösung gibt.

Alle Sandkastenlösungen, die von einem bestimmten Server verarbeitet werden, werden im selben Sandkasten-Arbeitsprozess ausgeführt. Jede Sandkastenlösung erhält innerhalb des gemeinsamen Prozesses eine eigene Anwendungsdomäne. Der SharePoint Foundation-Sandkasten-Codedienst wird im Farmkonto ausgeführt.

Codeausführung und Ressourcenzugriff im Sandkasten-Arbeitsprozess

Der gesamte in diesem Sandkasten-Arbeitsprozess ausgeführte Code unterliegt Ausführungs- und Zugriffseinschränkungen. Es gibt zwei Einschränkungssysteme: eines gilt nur für Aufrufe, die dieser Code in Sandkastenlösungen an die SharePoint Foundation-Hauptassembly Microsoft.SharePoint.dll richtet. Die andere gilt für alle anderen Aufrufe, einschließlich Aufrufen aller anderen SharePoint- und .NET Framework-Assemblys. In diesem Thema heißt das erste System Serverseitige Objektmodelleinschränkungen und das zweite Allgemeine Einschränkungen. (Es gibt ferner verschiedene andere Einschränkungen, die vom Rendersystem für aufgeteilte Seiten in Sandkastenlösungen herrühren. Weitere Informationen finden Sie im Abschnitt Rendersystem für aufgeteilte Seiten weiter unten.)

Hinweis
Beide Systeme schließen sich gegenseitig aus: die allgemeinen Einschränkungen gelten nicht für an die Microsoft.SharePoint.dll-Assembly gerichtete Aufrufe.

Die allgemeinen Einschränkungen werden mithilfe zweier Mechanismen durchgesetzt:

1. Eine überaus restriktive Codezugriffssicherheits-Richtlinie schränkt den Code beträchtlich ein, der im Sandkasten-Arbeitsprozess ausgeführt werden darf. Diese Richtlinie wird in der Datei wss_usercode.config in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG definiert und in der Datei web.config in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode referenziert. (Das Ändern dieser Datei wird nicht unterstützt). Die Codezugriffssicherheits-Richtlinie setzt die folgenden Einschränkungen durch:

   • Code in der Sandkastenlösung darf nur verwalteten Code aufrufen.

   • Code in der Sandkastenlösung darf nicht die Microsoft .NET Framework 3.5-Reflektions-APIs aufrufen.

   • Code in der Sandkastenlösung kann nur die .NET Framework 3.5-Assemblys aufrufen, die das AllowPartiallyTrustedCallersAttribute-Attribut aufweisen, das ca. 2/3 der .NET Framework 3.5-APIs blockiert, einschließlich z. B. System.Printing. Einige SharePoint-Assemblys weisen dieses Attribut ebenfalls nicht auf. Eine Liste der .NET Framework-Assemblys mit diesem bzw. ohne dieses Attribut finden Sie unter Verfügbare und nicht verfügbare .NET-Assemblys in Sandkastenlösungen. Listen von SharePoint-Assemblys mit diesem bzw. ohne dieses Attribut finden Sie unter Verfügbare und nicht verfügbare SharePoint-Assemblys in Sandkastenlösungen.

   Hinweis
   Die Codezugriffssicherheits-Richtlinie macht bei Microsoft Office-Assemblys mit starken Namen eine Ausnahme, denen voll vertraut wird.

   Weitere Informationen zu dieser Codezugriffssicherheits-Richtlinie finden Sie unter Einschränkungen bei Sandkastenlösungen.

2. Zweitens hat der Sandkasten-Arbeitsprozess ein Sicherheitstoken mit niedriger Berechtigungsstufe.

   • Das Token verweigert dem Prozess die Berechtigung, Daten im Dateisystem zu lesen oder in dieses zu schreiben.

   • Das Token verweigert dem Prozess die Berechtigung, das Netzwerk aufzurufen. Deshalb kann nur auf Ressourcen zugegriffen werden, die auf dem Server verfügbar sind, der den Sandkasten-Arbeitsprozess ausführt. Auf eine externe Datenbank kann beispielsweise nicht zugegriffen werden.

   • Das Token verweigert dem Prozess die Berechtigung, in die Registrierung zu schreiben.

   • Das Token verweigert die Berechtigung zum Aufrufen von Assemblys, die nicht im allgemeinen Assemblycache vorhanden sind, selbst wenn diese das AllowPartiallyTrustedCallersAttribute-Attribut aufweisen und ansonsten zum Aufrufen aus dem Sandkasten-Arbeitsprozess in Frage kämen.

Diese Einschränkungen gelten allerdings nicht für Aufrufe der APIs in der Microsoft.SharePoint.dll-Assembly. Bei Aufruf von GetLocalizedString können Ressourcen im Dateisystem gelesen werden, und bei Aufruf von SPList können Objekte gelesen und in die Inhaltsdatenbank unabhängig davon geschrieben werden, auf welchem Server sich diese befinden. (Eine Datei in einer Sandkastenlösung kann nicht auf dem Datenträger bereitgestellt werden, weshalb die .resx-Datei getrennt als Farmlösung installiert werden muss.)

Die Haupteinschränkung des Systems Serverseitige Objektmodelleinschränkungen ist, dass nur eine Untermenge der APIs in der Assembly Microsoft.SharePoint.dll in einer Sandkastenlösung aufgerufen werden können. Der Aufruf einer unzulässigen API führt zu einer Ausnahme (die abgefangen und dem Benutzer als Fehler gemeldet wird).

Es folgen einige der für das SharePoint-Objektmodell geltenden Zugriffseinschränkungen:

• Die SPWebApplication-Klasse ist nicht verfügbar. Dies bedeutet u. a., dass eine Sandkastenlösung nicht auf Elemente außerhalb der sie hostenden Websitesammlung zugreifen kann.

• Nahezu alle Klassen im Microsoft.SharePoint.WebControls-Namespace sind nicht verfügbar, weshalb Sie hauptsächlich auf die ASP.NET-Steuerelemente in Sandkastenlösungen begrenzt werden.

Eine vollständige Auflistung der Microsoft.SharePoint.dll-Klassen, die für Sandkastenlösungen zur Verfügung stehen, finden Sie unter In Sandkastenlösungen verfügbare Microsoft.SharePoint.dll-APIs.

Die Umsetzung dieser Einschränkung wird mithilfe eines Paares speziell eingeschränkter Versionen der Assembly Microsoft.SharePoint.dll erreicht, die als Shim-Assemblys bezeichnet werden und sich in im Verzeichnis %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode\assemblies befinden. Diese Versionen unterscheiden sich von der Microsoft.SharePoint.dll-Standardassembly vor allem darin, dass sie nur eine Untermenge der Klassen und Elemente der Standardversion enthalten.

Eine der beiden Shim-Assemblys wird vom Sandkasten-Arbeitsprozess geladen. Die andere wird von einem besonderen Proxyprozess (SPUCWorkerProcessProxy.exe) geladen, der voll vertrauenswürdig ausgeführt und auch vom SharePoint Foundation-Sandkasten-Codedienst verwaltet wird. Die Microsoft.SharePoint.dll-Standardassembly wird ebenfalls in diesen Proxyprozess geladen.

Die Hauptaufgabe der beiden Shim-Assemblys ist das Herausfiltern unzulässiger SharePoint-Klassen und -Elemente. Wenn Code im Sandkasten-Arbeitsprozess die Assembly Microsoft.SharePoint.dll aufruft, wird dieser an die Shimversion der Assembly umgeleitet. Wenn sich die aufgerufene API nicht in der Shim-Assembly befindet, wird eine Ausnahme ausgelöst (die abgefangen und dem Benutzer als Fehler gemeldet wird).

Wenn die Sandkastenlösung eine zulässige API aufruft, die in den Shim-Assemblys enthalten ist, wird sie von der ersten Shim-Assembly an die zweite im vollständig vertrauenswürdigen Proxyprozess übergeben, der sie wiederum an die Microsoft.SharePoint.dll-Standardassembly übergibt. Zurückgegebene Ergebnisse werden wieder an den ursprünglich aufrufenden Code übergeben. Diese prozessübergreifende Interaktion wird mithilfe von .NET Remoting ermöglicht. Ein Sandkasten-Arbeitsprozess und ein voll vertrauenswürdiger Proxyprozess werden stets als Paar gemeinsam gestartet. Stürzt einer der Prozesse ab, wird auch der andere beendet.

Im System Serverseitige Objektmodelleinschränkungen gibt es eine zweite Einschränkung, die auch von den Shim-Assemblys durchgesetzt wird. Einige SharePoint-APIs können in Sandkastenlösungen aufgerufen werden, allerdings nur mit speziellen Einschränkungen für die Parameter, die an sie übergeben werden. Die Shim-Assemblys sind es, die diese Eingabeeinschränkungen durchsetzen und sicherstellen, dass bei einem Verstoß eine Ausnahme ausgelöst wird. Hierfür kommen in SharePoint Foundation 2010 nur die Konstruktoren SPSite(String) und SPSite(Guid) in Frage. Diese stehen in Sandkastenlösungen zur Verfügung. Doch nur URLs oder GUIDs, die auf die Websitesammlung verweisen, in der die Sandkastenlösung installiert ist, können an sie übergeben werden.

Hinweis
Der Grund ist, dass die zweite Shim-Assembly und die Standardassembly Microsoft.SharePoint.dll in einem voll vertrauenswürdigen Prozess ausgeführt werden, für den die allgemeinen Einschränkungen nicht gelten. Diese Einschränkungen gelten für den Sandkasten-Arbeitsprozess.

Wichtig
Die Bereitstellungsphase einer Sandkastenlösung erfolgt in einem Sandkasten-Arbeitsprozess und unterliegt denselben Ausführungseinschränkungen. Sie können beispielsweise bei der Bereitstellung einer Sandkastenlösung keine Datei auf dem Datenträger bereitstellen. Dies ist der Hauptgrund, warum Benutzersteuerelemente (ASCX-Dateien) nicht in einer Sandkastenlösung enthalten sein können.

Abbildung 1 zeigt, wie eine HTTP-Anforderung verarbeitet wird, wenn sie auf eine Sandkastenlösung zugreift.

Abbildung 1: Verarbeitungsmodell für Anforderungen in einer Sandkastenlösung

Die Dateien SPUCHostService.exe, SPUCWorkerProcess.exe und SPUCWorkerProcessProxy.exe befinden sich im Verzeichnis %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode.

Einschränkungen für Sandkastenlösungen bei der Ressourcenverwendung

Sandkastenlösungen unterliegen ferner drei Arten von Einschränkungen bei der Ressourcenverwendung, die anhand zum einen des Entitätstyps, für den die Einschränkung gilt, und zum anderen anhand des Entitätstyps unterschieden werden können, dem eine Einschränkung bei Überschreiten des Grenzwerts auferlegt wird.

• Pro Anforderung mit Einschränkung für die Anforderung: Für die Ausführungsdauer einer Sandkastenlösung bis zu ihrem Abschluss gibt es einen festen Grenzwert, der standardmäßig 30 Sekunden beträgt. Wenn eine Sandkastenlösung diesen Grenzwert überschreitet, wird die Anforderung (aber nicht der Sandkasten-Arbeitsprozess) beendet. (Dieser Grenzwert kann geändert werden, allerdings nur über benutzerdefinierten Code für das Objektmodell. Die relevanten Teile des Objektmodells stehen Sandkastenlösungen nicht zur Verfügung, weshalb dieser Grenzwert durch Sandkastenlösungen nicht geändert werden kann.)

• Pro Anforderung mit Einschränkung für den Prozess: Für Anforderungen gelten 15 weitere Ressourcengrenzwerte. Wenn einer davon von einer Anforderung überschritten wird, werden der Prozess (und alle darin ausgeführten Sandkastenlösungen) beendet.

• Pro Tag bzw. Websitesammlung mit Einschränkung für die Websitesammlung: Jede Websitesammlung unterliegt einem konfigurierbaren Höchstwert an täglichen "Ressourcenpunkten". Diese Punkte werden basierend auf einem Algorithmus kumuliert, der die Verwendung von Ressourcen in den 15 Ressourcenkategorien durch die in der Websitesammlung installierten Sandkastenlösungen berücksichtigt. Wenn eine Websitesammlung ihren maximalen Punktwert überschreitet, werden alle Sandkastenlösungen in der Websitesammlung beendet, und für den Rest des Tages können keine weiteren ausgeführt werden.

Ausführliche Informationen zu den Ressourceneinschränkungen für Sandkastenlösungen finden Sie unter Einschränkungen beim Ressourceneinsatz in Sandkastenlösungen.

Rendersystem für aufgeteilte Seiten

Wenn ein Clientcomputer eine SharePoint-Seite mit einer Komponente aus einer Sandkastenlösung anfordert, z. B. ein in einer Sandkastenlösung bereitgestelltes Webpart, rendert SharePoint mehr als ein Seitenobjekt. Eines wird im Microsoft ASP.NET-Arbeitsprozess (w3wp.exe) gerendert, die anderen werden im Sandkasten-Arbeitsprozess gerendert. Alle nicht zur Sandkastenlösung gehörenden Komponenten werden auf der Seite im ASP.NET-Arbeitsprozess gerendert, während die erste Sandkastenlösungs-Komponente in einem Seitenobjekt im Sandkasten-Arbeitsprozess gerendert wird. Sobald die Seite im Sandkasten-Arbeitsprozess vollständig gerendert wurde, wird sie mit dem Seitenobjekt im ASP.NET-Prozess zusammengeführt. Wenn auf der vom Benutzer angeforderten Seite mehrere Sandkastenlösungs-Komponenten vorhanden sind, wird jede davon in einem eigenen Seitenobjekt im Sandkasten-Arbeitsprozess gesondert gerendert. Jedes solche Seitenobjekt wird wiederum mit dem Seitenobjekt im ASP.NET-Prozess zusammengeführt.

Als Nebeneffekt erlegt dieses System den Möglichkeiten in einer Sandkastenlösung weitere Einschränkungen auf. Weitere Informationen zu diesen Einschränkungen finden Sie unter Einschränkungen bei Sandkastenlösungen.

Umgehen der für Sandkastenlösungen geltenden Einschränkungen

Es gibt für eine Sandkastenlösung zwei wesentliche Möglichkeiten, die üblichen Einschränkungen zu umgehen. Die bei weitem verbreiteteste ist das Verwenden von clientseitigem Code für den Zugriff auf Ressourcen, die in serverseitigem Code in einer Sandkastenlösung nicht verfügbar sind. Eine Sandkastenlösung kann beispielsweise eine benutzerdefinierte Websiteseite mit JavaScript enthalten, die Aufrufe an das JavaScript-Clientobjektmodell von SharePoint richtet. Eine Sandkastenlösung kann auch ein Webpart enthalten, das eine Microsoft Silverlight-Anwendung hostet. Diese Anwendung kann Aufrufe an das Silverlight-Clientobjektmodell von SharePoint richten. Keine der Einschränkungen für Sandkastenlösungen gelten für clientseitigen Code, d. h. keine Ausführungs-, Ressourcenzugriffs- und Ressourceneinsatzeinschränkungen. Weitere Informationen finden Sie unter How to: Extend the Power of a Sandboxed Solution with the SharePoint Client Object Model.

Die Architektur von Sandkastenlösungen lässt auch ein Verfahren zu, über das eine Sandkastenlösung benutzerdefinierte Vorgänge aufrufen kann, die vollständig vertrauenswürdig ausgeführt werden. Dieses Verfahren erfordert, dass eine Farmlösung mit einer oder mehreren Klassen entwickelt wird, die von SPProxyOperation abgeleitet sind. Jede diese Klassen definiert einen Vorgang, der vollständig vertrauenswürdig ausgeführt wird und in Sandkastenlösungen über die Methode ExecuteRegisteredProxyOperation aufgerufen werden kann. Diese voll vertrauenswürdigen Proxyvorgänge werden insbesondere im selben Proxyprozess (SPUCWorkerProcessProxy.exe) ausgeführt, in dem die Standardassembly Microsoft.SharePoint.dll ausgeführt wird. Die Proxyvorgänge können Daten an die Sandkastenlösung zurückgeben.

Abbildung 2 zeigt die Verarbeitung einer Anforderung, die auf eine Sandkastenlösung zugreift, wenn die Sandkastenlösung einen Aufruf an einen voll vertrauenswürdigen Proxy richtet.

Abbildung 2: Anforderungsverarbeitungsmodell, wenn eine Sandkastenlösung einen Aufruf an einen vollständig vertrauenswürdigen Proxy richtet

Die vorherige Beschreibung kann den Eindruck erwecken, dass bei dieser Vorgehensweise eine Farm- und eine Sandkastenlösung stets vom selben Entwicklungsteam gemeinsam entwickelt werden. Tatsächlich kann die Farmlösung mit den Proxyvorgangsklassen speziell entwickelt werden, um beliebigen bzw. allen Sandkastenlösungen bestimmte Vorgänge bereitzustellen, die diese benötigen, einschließlich Sandkastenlösungen, die von anderen Teams entwickelt wurden. Da eine Sandkastenlösung beispielsweise nicht in die Protokolle des vereinheitlichten Protokollierungsdiensts von SharePoint schreiben kann, ist eine Farmlösung, die Sandkastenlösungen Proxyprotolliervorgänge bereitstellt, sehr nützlich.

Weitere Informationen zum Entwickeln und Aufrufen voll vertrauenswürdiger Proxyvorgänge finden Sie unter Sandboxed Solutions in Partnership with Full-Trust Proxies in SharePoint 2010 und anderen Themen im selben Knoten.

Das Framework für die Lösungsüberprüfung

SharePoint bietet ein Framework für die Lösungsüberprüfung zum Entwickeln benutzerdefinierter Lösungsüberprüfungen, um z. B. zu prüfen, ob eine Lösung mit einem bestimmten Zertifikat signiert ist. Die Überprüfungen in einer Websitesammlung werden bei Aktivierung einer Sandkastenlösung ausgeführt. Die Aktivierung ungültiger Lösungen wird verhindert. Wenn eine Überprüfung geändert oder eine neue Überprüfung hinzugefügt wird, werden alle aktivierten Lösungen bei ihrer nächsten Ausführung erneut überprüft. Ungültige Lösungen werden deaktiviert. Weitere Informationen zum Entwickeln benutzerdefinierter Überprüfungen finden Sie unter Solution Validation System.