Bereitstellen von Webparts in SharePoint Foundation

Artikel
09/24/2014

Letzte Änderung: Donnerstag, 1. September 2011

Gilt für: SharePoint Foundation 2010

Inhalt dieses Artikels
Bereitstellungsaspekte
Sicherheitsberechtigungsaspekte
Versehen einer Webpartassembly mit einem starken Namen
Erstellen eines SafeControl-Eintrags
Erstellen einer ".webpart"-Datei

Microsoft SharePoint Foundation erfordert die Bereitstellung eines Webparts im Webpartkatalog, ehe es einer Webseite hinzugefügt werden kann. In diesem Abschnitt wird Folgendes beschrieben: die Unterschiede zwischen dem Ordner bin und dem globalen Assemblycache (GAC), Aspekte bei Sicherheitsberechtigungen, das Versehen einer Assembly mit einem starken Namen für die Bereitstellung, das Erstellen eines SafeControl-Eintrags und das Erstellen einer Webpart-Definitionsdatei zum Bereitstellen des Webparts.

Bereitstellungsaspekte

In einer SharePoint-Website gibt es mehrere Stellen, an denen Sie eine Webpartassembly bereitstellen können.

Lösungskatalog – Der Lösungskatalog ist der empfohlene Ort zum Bereitstellen eines Webparts mithilfe eines Lösung mit eingeschränkter Sicherheitsstufe-Elements, da in diesem die Überwachung und Sicherheit Ihrer Webparts standardmäßig gewährleistet sind. Weitere Informationen zu Lösungen mit eingeschränkter Sicherheitsstufe finden Sie unter Sandkastenlösungen.

Das Verzeichnis bin – Das Verzeichnis bin wird im Stammverzeichnis Ihrer Webanwendung gespeichert. Der Speicherort dieses Verzeichnisses wird bei der Erstellung der Website in Internetinformationsdienste (IIS) bestimmt. In SharePoint Foundation kann dies entweder mithilfe der Website für die Zentraladministration oder manuell durch Erstellen einer neuen Website im Internetinformationsdienste-Manager erfolgen.

Wichtig
Wenn das Verzeichnis bin nicht vorhanden ist, müssen Sie es manuell erstellen. Speichern Sie Webparts nicht im lokalen Verzeichnis _app_bin, das für die Nutzung durch Microsoft reserviert ist. Weitere Informationen finden Sie unter Gewusst wie: Auffinden des Webanwendungs-Stammverzeichnisses.

Wenn das Verzeichnis bin nicht vorhanden ist, müssen Sie es manuell erstellen. Speichern Sie Webparts nicht im lokalen Verzeichnis _app_bin, das für die Nutzung durch Microsoft reserviert ist.

Weitere Informationen finden Sie unter Gewusst wie: Auffinden des Webanwendungs-Stammverzeichnisses.

Globaler Assemblycache – Ein globaler Speicherort, in dem signierte Assemblys bereitgestellt werden können. Der globale Assemblycache (GAC) ermöglicht das Freigeben von Assemblys in zahlreichen Anwendungen. Der GAC wird mit der .NET-Laufzeit automatisch installiert. Komponenten werden in der Regel im Ordner C:\WINNT\Assembly gespeichert.

Jeder Bereitstellungsspeicherort hat Vor- und Nachteile, die in der folgenden Tabelle beschrieben werden.

Bereitstellungsspeicherort	Vorteile	Nachteile
Lösungskatalog	Im Lösungskatalog bereitgestellter Code wird standardmäßig mit teilweiser Vertrauenswürdigkeit ausgeführt. Für diesen Code gibt es auch eine Überwachung der Ressourcenverwendung, um die Integrität der Farm sicherzustellen. Der Lösungskatalog gilt spezifisch für eine Websitesammlung.	Im Lösungskatalog steht nicht das gesamte SharePoint Foundation-Objektmodell zur Verfügung.
Verzeichnis "bin"	Assemblys werden standardmäßig mit teilweiser Vertrauenswürdigkeit ausgeführt. Für Code, der in diesem Verzeichnis ausgeführt wird, gilt ein niedriger Grad an Sicherheitsberechtigungen für den Codezugriff. Da Administratoren Berechtigungen, die einem Webpart für seine ordnungsgemäße Funktion erteilt wurden, explizit erhöhen müssen, bevorzugen sie häufig Assemblys, die im Verzeichnis bin mit einem bekannten Satz von Sicherheitsberechtigungen für den Codezugriff ausgeführt werden. Ein Verzeichnis vom Typ bin gilt spezifisch für eine Webanwendung, wodurch das Isolieren von Code für eine bestimmte Webanwendung möglich wird.	Damit das Webpart in mehreren Webanwendungen ausgeführt werden kann, müssen Sie es im globalen Assemblycache bereitstellen.
Globaler Assemblycache	Assemblys werden standardmäßig mit voller Vertrauenswürdigkeit ausgeführt. Sie werden global installiert, sodass sie in beliebigen Webanwendungen funktionieren. Der globale Assemblycache kann mehrere Versionen derselben Assembly enthalten.	Generell gelten keine Sicherheitsbeschränkungen für den Codezugriff für Code, der im globalen Assemblycache installiert ist. Darüber hinaus wird eine im globalen Assemblycache bereitgestellte Assembly zwischengespeichert, sodass bei einer Neuerstellung der Assembly diese nicht automatisch auf der SharePoint-Website aktualisiert wird. Sie müssen SharePoint Foundation zwingen, die Assembly neu zu laden, indem Sie Internetinformationsdienste zurücksetzen.

