SharePoint

10 bewährte Methoden zum Erstellen von SharePoint-Lösungen

E. Wilansky, T. Stojecki, P. Olszewski und S. Kowalewski

Codedownload verfügbar in der MSDN-Codegalerie
Code online durchsuchen

Themen in diesem Artikel: Nutzen der Vorteile integrierter SharePoint-Funktionen Bereitstellen von SharePoint-Lösungen Erstellen testbaren Codes Branding von SharePoint für Skalierung und Wartung

In diesem Artikel werden folgende Technologien verwendet: WSS, Visual Studio-Erweiterungen für SharePoint3

Inhalt

1. Der richtige Zeitpunkt zum Überwinden der Kluft
2. Nutzen der Vorteile systemeigener SharePoint-Funktionen
3. Kritische SPDev-Aufgaben und Informationsquellen
4. Entwickeln von Lösungen außerhalb des Servers
5. Testen von Code und Verwalten von Abhängigkeiten
6. Kontinuierliche Integration und automatisierter Build
7. Verwalten benutzerdefinierter Konfigurationseinstellungen durch SharePoint
8. Der richtige Speicherort für Konfigurationseinstellungen
9. Branding von SharePoint für Skalierung und Wartung
10. Erstellen bereitstellbarer Lösungen
Genug der Worte
Zusätzliche Tipps
Verwenden verwandter Links bei jeder Gelegenheit
Erstellen benutzerdefinierter Masterseiten
Behandeln von InfoPath-Projekten in einem automatisierten Build

Die Herausforderungen, denen sich Entwickler gegenübersehen, die mit Windows SharePoint Services 3.0 (WSS) und Microsoft Office SharePoint Server 2007 (MOSS) arbeiten, sind so groß wie die SharePoint-Plattform selbst. Wenn Sie noch nicht mit dieser Plattform vertraut sind, werden Sie mit den in diesem Artikel erforschten Methoden in die richtige Richtung geführt. Wenn Sie ein erfahrener SharePoint-Entwickler sind, können Sie mithilfe dieser Tipps Ihre Kenntnisse verbessern und Diskussionen anstoßen. Letzten Endes führt dies zum Erstellen großartiger SharePoint-Anwendungen. Außerdem wird auf eine Reihe online verfügbarer Referenzinformationen hingewiesen, unter denen Sie mehr über die hier erörterten Themen erfahren können.

1. Der richtige Zeitpunkt zum Überwinden der Kluft

Ein Problem, das früh in einem SharePoint-Entwicklungsprojekt auftaucht, ist die Frage nach der besten Interaktion mit anderen Systemen. Da SharePoint eine zusammengesetzte Anwendungsplattform ist, werden Sie diese Frage wahrscheinlich oft beantworten müssen. Am einfachsten ist es, die SharePoint-Architektur von der Ebene der Webanwendung aus anzuzeigen. Eine Instanz von SharePoint enthält mehrere Webanwendungen. Wenn Sie nicht mit der SharePoint-Anwendungsarchitektur vertraut sind, sollten Sie den Artikel Architektonischer Überblick über Office SharePoint Server 2007 lesen.

In Abbildung 1 sind typische Ansätze zum Interagieren mit SharePoint innerhalb einer Webanwendung, zwischen Webanwendungen und mit externen Systemen dargestellt. Diese Interaktionen werden im verbleibenden Teil dieses Abschnitts behandelt.

Abbildung 1 Interaktionsmodell für das SharePoint-System

Verwenden Sie das SharePoint-Objektmodell, wenn Sie Webparts, CodeBehind für ASP.NET-Formulare oder Websteuerelemente schreiben, die im Kontext einer bestimmten Webanwendung ausgeführt werden (siehe Abbildung 1). Das SharePoint-Objektmodell bietet einen reichhaltigen Satz an Klassen, mittels derer mit SharePoint interagiert werden kann. Diese Klassen sind in Windows SharePoint Services 3.0 und Microsoft Office SharePoint Server-SDKs gut dokumentiert.

Der Kontext ist ein wichtiger Aspekt beim Verarbeiten von SPWeb- oder SPSite-Verwerfung (SharePoint-Web bzw. SharePoint-Website). Wichtige Informationen zum Zeitpunkt der ausdrücklichen Verwerfung dieser Objekte mithilfe der Dispose-Methode oder einer using-Anweisung finden Sie unter Abrufen von Verweisen auf Websites, Webanwendungen und andere wichtige Objekte und Bewährte Methoden: Verwenden verwerfbarer Windows SharePoint Services-Objekte.

Aus der Perspektive des SharePoint-Objektmodells ist eine SharePoint-Webanwendung eine wichtige Sicherheitsbegrenzung. In der Regel sollten Sie das SharePoint-Objektmodell nicht für Interaktionen zwischen SharePoint-Webanwendungen verwenden. Informationen zu weiteren wichtigen SharePoint-Sicherheitsthemen finden Sie unter Sicherheitsprogrammierung in SharePoint 2007.

Wenn Sie Aufrufe zwischen SharePoint-Webanwendungen und zwischen SharePoint und externen Anwendungen wie einer Office-Clientanwendung durchführen, wird die Integrationsschicht des SharePoint-Webdiensts verwendet. Dies ist ein guter Ansatz, wenn Sie versuchen, Entwicklungsaufgaben in Visual Studio außerhalb des Servers durchzuführen. Ausführliche Informationen dazu finden Sie im Abschnitt „Entwickeln von Lösungen außerhalb des Servers“.

Das Aufrufen externer Webdienste, um mit anderen Systemen zu interagieren, ist der häufigste Ansatz, aber nicht immer der beste. Einige Alternativen sind u. U. einfacher zu implementieren, und möglicherweise haben sie auch den Vorteil, bedeutend schneller zu sein, z. B. wenn über das Programmierungsframework der Microsoft-Verzeichnisdienste Aufrufe an die LDAP-Speicher durchgeführt werden oder wenn Aufrufe an Project Server über ADO.NET an die Project Server-Berichtsdatenbank durchgeführt werden statt über die PSI-Webdiensteebene (Project Server Interface). Wenn es sich bei der Datenquelle um einen Webdienst oder eine Datenbank handelt, erwägen Sie die Verwendung des Geschäftsdatenkatalogs (Business Data Catalog, BDC). Weitere Informationen finden Sie im nächsten Abschnitt dieses Artikels, „Nutzen der Vorteile systemeigener SharePoint-Funktionen“.

Microsoft macht in seiner Dokumentation sehr deutlich, dass Sie Aufrufe nicht direkt an SharePoint-Inhalte und -Konfigurationsdatenbanken durchführen sollten. Dennoch wird dieser Ansatz in einigen Anwendungen verwendet. Ob Leistung das Argument für dieses Zugriffsverfahren ist oder schlicht mangelhafte Kenntnis über das SharePoint-Framework – es gibt sicherere Ansätze.

Letztendlich kann Microsoft das zugrunde liegende Schema in diesen Datenbanken ändern, und es kann mehr als eine Inhaltsdatenbank pro Webanwendung geben. Daher können scheinbar harmlose direkte Abfragevorgänge zu problematischen Lösungen führen. Nutzen Sie stattdessen die anderen in diesem Artikel skizzierten Ansätze, oder entwickeln Sie eine andere Strategie, bei der suboptimale Lösungen vermieden werden, die die Integrität Ihrer SharePoint-Implementierungen beeinträchtigen.

2. Nutzen der Vorteile systemeigener SharePoint-Funktionen

Zwei Situationen können Entwicklungsteams davon abhalten, alle Vorteile der systemeigenen Funktionen von SharePoint zu nutzen. Erstens ist es, da SharePoint eine so umfassende Plattform ist, u. U. einfacher, benutzerdefinierte Lösungen zu erstellen, statt verstehen zu lernen, was SharePoint ohne benutzerdefinierten Code zu bieten hat. Zweitens neigen Geschäftsinhaber dazu, ausführliche Anforderungen, Drahtmodelle und Verhaltensweisen von Anwendungen zu erstellen, die Ihnen wenig Flexibilität lassen, wenn Sie standardmäßige (OOB, out-of-the-box) Funktionen verwenden möchten.

Aber wenn Sie das annehmen, was die SharePoint-Plattform zu bieten hat, macht sich dies in Dividenden bezahlt, selbst wenn die fertige Version ein wenig von den ursprünglichen Anforderungen abweicht. Um diesen Vorteil zu erlangen, muss das Entwicklungsteam die Technologie grundlegend verstehen und, was noch wichtiger ist, den Wert und die Kompromisse einer besonderen Implementierung dem Geschäftsinhaber verdeutlichen können.

Sich ein solides Verständnis von den Stärken und Schwächen von SharePoint zu erwerben, ist einfacher gesagt als getan. Sowohl WSS als auch MOSS enthalten SDKs, die technische Dokumentation, exemplarische Vorgehensweisen, Codebeispiele und bewährte Methoden zum Programmieren von Lösungen in SharePoint enthalten. Wenn Informationen schwer zu finden sind, können Sie mit .NET Reflector in einige der zentralen SharePoint-Assemblys hineinsehen. In Abbildung 2 sind die Member der PeopleQueryControl-Klasse in der Microsoft.SharePoint-Assembly dargestellt, einschließlich der IssueQuery-Methode. Mit dem PeopleEditor-Steuerelement (alias People Picker) wird die Verantwortung für das Abfragen des Identitätsspeichers von SharePoint an PeopleQueryControl delegiert. Außerdem können Sie die IssueQuery-Methode außer Kraft setzen, um die Standardimplementierung zu ändern. Wie Sie in der Abbildung sehen, gewährt Ihnen .NET Reflector einen Einblick in die Interaktion der Komponenten.

Abbildung 2 .NET Reflector zeigt die IssueQuery-Methode von PeopleQueryControl

Ausgestattet mit Kenntnissen bezüglich der Funktionen der Plattform müssen Sie den Beteiligten die Vorteile einer bestimmten Implementierung in einer Art und Weise deutlich machen, die den Wert ihrer Investition in die Technologie unterstreicht. Bei einer Plattform von der Größe von SharePoint ist es besonders wichtig, sich nicht schon vorzeitig von Implementierungsdetails einschüchtern zu lassen. Vielmehr sollte dem Kunden vermittelt werden, was durch frühes Veröffentlichen und häufige Iterationen möglich ist. Stellen Sie sicher, dass Ihr Kunde mit den Features des Produkts vertraut ist, indem Sie eine effektive Feedbackmethode einsetzen, durch die er während des gesamten Softwareentwicklungslebenszyklus (SDLC) beteiligt bleibt.

Stellen Sie sich eine Diskussion über das Anzeigen einer großen Auswahlliste von Entitäten für einen Benutzer vor. Es gibt viele Möglichkeiten, diese Funktionen zu implementieren. Da wären z. B. das DropDownList-Steuerelement in ASP.NET, das GridView-Steuerelement, ein benutzerdefiniertes Steuerelement oder ein Drittanbietersteuerelement. SharePoint selbst bietet in seinem PeopleEditor oder seiner Basisklasse auch ein Auswahlsteuerelement für große Listen, das EntityEditorWithPicker-Steuerelement, das Sie für diesen Zweck verwenden können. Diese Websteuerelemente bieten viele Hooks zum Injizieren Ihrer eigenen benutzerdefinierten Logik. Wenn Sie diese verwenden, nutzen Sie die Vorteile einer reichhaltigen und intuitiven Benutzeroberfläche und erstellen eine konsistente Benutzerfunktionalität in SharePoint. Unter Anpassen von EntityEditorWithPicker finden Sie ein Beispiel zum Außerkraftsetzen von Methoden des PeopleEditor-Websteuerelements.

Das Darstellen von Branchendaten in SharePoint ist eine weitere gängige Anforderung. In der Regel beginnen Sie damit, die Goldquelle der Daten zu identifizieren und zu ermitteln, wie Sie die Daten am besten in SharePoint importieren können. Das Erstellen von Webdienstproxys oder das Einrichten von ADO.NET-Verbindungen zu Datenbanken ist für viele Entwickler ein alter Hut. Der BDC ist jedoch u. U. eine bessere Alternative. Durch diese SharePoint-Funktion können Sie Daten von externen Datenquellen lesen und in SharePoint anzeigen. Der BDC unterstützt eine Vielzahl von Authentifizierungsmechanismen, ermöglicht das Erstellen von Zuordnungen zwischen Datenentitäten und ist eng mit den SharePoint-Such- und Listeninfrastrukturen verbunden.

Außerdem enthält SharePoint eine Suite von Webparts zum Anzeigen von Branchendaten durch den BDC. Derzeit unterstützt der BDC Erstellungs-, Aktualisierungs- und Löschvorgänge zwar nicht direkt, aber Sie können benutzerdefinierte Anwendungen für diese Vorgänge erstellen und sie dem BDC durch die BDC-Aktionsschnittstelle zuordnen. Weitere Informationen finden Sie unter den BDC-Themen in der Randleiste „Ressourcen“.

3. Kritische SPDev-Aufgaben und Informationsquellen

In diesem Abschnitt soll über häufige Aufgaben aufgeklärt werden, die jeder SharePoint-Entwickler während der Softwareentwicklung benötigen dürfte. Dies ist keine Toolbesprechung, noch soll ein Tool einem anderem vorgezogen werden. Stattdessen werden Vorschläge für Tools angeboten, mit denen Sie gängige SharePoint-Entwicklungsaufgaben durchführen können.

Das Erstellen von SharePoint-Lösungen ist ein Ansatz, den Sie übernehmen sollten. Ted Pattison liefert in seinem Office Space-Artikel Lösungsbereitstellung mit SharePoint 2007 eine gute Zusammenfassung, indem er schreibt, „Das Verpacken und Bereitstellen Ihrer WSS-Entwicklungsprojekte unter Verwendung von Lösungspaketen ist eine empfohlene Vorgehensweise, und die Kenntnis des Verfahrens sollte als wesentliche Fähigkeit angesehen werden.“ Es gibt zahlreiche Möglichkeiten, Ihre SharePoint-Lösungen zu verpacken. Dies reicht vom manuellen Erstellen von manifest.xml-Dateien und DDFs (diamond directive files) bis zu Visual Studio-Projekten, bei denen die Windows SharePoint Services 3.0-Tools verwendet werden: Visual Studio 2005/2008-Erweiterungen (VSeWSS).

Das Verwenden von VSeWSS-Projekten ist bedeutend einfacher als das manuelle Erstellen von DDFs. Einige Alternativen sind jedoch besonders nützlich für kommerzielle oder Unternehmensbereitstellungen, einschließlich WSPBuilder, STSDev, SPDeploy und DDFGenerator. Evaluieren Sie die verschiedenen Tools, um jenes zu finden, das Ihren Anforderungen am ehesten entspricht. Der Schlüssel besteht darin, Lösungspakete für die Bereitstellung zu erstellen, statt Codekomponenten manuell bereitzustellen.

Das Debuggen von clientseitigem Verhalten kann schwierig sein, und Tools wie die Internet Explorer Developer Toolbar (Developer Tools in Internet Explorer 8) erleichtern diese Bemühung wesentlich. Internet Explorer Developer Toolbar ähnelt Firefox-Add-Ons wie FireBug. Ein weiteres Tool, das in Internet Explorer ausgeführt wird, ist der Web Development Helper. Beide dieser Tools sind nützlich für das Debuggen von clientseitigem JavaScript, das Prüfen von Stilen und das Durchlaufen des DOM. Das IIS 6.0 Resource Kit enthält eine Unmenge nützlicher Tools, falls Sie die Interaktion mit IIS prüfen müssen. WFetch z. B. ist nützlich zum Prüfen von Seitenausgabeinformationen wie der Ausgabe eines benutzerdefinierten HTTP-Handlers oder Informationen eines Authentifizierungsheaders, um zu überprüfen, welches Authentifizierungsprotokoll Sie verwenden (siehe Abbildung 3).

Abbildung 3 WFetch zeigt einen NTLM-Authentifizierungsheader

Die Behandlung serverseitiger Codeprobleme kann in SharePoint besonders schwierig sein, da Fehler hinter einigermaßen freundlichen (wenn auch nicht sehr hilfreichen) Webseiten oder in Protokollen, die Webdienstaufrufen folgen, verborgen sind. Die wichtigsten Schlussfolgerungen an dieser Stelle bestehen darin zu wissen, wo SharePoint Daten protokolliert und wann ein Debugger verwendet werden sollte, und mit Tools vertraut zu sein, die Ihnen helfen können, die Probleme in Ihren SharePoint-Anwendungen zu beheben.

Wenn Sie feststellen möchten, wodurch ein Anwendungsproblem verursacht wird, sollten Sie sich zunächst die Windows-Ereignisprotokolle ansehen. In einigen Fällen können Sie Optionen verwenden, um die Ereignisprotokollierung zu erhöhen. Wenn Sie z. B. mit einer Anwendung arbeiten, für die Kerberos-Authentifizierung erforderlich ist, können Sie die Kerberos-Protokollierung auf das Systemereignisprotokoll erhöhen. Es gibt viele hervorragende Onlineressourcen, in denen die Kerberos-Authentifizierung erklärt wird. Kurze und bündige Informationen zur ausführlichen Kerberos-Protokollierung in Windows Server 2003 finden Sie in Kerberos-Protokollregistrierungseinträge und KDC-Konfigurationsschlüssel in Windows Server 2003.