Lösungskatalog

Im Lösungskatalog bereitgestellter Code wird standardmäßig mit teilweiser Vertrauenswürdigkeit ausgeführt. Für diesen Code gibt es auch eine Überwachung der Ressourcenverwendung, um die Integrität der Farm sicherzustellen. Der Lösungskatalog gilt spezifisch für eine Websitesammlung.

Im Lösungskatalog steht nicht das gesamte SharePoint Foundation-Objektmodell zur Verfügung.

Verzeichnis "bin"

Assemblys werden standardmäßig mit teilweiser Vertrauenswürdigkeit ausgeführt. Für Code, der in diesem Verzeichnis ausgeführt wird, gilt ein niedriger Grad an Sicherheitsberechtigungen für den Codezugriff. Da Administratoren Berechtigungen, die einem Webpart für seine ordnungsgemäße Funktion erteilt wurden, explizit erhöhen müssen, bevorzugen sie häufig Assemblys, die im Verzeichnis bin mit einem bekannten Satz von Sicherheitsberechtigungen für den Codezugriff ausgeführt werden.

Ein Verzeichnis vom Typ bin gilt spezifisch für eine Webanwendung, wodurch das Isolieren von Code für eine bestimmte Webanwendung möglich wird.

Damit das Webpart in mehreren Webanwendungen ausgeführt werden kann, müssen Sie es im globalen Assemblycache bereitstellen.

Globaler Assemblycache

Assemblys werden standardmäßig mit voller Vertrauenswürdigkeit ausgeführt. Sie werden global installiert, sodass sie in beliebigen Webanwendungen funktionieren. Der globale Assemblycache kann mehrere Versionen derselben Assembly enthalten.

Generell gelten keine Sicherheitsbeschränkungen für den Codezugriff für Code, der im globalen Assemblycache installiert ist.

Darüber hinaus wird eine im globalen Assemblycache bereitgestellte Assembly zwischengespeichert, sodass bei einer Neuerstellung der Assembly diese nicht automatisch auf der SharePoint-Website aktualisiert wird. Sie müssen SharePoint Foundation zwingen, die Assembly neu zu laden, indem Sie Internetinformationsdienste zurücksetzen.

Sicherheitsberechtigungsaspekte

Standardmäßig sind die Sicherheitsberechtigungen für den Codezugriff für das Verzeichnis bin niedrig. Nur die reine Ausführung ist zulässig. In den meisten Fällen müssen Sie diese Berechtigungen erhöhen, damit Ihre Assembly ordnungsgemäß funktioniert, z. B. wenn Ihr Webpart Zugriff auf das SharePoint-Objektmodell benötigt.

Es gibt zwei Möglichkeiten zum Erhöhen von Berechtigungen:

Empfohlene Vorgehensweise – Erstellen Sie eine neue Vertrauensrichtliniendatei, und fügen Sie der Datei web.config einen Verweis auf die neue Datei hinzu. Diese Option ist komplizierter, ermöglicht aber eine präzise Zuordnung von Berechtigungen für Ihre Webparts.

Weitere Informationen zu Vertrauensrichtliniendateien finden Sie unter Absichern von Webparts in SharePoint Foundation.
Optionale Vorgehensweise – Erhöhen Sie die Vertrauensebene des Verzeichnisses bin. In der Datei web.config am Stamm der Webanwendung gibt es das Tag <trust> mit dem Standardattribut level="WSS_Minimal". Sie können diese Ebene in WSS_Medium ändern. Wenngleich diese Option einfacher ist, gewährt Sie beliebige neue Berechtigungen, die Sie ggf. nicht benötigen, und ist weniger sicher als das Erstellen einer neuen Vertrauensrichtliniendatei.

Versehen einer Webpartassembly mit einem starken Namen