Die SharePoint- und IIS-Protokolle sind bei der Problembehandlung von SharePoint-Anwendungsfehlern von entscheidender Bedeutung. Es folgen einige kurze Informationen zu diesen beiden kritischen Protokollierungsquellen:

• Die SharePoint-Protokolle befinden sich unter „<%CommonProgramFiles%>\Microsoft Shared\Web Server Extensions\12\LOGS“. Sie können das Lesen dieser Protokolle vereinfachen, indem Sie die Protokollanzeige installieren.
• Die IIS-Protokolle befinden sich in der Regel unter „<%SystemRoot%>\System32\LogFiles“. Sehen Sie sich die Eigenschaften von IIS an, um den Stammspeicherort der Protokolle zu überprüfen. Da jede IIS-Webanwendung eine eindeutige ID hat, ordnen Sie die IIS-Anwendungs-ID für die in IIS aufgelistete SharePoint-Webanwendung einfach dem Ordnernamen im LogFiles-Verzeichnis zu.

Erwägen Sie für benutzerdefinierte Anwendungsprotokollierung die Integration der Enterprise Library. Indem Sie die Enterprise Library-Anwendungsblöcke zur Protokollierung und Ausnahmebehandlung in Ihren Code integrieren, kann Ihr Protokollierungsziel, in der Regel eine Datenbank, Protokollierungsinformationen und Ausnahmedetails enthalten, die für die Behandlung von Problemen mit Ihren benutzerdefinierten Anwendungen von entscheidender Bedeutung sind.

Das nützlichste Tool zum Debuggen von Problemen mit benutzerdefinierten Anwendungen ist der Visual Studio-Debugger. Wenn Sie Visual Studio auf Ihrem SharePoint-Server installiert haben, verfügen Sie über die Debuggingfunktion mit F5. Im Idealfall sollten Sie Visual Studio nicht auf Produktions- oder Modellbürosystemen installiert haben. Außerdem können Sie Software auf lokalen Arbeitsstationen entwickeln und Lösungen von einem Remotestandort aus debuggen. Remotedebugging wird in SharePoint vollständig unterstützt, indem eine Verbindung zum w3wp-Prozess hergestellt wird, der Ihre benutzerdefinierte Anwendung in IIS hostet.

Um zu ermitteln, mit welcher Instanz von w3wp Ihre Anwendung ausgeführt wird, öffnen Sie eine Eingabeaufforderung, und führen Sie IISApp.vbs auf Ihrem Windows-Server aus, um die Prozess-ID (PID) zu identifizieren, mit der Ihre SharePoint-Webanwendung ausgeführt wird. Wählen Sie anschließend in Visual Studio die Instanz von w3wp mit der entsprechenden PID aus.

Ein weiteres sehr hilfreiches Tool ist Exception Display. Wenn Sie dieses Tool in Ihrer Farm aktivieren, wird die benutzerfreundliche SharePoint-Fehlerseitenmeldung durch einige Ausnahmeanzeigetypen ersetzt. Informationen zur Installation und Verwendung dieses Tools erhalten Sie, indem Sie auf den oben aufgeführten Link „Exception Display“ klicken.

Wenn ein bereitgestelltes Webpart einen Seitenladefehler verursacht, können Sie die Wartungsseite für Webparts öffnen, indem Sie „?content=1“ an das Ende der Seiten-URL anfügen. Auf der Wartungsseite können Sie das fehlerauslösende Webpart von der Seite löschen.

Abschließend können Sie in der web.config-Datei Ihrer Webanwendung die Ablaufverfolgung auf Anwendungsebene aktivieren. Lesen Sie dazu die Diskussion in Aktivieren der Ablaufverfolgung auf Anwendungsebene.

Fahren Sie fort, das Framework zu erweitern. In SharePoint können benutzerdefinierte Lösungen auf vielfältige Weise integriert werden. Da SharePoint auf ASP.NET basiert, erbt es die Erweiterungspunkte von dieser Plattform. Mit der Veröffentlichung von WSS 3.0/MOSS SP1 unterstützt Microsoft jetzt das ASP.NET AJAX-Framework. Das bedeutet, dass Sie die ASP.NET AJAX-Erweiterungen und das AJAX Control Toolkit nutzen können. Sie können das Installations- und Konfigurationsverfahren mithilfe der Erweiterungen unter Ajaxify MOSS custom stsadm extensions erleichtern, mit denen mithilfe der SPWebConfigModification-Klasse programmgesteuert AJAX-bezogene Einträge zu web.config hinzugefügt oder daraus entfernt werden.

Wenn das Framework eingerichtet ist, können Sie die Reaktionsfähigkeit Ihrer Seiten mithilfe der AJAX-Steuerelementsuite verbessern, indem Sie clientseitige Rückrufe implementieren. Dies ist besonders wichtig, wenn in benutzerdefinierten Webparts externe Webdienstaufrufe durchgeführt werden. Lesen Sie dazu den Artikel Clientbasierte Webdienstaufrufe mit AJAX Extensions.

jQuery ist ein weiteres clientseitiges Framework, das viel Aufmerksamkeit erregt, insbesondere aufgrund der jüngsten Ankündigung von Microsoft, dass es in Visual Studio unterstützt wird. Da die jQuery-Kernbibliothek in einer einzelnen .js-Datei enthalten ist, ist es einfach, diese in SharePoint zu integrieren. Unter jQuery-Skript-Manager ist ein Ansatz zum Einbetten von jQuery-Skripts in eine ASP.NET-Webseite beschrieben.

Weitere Informationen zur Silverlight-Integration finden Sie in Lassen Sie SharePoint mit Silverlight 2-Webparts erstrahlen. Die Autoren untersuchen ein Beispiel zum Integrieren einer Silverlight-Anwendung in SharePoint.

4. Entwickeln von Lösungen außerhalb des Servers

Wann immer möglich, sollten Sie Ihre Lösungen ohne die Abhängigkeiten erstellen, die bei der SharePoint-Entwicklung oft auferlegt werden. Mithilfe des Visual Studio-Entwicklungsservers, der ASP.NET-Webpart-Frameworkunterstützung, der SharePoint-Webdienste und mit Drittanbietertools können Sie den Großteil Ihrer Entwicklung auf einer Standardarbeitsstation durchführen. Dafür benötigen Sie keinen Computer, auf dem SharePoint ausgeführt wird.

Da SharePoint zusammen mit IIS und ASP.NET ausgeführt wird, ist der in Visual Studio enthaltene Webentwicklungsserver ein hervorragender Ausgangspunkt für einen Großteil Ihrer SharePoint-Entwicklung. Sie können z. B. Webparts, HTTP-Handler und Websteuerelemente in dieser relativ einfachen Umgebung entwickeln.

Zu Beginn haben Sie etwas Arbeit durch das Einrichten der Umgebung und das Hosten Ihrer Komponenten. Um z. B. effektiv ein ASP.NET-Webpart zu entwickeln, sollten Sie ein Klassenprojekt erstellen, um Ihr Webpart zu hosten, ein Visual Studio-Webanwendungsprojekt sowie optional ein Komponententestprojekt. Wir haben ein Beispiel für dieses Setup, das Sie für die Webpartentwicklung außerhalb des Servers verwenden können, in die Visual Studio SPTips-Lösung integriert (mit dem Beispielcode des Artikels).

Der Standardkonstruktor im Webpartprojekt enthält eine Zeile, mit der die ExportMode-Eigenschaft des Webparts festgelegt wird:

public WebPartOffServerExample()
{
    this.ExportMode = WebPartExportMode.All;
}

Mithilfe dieser Zeile können Sie auf Grundlage der Eigenschaften, die Sie für das Webpart konfigurieren, eine .webpart-Bereitstellungsdatei generieren (siehe Abbildung 4).

Abbildung 4 Menüoption für Webpartexport

Anschließend können Sie das Webpart über diese Bereitstellungsdatei in SharePoint importieren (Abbildung 5). Den abwärtskompatiblen Importdateityp „.dwp“ von SharePoint 2003 sollten Sie nicht verwenden. Das zugrunde liegende XML-Schema für eine .dwp-Datei ist nicht so reichhaltig und erfordert, dass Sie früh im SDLC auf die Microsoft.SharePoint-Assembly verweisen.

Abbildung 5 Das in SharePoint importierte Webpart

Beachten Sie, dass Sie die Erstellung von .webpart-Bereitstellungsdateien sicherstellen können, indem Sie von der Webpart-Klasse im System.Web.UI.WebControls.WebParts-Namespace erben, und nicht vom Microsoft.SharePoint.WebPartPages-Namespace. (Beispiele dafür, wann Sie gegebenenfalls von der Webpart-Klasse von SharePoint erben sollten, finden Sie unter dem Thema, das in der Randleiste „Ressourcen“ aufgelistet ist.)

Microsoft macht eine bedeutende Teilmenge des SharePoint-Objektmodells durch Webdienste verfügbar. Wenn Sie mithilfe der SharePoint-Webdienste auf das Objektmodell zugreifen, können Sie eine Lösung entwickeln, ohne von Direktzugriff auf SharePoint-Assemblys abhängig zu sein. SharePoint hostet die Webdienste auf jedem Web-Front-End-Server (WFE-Server) im virtuellen Verzeichnis „_vti_bin“.

In Visual Studio fügen Sie einer Lösung SharePoint-Webdienste in der gleichen Weise wie einen beliebigen Webdienstverweis hinzu. Webdienst-URLs haben in SharePoint folgendes Format:

http://<SharePointServer>:port/[sites/][SubSite/]_vti_bin/WebService.asmx

wobei <SharePointServer> die der Webanwendung zugeordnete URL ist. Beispiel:

https://www.contoso.com:35000/_vti_bin/Lists.asmx

Wenn Sie einen Webdienstverweis hinzufügen, erstellt Visual Studio Proxyklassen sowohl für den Dienst als auch für die Datentypen, die vom Dienst verwendet werden. Weitere Informationen zur Interaktion mit diesen Webdiensten finden Sie in den Artikeln WSS SDK 3.0-Thema: Webdienstrichtlinien und SharePoint-Webdienste.

Durch das Implementieren einer dreistufigen Architektur wird das Ziel gefördert, Code zu isolieren und Abhängigkeiten von SharePoint und anderen äußeren Quellen zu beseitigen. Dieser Ansatz kann Ihre Fähigkeit verbessern, außerhalb des Servers zu entwickeln, indem Geschäfts-, Datenzugriffs- und Benutzeroberflächenlogik voneinander abstrahiert werden. Dadurch können Sie Code in überschaubare Abschnitte unterteilen und Abhängigkeiten zwischen ihnen verringern. Durch diesen Ansatz erhalten Sie auch besser testbaren Code. Weitere Informationen dazu finden Sie im Abschnitt „Testen von Code und Verwalten von Abhängigkeiten“.

Es gibt noch mehr Tools, die Sie verwenden können. Die Abhängigkeit von SharePoint über die gesamte Codebasis hinweg zu beseitigen, ist unrealistisch. Das Entwickeln für SharePoint außerhalb des Servers erfordert im Allgemeinen die Verwendung einer SharePoint-Instanz, die früh im SDLC meist auf einem virtuellen Computer gehostet wird. Mit der Zunahme der SharePoint-Entwicklung wurden mehrere Tools erstellt, um diese bedeutende Abhängigkeit zu behandeln. Ein solches Tool ist „SharePoint on Vista Installation Helper“ von Bamboo Solutions. Mit diesem Tool können Sie WSS 3.0 SP1 oder MOSS 2007 SP1 unter Windows Vista installieren. Dadurch können Sie SharePoint-abhängige Lösungen ohne Windows Server entwickeln.

Microsoft unterstützt diese Art der Ausführung von SharePoint nicht. Dieser Ansatz ist jedoch in der SharePoint-Entwicklungscommunity auf positive Resonanz gestoßen, da er zur Verringerung des Speicherbedarfs beiträgt, der durch diese Abhängigkeit von SharePoint entsteht. Weitere Informationen dazu finden Sie unter How to install Windows SharePoint Services 3.0 SP1 on Vista x64/x86.

5. Testen von Code und Verwalten von Abhängigkeiten

Die weit verbreitete Akzeptanz von Komponententestframeworks und verwandten Tools hat sich natürlich auch die SharePoint-Entwicklung erreicht. Komponententests und Integrationstests sind zwei primäre Testkategorien. Beide Testtypen weisen unterschiedliche Merkmale auf und erfordern die Verwendung verschiedener Tools und Verfahren.

Beim Schreiben von Komponententests oder Tests außerhalb des Servers wird es als bewährte Methode angesehen, externe Abhängigkeiten mit Stellvertretern wie Stubs oder Mocks zu simulieren. Durch Verwenden von Objekten, die externe Abhängigkeiten nachahmen, wird Ihr Test schneller und konzentriert sich stärker auf das zu testende Verhalten. Damit dieser Ansatz effektiv ist, müssen Sie den Prinzipien des testbaren, objektorientierten Entwurfs folgen oder ein spezialisiertes Framework verwenden, um eng gekoppelte Komponenten von Ihrer Lösung zu isolieren.

Identifizieren Sie die Verhaltensweisen und Geschäftsregeln, die von der Infrastruktur unabhängig sind, und stellen Sie sicher, dass Sie eine Strategie haben, um diese isoliert zu testen. Um Interaktionen mit SharePoint, einer Datenbank oder einem Webdienst zu isolieren, können Sie das Repository-Muster einführen. Damit werden die Details vom Back-End-System wegabstrahiert. Diese Repositoryobjekte können mithilfe von Prinzipien der Steuerumkehrung (inversion of control, IoC) und der Abhängigkeitsinjektion (dependency injection, DI) an Komponenten höherer Ebene übergeben werden. Weitere Informationen zu IoC und DI finden Sie in Flexiblere Anwendungen durch Verringerung der Softwareabhängigkeiten.

Um die Testbarkeit Ihrer Darstellungskomponenten zu erhöhen, implementieren Sie das MVP-Muster (Model-View-Presenter). Weitere Informationen zu testbaren Codemustern finden Sie in Entwerfen testbarer Anwendungen.

Weitere große Herausforderungen, denen sich SharePoint-Entwickler gegenübersehen, wenn sie Komponenten testen, drehen sich um das SharePoint-Objektmodell. Einfach ausgedrückt, ist das Testen dieser Komponenten in Isolation keine triviale Aufgabe. Dies ist ein direktes Ergebnis einer begrenzten Anzahl von Schnittstellen und Abstraktionen sowie einer großen Anzahl versiegelter Klassen: Klassen mit inneren Abhängigkeiten oder ohne öffentlichen Konstruktor.

Ein Produkt, das mit diesen Mängeln fertig wird, ist TypeMock Isolator. Dies ist ein kommerzielles Mockframework, mit dem versiegelte, konkrete, statische oder intern erstellte Klassen simuliert werden können. Damit andere Mockframeworks verwendet werden können, müssen Sie sich an Muster und Prinzipien halten, denen wir uns bereits entzogen haben. Mit TypeMock Isolator oder dessen neuer SharePoint-spezifischer Version, Isolator for SharePoint, werden diese Einschränkungen umgangen und die Codeabdeckung erhöht, ohne dass eine ausgeführte Instanz von SharePoint erforderlich ist. Das P&P-Team (Patterns and Practices) verwendet TypeMock Isolator ebenfalls in seiner Referenzarchitektur im SharePoint-Leitfaden.

An einem gewissen Punkt müssen Sie Integrationstests schreiben, die vom SharePoint-Objektmodell abhängig sind. Es ist sinnvoll, Ihre serverabhängigen Komponententests getrennt von den serverunabhängigen zu verwalten.

Mit dem Testlisten-Editor im Test-Manager von Visual Studio können Sie Ihre Komponenten- und Integrationstests trennen. Sie können z. B. zwei Listen von Tests erstellen: eine für serverabhängige Tests und eine für serverunabhängige (siehe Abbildung 6). Durch diesen Ansatz können Sie auswählen, welcher Satz von Tests ausgeführt werden soll. Das hängt davon ab, ob Sie sich auf dem Server befinden.

Abbildung 6 Der Testlisten-Editor mit einer kategorisierten Testliste

Wenn Visual Studio auf dem Server installiert ist, können Sie Ihre Tests in der IDE ausführen und debuggen oder mit dem Befehlszeilentool „MSTest.exe“ serverabhängige Tests durchführen. Leider wird MSTest nur ausgeführt, wenn Visual Studio auf dem Server installiert ist. Wir hoffen, dass eine zukünftige Version von MSTest nicht diese schwere Abhängigkeit enthält.

Mit MSTest.exe können Sie durch Befehlszeilenargumente angeben, welche Tests ausgeführt werden sollen. Wenn Sie MSTest.exe ausführen, müssen Sie entweder die Option „/testcontainer“ oder „/testmetadata“ angeben. Mit der Option „/testmetadata“ können Sie angeben, welche Tests ausgeführt werden. Geben Sie z. B. Folgendes ein, um alle serverabhängigen Tests auszuführen:

MSTest /testmetadata:SPTips.vsmdi /testlist:ServerDependentTests

Geben Sie Folgendes ein, um einen bestimmten Test innerhalb der serverabhängigen Tests auszuführen:

MSTest /testmetadata:SPTips.vsmdi /test:GetTasks_ShouldReturnTasks

Beispiele zu Tests auf dem Server und Tests mit einem Mockframework finden Sie im Beispielcode in der Visual Studio SPTips-Lösung im Codedownload dieses Artikels.