Beim Zuordnen von starken Namen wird ein privater Schlüssel zum digitalen Signieren einer Assembly verwendet. Bei diesem Vorgang wird die Assembly außerdem mit einem öffentlichen Schlüssel zum Überprüfen der Gültigkeit der Signatur versehen. Diese Vorgehensweise dient als Schutz gegen nicht autorisierte Versionen eines Webparts. Wenn die Gültigkeit der digitalen Signatur nicht mithilfe des öffentlichen Schlüssels bestätigt werden kann, verweigert SharePoint Foundation die Ausführung des Moduls.

Bei Bereitstellung eines Webparts im Verzeichnis bin wird empfohlen, die Assembly mit einem starken Namen zu versehen. Bei Bereitstellung eines Webparts im globalen Assemblycache muss die Assembly einen starken Namen haben. Assemblys ohne starken Namen werden in SharePoint Foundation nicht empfohlen.

Zum Signieren einer Assembly dient das Tool sn.exe im Funktionsumfang des Microsoft .NET Framework Software Development Kits (SDK). Weitere Informationen zum .NET Framework-SDK finden Sie unter SDKs, Redistributables und Service Packs. Das Tool sn.exe dient auch zum Extrahieren des öffentlichen Schlüssels, der benötigt wird, um Steuerelemente in der SafeControls-Liste als sicher zu registrieren. Weitere Informationen zum Tool sn.exe finden Sie unter Sn.exe (Strong Name-Tool).

Erstellen eines SafeControl-Eintrags

Eine grundlegende Annahme der SharePoint Foundation-Technologie ist, dass nicht vertrauenswürdige Benutzer ASPX-Seiten auf das System hochladen und erstellen können, auf dem SharePoint Foundation ausgeführt wird. In SharePoint Foundation wird eine SafeControl-Liste bereitgestellt, mit der Sie verhindern können, dass nicht vertrauenswürdige Benutzer auf ASPX-Seiten serverseitigen Code beliebig hinzufügen.

Die SafeControls-Liste ist eine Liste mit für Ihre SharePoint-Website spezifischen genehmigten Steuerelementen und Webparts, die Sie so entworfen haben, dass diese auf allen ASPX-Seiten der Website sicher aufgerufen werden können. Die Liste ist in der Datei web.config im Stammverzeichnis Ihrer Webanwendung enthalten.

Bei einem SafeControl-Eintrag handelt es sich um eine XML-basierte Deklaration eines Webparts im folgenden Format:

<SafeControl Assembly="AssemblyNameWithoutDLLExtension, Version=AssemblyVersionNumber, Culture=neutral, PublicKeyToken=PublicKeyToken" Namespace="NamespaceOfYourProject" TypeName="*" Safe="True" />

Der SafeControl-Eintrag verwendet den Assemblynamen, Namespace und Versionsverwaltungsinformationen und erfordert, falls signiert, auch ein öffentliches Schlüsseltoken, um zu bestätigen, dass das Steuerelement sicher ist. Wenn eine Webpartassembly signiert ist, können Sie das Strong Name-Tool zum Abrufen des öffentlichen Schlüsseltokens verwenden, das im SafeControl-Eintrag verwendet werden soll. Mit dem folgenden Befehl wird das öffentliche Schlüsseltoken für eine Assembly abgerufen.

sn -T AssemblyName.dll

Erstellen einer ".webpart"-Datei

Eine Webpart-Definitionsdatei ist eine einfache XML-Datei, die Eigenschaftseinstellungen für ein einzelnes Webpart enthält. Zum Importieren des Webparts in eine Webpartseite laden Sie einfach die .webpart-Datei hoch oder fügen das Webpart dem Webpartkatalog hinzu. Nach dem Hochladen des Webparts können Sie dieses anzeigen, indem Sie das Webpart einer Websiteseite hinzufügen. Wenn nach dem Import ein Standardname und eine Beschreibung für das Webpart angezeigt werden sollen, müssen Sie die Eigenschaften Title und Description einschließen. Wenn Sie beim Import weitere Webparteigenschaften festlegen möchten, können Sie diese ebenfalls in einer .webpart-Datei definieren. Eine .webpart-Datei hat das folgende Format:

<?xml version="1.0" encoding="utf-8" ?> 
  <webParts>
     <webPart xmlns="https://schemas.microsoft.com/WebPart/v3">
       <metaData>
         <type name="TypeName, Version=VersionNumber, Culture=neutral, 
         PublicKeyToken=PublicKeyToken" /> 
         <importErrorMessage>Cannot import this Web 
         Part.</importErrorMessage> 
       </metaData>
       <data>
         <properties>
           <property name="Title" type="string">
              WebPartTitle</property>
           <property name="Description" type="string">
              WebPartDescription
           </property>
         </properties>
       </data>
     </webPart>
   </webParts>

SharePoint Foundation unterstützt auch DWP-Dateien für Webparts. Beim Exportieren eines Webparts wird ggf. eine DWP- oder WEBPART-Datei angezeigt. Weitere Informationen finden Sie unter Upgraden von Webparts.