6. Kontinuierliche Integration und automatisierter Build

Code in der Quellcodeverwaltung zu behalten, kontinuierliche Integration zu verwenden und den Buildprozess zu automatisieren, sind wesentliche Schritte für die effiziente Veröffentlichung von Ressourcen mit qualitativ hochwertigem Code. Mit SharePoint ist das Setup für diese Umgebung gelinde gesagt eine Herausforderung. Der wichtigste Ausgangspunkt für diesen Tipp ist der Artikel Übersicht über die Teamentwicklung.

Im weiteren Verlauf der Übersicht finden Sie den Artikel „Gewusst wie: Erstellen einer automatisierten Build- und Bereitstellungslösung mit Team Foundation Server Build“ aus dem SharePoint-Leitfaden. In diesem Thema geht es hauptsächlich um das Erstellen von Buildzielen zum Erstellen und Bereitstellen von Lösungen. Diese Methode hat zwar ihre Vorzüge, kann aber nicht verwendet werden, wenn sich die TFS-Build- und SharePoint-Server nicht in derselben Umgebung befinden, wie dies in Unternehmen häufig der Fall ist. Durch das Erstellen von Lösungspaketen mithilfe von Zielen wird die Verwendung der Pakete in der automatisierten Buildumgebung begrenzt, wodurch die frühe Entwicklung und das Testen von Paketen durch Entwickler nicht gefördert werden.

Die Alternative besteht darin, in Visual Studio Postbuildereignisse zu verwenden. Die Postbuildereignisse können eingerichtet werden, um die gleichen Verpackungsschritte wie die MSBuild-Ziele durchzuführen. So können Entwickler Pakete für die Bereitstellung ihrer eigenen Sandboxumgebungen erstellen. Dieser Ansatz funktioniert auch mit Drittanbietertools wie WSPBuilder und STSDEV.

Bei der Bereitstellung im Unternehmen müssen Sie u. U. auch eine Versionsverwaltung für Lösungspakete erwägen. Die Lösungsversion an die aktuelle Buildversion zu binden ist ein Ansatz. Dies kann durch benutzerdefinierten Anwendungscode vereinfacht werden, der im AfterBuild-MSBuild-Ereignis oder vom Postbuildereignis ausgeführt wird. Erwägen Sie auch Lösungs-IDs im automatisierten Build sowie die Frage, ob Sie bei jedem Build neue IDs generieren sollen. Diese Entscheidung wird sich auf Ihre Fähigkeit auswirken, Lösungen in Zukunft zu aktualisieren. Im Allgemeinen werden neue Lösungs-IDs generiert, wenn die Assemblyversionen geändert werden. Andernfalls werden die Lösungs-IDs beibehalten, wenn Versions-IDs zwischen Builds statisch sind.

Statt Informationen zu wiederholen, die Sie aus dem SharePoint Server-Entwicklercenter abrufen können, erweitern wir diesen Tipp, indem wir uns darauf konzentrieren, wie der automatisierte Buildprozess weiter vereinfacht werden kann. Im SharePoint-Leitfaden geht das P&P-Team im Artikel „Gewusst wie: Erstellen einer automatisierten Build- und Bereitstellungslösung mit Team Foundation Server Build“ davon aus, dass Sie VSeWSS-Erweiterungen verwenden.

VSeWSS ist zwar eine fantastische Ergänzung des Repertoires eines SharePoint-Entwicklers dank Funktionen wie dem WSPView-Bereich, mit dem Sie Ihre Lösung dynamisch konfigurieren können. Wir sind jedoch der Meinung, dass es sich nicht für mittlere bis große Implementierungen oder Teams eignet, die agilen Entwicklungsmethoden folgen.

In der Teamdokumentation des P&P-SharePoint-Leitfadens ist angegeben, dass VSeWSS Bereitstellung mit einem einzigen Klick sowie Debuggen mittels F5 bietet. Die Bereitstellung mit einem einzigen Klick ist sicherlich Bestandteil von VSeWSS, aber das Debuggen mittels F5 hat mehr mit der Tatsache zu tun, dass Sie Visual Studio lokal auf Ihrer Instanz von SharePoint ausführen müssen. Dies ist eine Voraussetzung für das Installieren von VSeWSS. Obwohl Sie VSeWSS mit einem Registrierungshack auf einer Arbeitsstation installieren können, gehen viele Vorteile der Erweiterung verloren, wenn sie auf einer Arbeitsstation installiert wird.

In der Dokumentation steht auch, dass Entwickler für viele Tools wie z. B. WSPBuilder und STSDEV Feature.xml- und Manifest.xml-Dateien pflegen müssen, um SharePoint-Lösungen in einem Weblösungspaket zu verpacken. In Wirklichkeit werden diese Tools ständig weiterentwickelt. Zum Beispiel enthält WSPBuilder jetzt Erweiterungen, die die einfache Wartung von Feature.xml und Manifest.xml in Visual Studio 2005 und 2008 ermöglichen.

VSeWSS ist dann am nützlichsten, wenn Sie unsicher sind, wie ein SharePoint-Projekt strukturiert wird. Unter Umständen möchten Sie z. B. einen VSeWSS-Projekttyp verwenden, um die Struktur eines Webparts oder eines SharePoint-Workflowprojekts zu bestimmen. Sobald Sie wissen, wie das funktioniert, können Sie sich mit diesen Informationen an einen allgegenwärtigen Projekttyp heranwagen. Die Hauptprobleme bei der Verwendung von VSeWSS für ein mittleres bis großes Projekt sind folgende:

• Die Erweiterungen wurden dafür entworfen, auf einer Instanz von Visual Studio installiert zu werden, auf der ein SharePoint-Server ausgeführt wird. Deshalb haben sie eine feste Abhängigkeit von WSS.
• Entwickler, die VSeWSS nicht installiert haben, verfügen nicht über die speziellen Projekttypen, die von VSeWSS erstellt werden, und können keine Projekte öffnen, die sie benötigen.
• Das Neuerstellen einer Lösung wird durch VSeWSS komplizierter.

Im Leitfaden wird in einem anderen Ansatz vorgeschlagen, für jede Visual Studio-Lösung manuell eine SharePoint-Lösungsdatei zu erstellen, zusammen mit dem Bereitstellungsmanifest „manifest.xml“. Mit Tools wie WSPBuilder können Sie diesen Schritt jedoch in Ihrem Build automatisieren.

Die Schlüssel zu einem erfolgreichen automatisierten Build sind folgende:

• Verwenden Sie standardmäßige Visual Studio-Projekttypen (d. h. Klassenprojekte für Webparts), damit alle Entwickler problemlos ein Projekt öffnen können.
• Strukturieren Sie Ihr Codeprojekt so, dass Lösungsverpackung in das Projekt integriert ist (siehe Abbildung 7). Es besteht kein Grund, ein separates Bereitstellungsprojekt zu erstellen.
• Richten Sie ein Postbuildereignis ein, um WSPBuilder oder ein anderes automatisiertes Lösungserstellungstool auszuführen, um die SharePoint-Lösungsdatei zu erstellen. Dieser Ansatz funktioniert sowohl für eine lokale Bereitstellung der Lösung als auch für den automatisierten Buildprozess.
• Verwenden Sie Makrobedingungen, um die Bestandteile Ihres Postbuildereignisses zu steuern, die in Abhängigkeit davon aufgerufen werden, wo der Build stattfindet.
• Ein automatisierter Build wird durch ein InfoPath-Projekt weiter verkompliziert. Informationen dazu finden Sie in dem Tipp „Behandeln von InfoPath-Projekten in einem automatisierten Build“ in der Onlineversion dieses Artikels.

Abbildung 7 In den Codedownload des Webpartprojekts integrierte Lösungsverpackungsstruktur

Stellen Sie nicht im globalen Assemblycache (GAC) bereit, bis Sie zu einer Integrationsumgebung übergehen. Wenn Sie Assemblys im BIN-Ordner behalten, ist das Debuggen benutzerdefinierter SharePoint-Anwendungen bedeutend einfacher. Es gibt bestimmte Projekttypen, die nicht zu diesem Modell passen, z. B. SharePoint-Ereignishandler und SharePoint-Features. Wenn Entwickler in einer freigegebenen Entwicklungsumgebung kompatible Assemblys im BIN-Ordner platzieren, stehen sie nicht vor dem Problem häufiger IIS-Resets nach jeder Bereitstellung.

Es folgen einige Hinweise zum Ausführen von SharePoint-Assemblys vom BIN-Ordner aus:

• Dekorieren Sie Ihre Assembly mit dem Attribut „[assembly:System.Security.AllowPartiallyTrustedCallers]“.
• Konfigurieren Sie die benutzerdefinierte CAS-Richtlinie (code access security, Codezugriffssicherheit), oder setzen Sie die web.config auf „voll vertrauenswürdig“, wie hier gezeigt:

<system.web>
  <trust level="Full" />
</system.web>

(Volle Vertrauenswürdigkeit eignet sich nur für die lokale oder interne Entwicklung, bei der Ihre Coderessourcen schließlich im GAC bereitgestellt werden.)

• Signieren Sie Ihre Assemblys für die spätere Bereitstellung im GAC.

7. Verwalten benutzerdefinierter Konfigurationseinstellungen durch SharePoint

Wie bei jeder Anwendung ist es auch in SharePoint-Lösungen erforderlich, dass die Konfigurationseinstellungen richtig funktionieren. Eine benutzerdefinierte Anwendung mit nur wenigen Konfigurationseinstellungen kann leicht manuell verwaltet werden. Im Gegensatz dazu kann die Anzahl der Konfigurationseinstellungen beim Entwickeln von Unternehmensanwendungen oder kommerziellen Anwendungen in SharePoint beträchtlich sein.

Deshalb sind die Kenntnis der verschiedenen Einstellungstypen und das Wissen um deren Verwaltung wichtig für das Entwickeln, Bereitstellen und Verwalten von Anwendungen. Der beste Ansatz besteht darin, die Anzahl der von SharePoint verwalteten Einstellungen zu erhöhen und die Anzahl der manuell verwalteten Einstellungen zu verringern.

Wenn Sie die Einstellungsarten verstehen, können Sie auch erkennen, wo diese hingehören. SharePoint-Konfigurationseinstellungen lassen sich im Allgemeinen in drei Kategorien unterteilen: zentrale Einstellungen, benutzerdefinierte Einstellungen sowie SharePoint-Einstellungen.

Zentrale Einstellungen werden in der gesamten SharePoint-Webanwendung verwendet. Anwendungsblöcke der Enterprise Library und die Konfigurationen externer Webdienste sind Beispiele für typische zentrale Einstellungen.

Benutzerdefinierte Einstellungen sind für benutzerdefinierte Buildkomponenten vorgesehen. Mit diesen Einstellungen, die nicht außerhalb der Komponente freigegeben sind, werden Konfigurationseinstellungen für die benutzerdefinierte Komponente bereitgestellt. Mit benutzerdefinierten Einstellungen können z. B. Verzeichnisservereinstellungen für eine LDAP-Suche bereitgestellt werden.

SharePoint-Einstellungen sind erforderlich, damit die Lösung in SharePoint funktioniert. Zu den Einstellungen in dieser Kategorie gehören SafeControls-Einträge, SessionState-Anpassungen oder das Registrieren von HttpModules.

Nachdem Sie Ihre Einstellungen in Kategorien unterteilt haben, können Sie sie an den richtigen Orten bereitstellen, um sie zu verwalten. Das Ziel besteht darin, die Anzahl der manuell verwalteten Einstellungen zu verringern. Wenn Sie zulassen, dass SharePoint Einstellungen verarbeitet, wird die Anzahl der Fehler verringert, die beim Bereitstellen von Anwendungen auftreten können.

Zentrale Einstellungen lassen sich am besten in der Quellcodeverwaltung verwalten. Dadurch können Sie einen Einstellungsverlauf pflegen, während Sie eine einzig wahre Quelle für die Einstellungen bereitstellen. Außerdem können Sie mit diesem Ansatz unterschiedliche Versionen der Konfigurationsdateien für Entwicklungs-, Test- und Produktionsumgebungen pflegen.

Mit dem SharePoint-Objektmodell und den -Bereitstellungstools können Sie die Installation und Verwaltung benutzerdefinierter Einstellungen automatisieren. Verwenden Sie die SPWebConfigModification-Klasse, Lösungsbereitstellung sowie das CONFIG-Verzeichnis in der SharePoint-Struktur 12, um Ihre Strategie zur Verwaltung der Konfiguration zu bilden. Weitere Informationen zum Bereitstellen mithilfe von Lösungen finden Sie im Abschnitt „Erstellen bereitstellbarer Lösungen“ dieses Artikels.

Mithilfe der SPWebConfigModification-Klasse von SharePoint können Sie programmgesteuert Einstellungen in der web.config-Datei einer SharePoint-Webanwendung registrieren. Mittels SPWebConfigModification können Sie eine Konsolenanwendung oder stsadm-Erweiterung schreiben, um Konfigurationseinträge aufzulisten, hinzuzufügen oder zu löschen. Dieser Ansatz ermöglicht ein schnelles und konsistentes Ändern großer Sätze von SharePoint-Konfigurationseinstellungen. Die SPWebConfigModificationType-Enumeration in dieser Klasse enthält drei Werte, mit denen die Art der vorgenommenen Änderung angegeben wird: EnsureChildNode, EnsureAttribute und EnsureSection. Verwenden Sie EnsureSection umsichtig, da mit dieser Enumeration hinzugefügte Einträge nicht problemlos wieder entfernt werden können. Weitere Informationen finden Sie unter Automatisieren der Bereitstellung von Webanwendungen mit der SharePoint-API.

Mit dem CONFIG-Verzeichnis von SharePoint können Sie Einstellungen deklarativ registrieren, indem Sie in diesem Verzeichnis XML-Dateien pflegen. WSS wendet Einstellungen in den XML-Dateien auf die web.config-Datei an, wenn mit SharePoint eine Webanwendung erstellt wird. Einstellungen in diesem Ordner werden auf alle Webanwendungen angewendet. Weitere Informationen zu diesem Ansatz finden Sie unter Verwalten von web.config-Anpassungen.

8. Der richtige Speicherort für Konfigurationseinstellungen

Im vorherigen Tipp wurden verschiedene Arten von SharePoint-Konfigurationseinstellungen und deren Verwaltung untersucht. Während eine Anwendung Umgebungen durchläuft, z. B. vom Testen zur Produktion, können Änderungen an den Konfigurationseinstellungen (besonders jene, die auf externe Systeme zeigen) Verunsicherung hervorrufen. Wenn Sie wissen, wo Konfigurationseinstellungen hingehören, ist die Verwaltung der Umgebungseinstellungen u. U. stabiler.

Beim Entwickeln zusammengesetzter Anwendungen sind zunehmend Konfigurationseinstellungen erforderlich. Die Leistungsfähigkeit sowie die einfache Verwendbarkeit von Konfigurationseinstellungen haben zu deren übermäßigem Gebrauch geführt. Eine Möglichkeit, ständige Änderungen an diesen Einstellungen zu verringern, besteht darin, das Paradigma „Konvention vor Konfiguration“ anzuwenden, statt Werte z. B. von Benennungskonventionen abzuleiten. Im Abschnitt „Kontinuierliche Integration und automatisierter Build“ wird ein Beispiel für das Paradigma „Konvention vor Konfiguration“ skizziert, indem vorgeführt wird, wie die SharePoint-Lösungsverpackung in Ihre Visual Studio-Projekte integriert wird. Ein verwandtes Beispiel für dieses Paradigma befindet sich im Webinhaltstipp „Verwenden verwandter Links bei jeder Gelegenheit“.

Instanzenspezifische Einstellungen sind für jede Instanz eines Webparts eindeutig. Unter Umständen haben Sie z. B. ein Webpart, mit dem auf der Seite eines Programmmanagers eine Liste von Projekten angezeigt wird, während auf der Seite eines Entwicklers Projekt- und Aufgabendetails angezeigt werden. Instanzenspezifische Einstellungen lassen sich am besten in einem benutzerdefinierten Toolpart oder in den verschiedenen Toolpart-Eigenschaften eines Webparts speichern.

Konfigurationseinstellungen, die von mehr als einer Komponente verwendet werden, werden als globale Einstellungen betrachtet. Beispiele für Einstellungen in dieser Kategorie sind URLs für externe Webdienste, Geschäftsobjekteinstellungen und Dateneinstellungen. Diese Einstellungen werden am besten in web.config gespeichert und wie im Abschnitt „Verwalten benutzerdefinierter Konfigurationseinstellungen durch SharePoint“ beschrieben verwaltet.

9. Branding von SharePoint für Skalierung und Wartung

Durch Branding erhalten die Benutzer Ihrer SharePoint-Website den deutlichsten visuellen Hinweis bezüglich des Zwecks Ihrer Anwendung. Branding beinhaltet die Arbeit mit verschiedenen Artefakten wie Masterseiten, Inhaltsseiten, Seitenlayouts, Websitedefinitionen und CSS. Informationen zum Erstellen benutzerdefinierter Masterseiten finden Sie im Onlinetipp „Erstellen benutzerdefinierter Masterseiten“.

Ressourcen

Microsoft Office SharePoint Server 2007 and Windows SharePoint Services v3

Geschäftsdatenkatalog

SharePoint 2007: BDC—The Business Data Catalog

Webpart-Klasse (Microsoft.SharePoint.WebPartPages)

Stellen Sie sicher, dass bei Ihrer Anwendungsskalierung und Wartungsstrategie berücksichtigt wird, wie Sie diese Brandingartefakte verwalten. Weitere Informationen zum SharePoint-Branding finden Sie in der Randleiste „Ressourcen“ unter „Microsoft Office SharePoint Server 2007 and Windows SharePoint Services v3“.

Bevor Sie ein Tool für das Branding auswählen, betrachten Sie die Größe Ihrer SharePoint-Implementierung, das Ausmaß Ihres Brandingbestrebens und die Fachkenntnis der Entwickler, die die Anwendung unterstützen. Wir konzentrieren uns auf zwei Tools: SharePoint Designer und Visual Studio.

SharePoint Designer hat seinen Ursprung in FrontPage und ist ein nützliches Webentwurfstool zum Bearbeiten von Masterseiten und CSS. Die Benutzerfreundlichkeit von SharePoint Designer hat jedoch ihren Preis:

• Es gibt keine Unterstützung für die integrierte Quellcodeverwaltung.
• In SharePoint Designer vorgenommene Änderungen führen dazu, dass das Ghosting des geänderten Inhalts aufgehoben wird.

Infolgedessen werden Kopien des Inhalts in der Inhaltsdatenbank statt im Dateisystem gespeichert. Dies hat folgende Auswirkungen:

• Schwierigere Verwaltung von Bereitstellungen, da der Inhalt nur in SharePoint oder SharePoint Designer aktualisiert werden kann
• Eine Website wird von aktualisiertem Inhalt getrennt, der im Dateisystem bereitgestellt wird
• Potenzielle Leistungsprobleme in großen, aktiven SharePoint-Implementierungen

Aus diesen Gründen glauben wir, dass SharePoint Designer sich am besten für kleine bis mittlere Implementierungen und Prototypen eignet.

Visual Studio bietet eine konsistente Entwicklungsumgebung sowohl für Anwendungskomponenten als auch für Brandingartefakte, aber es verfügt nicht über die grafische Bearbeitungsfunktionalität von SharePoint Designer. Aufgrund dessen müssen Entwickler sich in der Bearbeitung von HTML und CSS besser auskennen. Eine gute Projektstruktur muss eingerichtet werden, um die Brandingartefakte zu verwalten. Mit der Unterstützung der integrierten Quellcodeverwaltung durch Visual Studio ist es einfacher, umgebungsspezifische Konfigurationen zu verwalten und Brandingartefakte zu verpacken, die über mehrere Umgebungen hinweg bereitgestellt werden sollen. Außerdem bleibt das Ghosting von Brandingartefakten erhalten. Deshalb ist Visual Studio unser bevorzugtes SharePoint-Brandingtool für große kommerzielle und Unternehmensimplementierungen.

Es gibt drei Ansätze für das Anwenden von Branding: Websitevorlagen, benutzerdefinierte Websitedefinitionen und OOB-Websitedefinitionen, die über Featureheftung (feature stapling) mit Anpassungen gekoppelt sind. Das Erstellen benutzerdefinierter Websitevorlagen dürfte der schnellste Ansatz für kleine Implementierungen und Prototypen sein. Websites jedoch, die aus einer Vorlage erstellt wurden, werden nicht aktualisiert, wenn eine neue Vorlage hochgeladen wird. Bei benutzerdefinierten Vorlagen können Sie die Vorlagen-ID nicht angeben, die Änderungen an Bereitstellungscode erfordert, der auf die Vorlagen verweist. Außerdem wird Inhalt, für den kein Ghosting vorliegt, durch Websitevorlagen nur erstellt, wenn er sich auf Leistung auswirken könnte.

Websitedefinitionen sind flexibler und portabler als Websitevorlagen. Sie können die Websitedefinitionsdatei (onet.xml) und zugehörige Inhalte in der Quellcodeverwaltung verwalten und Ghosting-Inhalt bereitstellen. Dadurch kann eine Website mit neuem Inhalt aktualisiert werden, vorausgesetzt, sie wurde nicht bereits angepasst. Websitedefinitionen können aufgrund der Komplexität des XML, das Sie bearbeiten müssen, schwierig zu erstellen sein. Diese Aufgabe lässt sich vereinfachen, indem OOB-Websitedefinitionen (in „12\Template\SiteTemplates“) als Ausgangspunkt verwendet werden oder indem eine Websitedefinition mithilfe von VSeWSS exportiert wird. Weitere Informationen zu Websitedefinitionen finden Sie unter Site Definitions Demystified.

Wenn es um mittlere bis große Implementierungen geht, ist das Kombinieren der OOB-Websitedefinitionen mit benutzerdefinierten Features der beste Ansatz. Mithilfe von Features können Websitedefinitionen erweitert werden, und es kann ein modularer Ansatz zur Bereitstellung von Websites bereitgestellt werden. Im Office Space-Artikel Features für SharePoint finden Sie einen guten Überblick über die Features. Die VSeWSS-Erweiterungen sowie einige Drittanbietertools bieten Vorlagen zum Erstellen gängiger Features, die beim Branding von Websites verwendet werden.

Mithilfe der Featureheftung können Sie ein Feature an eine Websitedefinition anfügen und aktivieren lassen, wenn eine neue Website erstellt wird. Dies ist eine gute Möglichkeit, Ihr Branding auf die OOB-Websitedefinitionen von SharePoint anzuwenden.

10. Erstellen bereitstellbarer Lösungen

Es gibt mehrere Möglichkeiten, Ihre Komponenten in eine SharePoint-Webanwendung einzubringen. In diesem Abschnitt wird die Nutzung der Verpackungs- und Bereitstellungsframeworks erörtert, die SharePoint bietet. Dazu gehören auch Weblösungspakete (Lösungen/WSPs) Features und das SharePoint-Objektmodell.

Die Entscheidung darüber, wie Komponenten verpackt werden sollen, ist größtenteils davon abhängig, wo die Komponenten bereitgestellt werden. Lösungen enthalten Dateien, die auf dem Server bereitgestellt werden. Features enthalten Inhalt, der in der Inhaltsdatenbank bereitgestellt wird.

Eine SharePoint-Lösung enthält die Assemblys und Ressourcen, die in SharePoint-Webanwendungen bereitgestellt werden. Lösungen sind kompakt, einfach bereitzustellen und zurückzuziehen, und SharePoint verarbeitet die Spiegelung von Dateiupdates in SharePoint-Lösungen über mehrere Server in einer Farm hinweg. Sie können SharePoint-Lösungen auch für Änderungen an der web.config-Datei verwenden. Weitere Informationen zu Lösungen und Änderungen an web.config finden Sie in den Abschnitten „Kritische SPDev-Aufgaben und Informationsquellen“ und „Verwalten benutzerdefinierter Konfigurationseinstellungen durch SharePoint“. In Abbildung 8 sind die gängigen Ordnerspeicherorte aufgeführt, die von Lösungen und ihren Inhalten unterstützt werden. „Struktur 12“ bezieht sich auf den SharePoint-Anwendungsstamm, standardmäßig „<%CommonProgramFiles%>\Microsoft Shared\Web server extensions\12“.

Abbildung 8 Gängige Dateispeicherorte, die von WSPs zugänglich sind

Ordner in Struktur 12	Contains
ISAPI\HELP\[LCID]	SharePoint-Hilfedateien. Stellen Sie in diesem Ordner (oder einem lokalisierten Unterordner) Ihre eigenen .chm-Dateien bereit
CONFIG	Anpassungen von web.config
\ISAPI	SharePoint-Webdienste (hier können Sie ebenso Ihre benutzerdefinierten Webdienste bereitstellen); wird „/_vti_bin“ zugeordnet
\Resources	Global.resx-Dateien, auf die von benutzerdefinierten Features und Websitedefinitionen zugegriffen wird
TEMPLATE\CONTROLTEMPLATES	.Ascx-Benutzersteuerelemente; werden „/_controltemplates“ zugeordnet
\TEMPLATE\FEATURES	Features natürlich!
\TEMPLATE\LAYOUTS	Häufige Websiteseiten; werden „/_Layouts“ zugeordnet
\TEMPLATE\IMAGES	Häufige Website-Abbilddateien; werden „/_layouts/images“ zugeordnet
\TEMPLATE\SiteTemplates	Alle Website Definitionen von SharePoint. Erstellen Sie „<subfolder>\xml“, um Ihre benutzerdefinierte onet.xml-Websitedefinition bereitzustellen
\TEMPLATE\THEMES	Alle in Designs verwendeten Benutzeroberflächenelemente. Klonen Sie einen vorhandenen Designordner, um Ihren eigenen zu erstellen
\TEMPLATE\[LCID]\XML	Webtemp.xml-Dateien zum Definieren verfügbarer Websitedefinitionen. Fügen Sie an dieser Stelle eine XML-Datei für Ihre benutzerdefinierte Websitedefinition hinzu
\TEMPLATE\ADMIN	Vom der zentralen Verwaltung verwendete Seiten; werden „/_admin“ zugeordnet
\ADMISAPI	Verwaltungswebdienste; werden „/_vti_adm“ zugeordnet

Die folgenden Regeln sind bei der Arbeit an Lösungen zu beachten:

• Da SharePoint-Lösungen in der Konfigurationsdatenbank verwaltet werden, kann es in einer Farm nur eine eindeutige Instanz einer SharePoint-Lösung geben. Dieser Punkt ist wichtig, wenn Sie in der gleichen Farm verschiedene Versionen der gleichen Webanwendung hosten möchten, z. B. sowohl aktuelle Wartungs- als auch zukünftige Entwicklungsumgebungen.
• SharePoint verfolgt Lösungen nach ID und nicht nach Name. Deshalb müssen Sie Lösungs-IDs in der Quellcodeverwaltung pflegen, wenn Lösungen in Zukunft aktualisiert werden sollen.
• Struktur 12 ist ein freigegebener Webanwendungsspeicherplatz. Wenn Sie mehrere Webanwendungen in der gleichen Farm hosten möchten, müssen Sie sicherstellen, dass Ihre SharePoint-Lösungen keine vorhandenen SharePoint-Dateien oder Dateien, die an diesem Speicherort von anderen Lösungen bereitgestellt werden, überschreiben.
• Lösungen können keine Dateien außerhalb der in Abbildung 8 aufgelisteten Ordner bereitstellen. Dazu gehören auch Ordner unter der Webanwendung, z. B. „wpresources“, „global _wpresources“ oder andere Ordner außerhalb von Struktur 12.
• Lösungen können innerhalb einer SharePoint-Webanwendung keine Inhalte bereitstellen. Dies ist Aufgabe der SharePoint-Features.

Features können Webparts in der Galerie zur Verfügung stellen, Dateien in Dokumentbibliotheken hochladen und veröffentlichen und benutzerdefinierte Aktionen wie das Festlegen des Websiteentwurfs oder der standardmäßigen Masterseite mithilfe von Featureempfängerassemblys durchführen. Weitere Informationen zum Verwenden von Features für das Branding finden Sie in den Informationen zum Verwenden des richtigen Brandingverfahrens weiter oben in diesem Artikel.

Es folgen einige Einschränkungen beim Erstellen von Features:

• Features verfolgen keine hinzugefügten Inhalte. Deshalb liegt es in der Verantwortung des Features, hinter sich aufzuräumen, wenn es mithilfe eines Featureempfängers deaktiviert wird. Betrachten Sie den gesamten Produktlebenszyklus des Features, und überlegen Sie, bevor der Inhalt gelöscht wird, ob vom Feature bereitgestellte Inhalte u. U. von anderen Teilen der Webanwendung benötigt werden. Wenn z. B. bei Deaktivierung eines Features eine Masterseite entfernt wird, werden alle Seiten zerstört, die von dieser Masterseite erben.
• Deaktivieren Sie ein Feature in allen Webanwendungen, bevor Sie die Lösung entfernen, mit der das Feature bereitgestellt wurde. Wenn Sie dies nicht tun, schlägt die Lösungsbereitstellung fehl, und wenn der Featureordner entfernt wurde, müssen Sie mithilfe von STSADM eine Deinstallation des Features erzwingen.

Genug der Worte

Verwenden Sie diesen Artikel als Wegweiser, machen Sie sich mit den bereitgestellten Referenzinformationen vertraut, und laden Sie das Codebeispiel des Artikels herunter, um Hilfe bei den ersten Schritten zu erhalten. Vielleicht lesen Sie sich diese bewährten Methoden noch einmal durch, während Sie Anwendungen auf der SharePoint-Plattform entwickeln, und finden auch Verwendung für die Codebeispiele. Wenn Sie Erläuterungen benötigen oder uns Feedback zu den angebotenen Tipps oder zu anderen Tipps geben möchten, die Sie als wichtig erachten, senden Sie uns Ihre Fragen oder Kommentare. Wir werden uns bemühen, schnell zu antworten. Sie können uns (in englischer Sprache) per E-Mail unter ewilansky@yahoo.com erreichen.

Zusätzliche Tipps

Es folgen einige zusätzliche Tipps zum Entwickeln von SharePoint-Lösungen.

Verwenden verwandter Links bei jeder Gelegenheit

Erwägen Sie die Verwendung relativer statt absoluter Links. Durch das Einbeziehen verwandter Links in Speicherorte wie Dokumentbibliotheken, Datenverbindungen und Berichtsbibliotheken wird die Bereitstellung von einer SharePoint-Instanz zu einer anderen vereinfacht. Denken Sie an das Beispiel der Berichtsbibliothek: Wenn Sie in allen Ihren SharePoint-Umgebungen einen konsistenten Webspeicherort für die Berichtsbibliothek verwenden, müssen Sie die Zeiger auf Berichte nicht mehr ändern, wenn Sie Ihre Anwendung von einer Umgebung in die nächste verschieben. In der Regel gilt „Konvention vor Konfiguration“ für die Codekonfiguration, aber dieses Konzept kann auch lose auf andere Konfigurationsaspekte Ihrer Bereitstellungen angewendet werden.

Übrigens hoffen wir, dass Microsoft relative Links innerhalb der SharePoint-Plattform unterstützen wird, in der einige Konfigurationseinstellungen derzeit absolute Links erfordern. In einer .udcx-Datenverbindungsdatei von InfoPath müssen Sie z. B. eine absolute URL zur Formularbibliothek angeben, und das ReportViewer­Webpart erfordert einen absoluten Pfad zur Berichtsdefinition.

Erstellen benutzerdefinierter Masterseiten

Ein gängiges Verfahren für das Branding von SharePoint-Websites mit einem bestimmten Erscheinungsbild besteht in der Erstellung benutzerdefinierter Masterseiten, die Ihnen die größtmögliche Kontrolle über das Layout Ihrer Website geben. Sie können eine vorhandene SharePoint-Masterseite Ihren Anforderungen anpassen. Dieser Ansatz funktioniert am besten, wenn die vorhandene Masterseite dem gewünschten Layout so nahe wie möglich ist. Wenn sich das gewünschte Erscheinungsbild sehr von allen OOB-Masterseiten unterscheidet, möchten Sie u. U. von Grund auf neu starten. Da SharePoint jedoch bestimmte Funktionen in Masterseiten erfordert, wird empfohlen, mit einer minimalen Masterseite zu beginnen und Ihr gewünschtes Erscheinungsbild von dort zu erstellen. Weitere Informationen zum Erstellen einer minimalen Masterseite finden Sie unter Gewusst wie: Erstellen einer minimalen Masterseite. Sie können auch einige minimale Masterseiten aus dem Blog von Heather Solomon herunterladen. Die Adresse ist ebenfalls im Abschnitt „Ressourcen“ aufgelistet.

Behandeln von InfoPath-Projekten in einem automatisierten Build

In Microsoft InfoPath Designer erstellte Projekte stellen eine größere Herausforderung für Ihre Bemühungen dar, Ihren Build zu automatisieren. Am besten lassen Sie InfoPath und SharePoint die Verpackung vornehmen. Informationen dazu, wie Sie von InfoPath-Projekten portable Lösungspakete erhalten, finden Sie im Artikel „Automatisieren der Bereitstellung von Webanwendungen mit der SharePoint-API“.

Ethan Wilansky ist ein Direktor in der Technology Practice von FTI Consulting und arbeitet hauptsächlich an der Erstellung benutzerdefinierter SharePoint-Lösungen. Als MVP für Microsoft-Verzeichnisdienste konzentriert er sich auf das DS-Programmierungsframework und ist außerdem Mitglied des Office Developer Advisory Council.

Paul Olszewski ist Informationsspezialist in einem .NET-Funktionsteam. Er hat sich auf das Erstellen und Bereitstellen wiederverwendbarer Komponentenanwendungen spezialisiert, die Microsoft-Technologien nutzen.

Tomek Stojecki arbeitet bei Annapolis Computing, wo er sich auf die Architektur und die Entwicklung von .NET-Anwendungen spezialisiert hat, in denen Entwurfsmuster und agile Methoden verwendet werden. Er war bei einigen SharePoint-basierten Projekten als Berater tätig.

Stefan Kowalewski ist leitender Berater in einem SharePoint-Entwicklungsteam. Er stellt technische Fachkenntnisse bereit und bringt bewährte agile Erfahrungen in benutzerdefinierte SharePoint-Entwicklungsbemühungen ein.