Teambasierte Entwicklung in SharePoint 2010

Artikel
06/24/2015

Zusammenfassung: Hier erfahren Sie, wie Sie ein SharePoint 2010-Projekt für eine benutzerdefinierte Entwicklung in einer Teamumgebung realisieren, indem Sie Visual Studio 2010 und SharePoint Designer 2010 verwenden. Darüber hinaus wird erklärt, welche Aspekte Sie berücksichtigen müssen, bevor Sie mit einem SharePoint-Entwicklungsprojekt beginnen.

Letzte Änderung: Mittwoch, 12. Januar 2011

Inhalt dieses Artikels
Einführung in die teambasierte Entwicklung mit SharePoint 2010
Komponenten eines SharePoint-Projekts
Implementierungsoptionen für SharePoint-Projekte
Entwicklungstools für SharePoint-Entwickler und -Implementierer
Konfigurieren der typischen Umgebung für ein SharePoint-Entwicklungsteam
Bereitstellungsmodelle für SharePoint
Upgraden von bereitgestellten SharePoint-Projekten
Problembehandlung für benutzerdefinierte Bereitstellungskomponenten
Schlussbemerkung
Weitere Ressourcen

Inhalt

Einführung in die teambasierte Entwicklung mit SharePoint 2010
Komponenten eines SharePoint-Projekts
Implementierungsoptionen für SharePoint-Projekte
Entwicklungstools für SharePoint-Entwickler und -Implementierer
Konfigurieren der typischen Umgebung für ein SharePoint-Entwicklungsteam
Bereitstellungsmodelle für SharePoint
Upgraden von bereitgestellten SharePoint-Projekten
Problembehandlung für benutzerdefinierte Bereitstellungskomponenten
Schlussbemerkung
Weitere Ressourcen

Einführung in die teambasierte Entwicklung mit SharePoint 2010

Microsoft SharePoint 2010 mit seinen Komponenten Microsoft SharePoint Foundation 2010 und Microsoft SharePoint Server 2010 bietet ein umfassendes Spektrum an Funktionen für Zusammenarbeit, Content Management, Business Intelligence, die Nutzung von sozialen Netzwerken und elektronische Formulare. Doch SharePoint 2010 zeichnet sich nicht nur durch dieses robuste, integrierte Funktionenpaket aus, sondern auch durch eine hohe Erweiterbarkeit und eine Fülle von Optionen, mit denen Entwickler benutzerdefinierte Lösungen für individuelle Geschäftsanforderungen erstellen können.

SharePoint 2010 ist eine Microsoft ASP.NET-Anwendung. Viele der in ASP.NET-Projekten verwendeten Techniken und Methoden für die Entwicklung im Team gelten für auch SharePoint 2010-Projekte. Allerdings bestehen auch wesentliche Unterschiede. In diesem Artikel werden die Unterschiede zwischen SharePoint 2010-Projekten und ASP.NET-Projekten beschrieben, besonders in Bezug auf die teambasierte Entwicklung. Darüber hinaus werden in diesem Artikel Aspekte erklärt, die bei der Entwicklung von SharePoint-Lösungen und deren Übertragung zwischen unterschiedlichen Umgebungen (z. B. Entwicklungs-, Erstellungs-, Integrations-, Test-, Qualitätssicherungs-, Staging- und letztlich Produktionsumgebung) zu berücksichtigen sind.

Teams, die SharePoint 2010-Anpassungen erstellen, wenden bei der Entwicklung von Projekten andere Herangehensweisen an, je nach Größe und Hintergrund des Entwicklungsteams sowie Größe und Gegenstand des Projekts. Da bei der Vorbereitung und Umsetzung eines teambasierten Entwicklungsmodells für SharePoint 2010-Projekte viele verschiedene Faktoren zusammenspielen, kann Ihnen dieser Artikel kein Patentrezept für die richtige Vorgehensweise bieten. Vielmehr sollten die Entwickler und Entwicklungsleiter die Überlegungen in diesem Artikel aufgreifen, um daraus einen Prozess und einen Leitfaden zu entwickeln, der der Größe ihres jeweiligen Entwicklungsteams, dessen Hintergrund und dem Typ des Projekts entspricht.

Verbesserungen für Entwickler in SharePoint 2010

Microsoft hat großen Aufwand in die Verbesserung der Tools für Entwickler in SharePoint 2010 gesteckt. Die wichtigste Verbesserung für Entwickler besteht darin, dass Microsoft Visual Studio 2010 nun erstklassige systemeigene Entwicklungstools enthält. Dank dieser umfassenden neuen Unterstützung für die SharePoint 2010-Entwicklung in Visual Studio 2010 können Entwickler jetzt auch problemlos Unternehmenslösungen für Quellcodeverwaltung nutzen, z. B. Microsoft Visual Studio Team Foundation Server 2010. Zudem hat Microsoft Microsoft SharePoint Designer 2010 dahin gehend verbessert, dass Export und Wiederverwendung von bestimmten Anpassungen unterstützt werden.

Abgesehen von den neuen und verbesserten Tools bietet SharePoint 2010 jetzt den Vorteil, dass es nicht mehr nur in einer Serverumgebung für die lokale Entwicklung installiert werden kann, wie dies bei Windows SharePoint Services 3.0 und Office SharePoint Server 2007 der Fall war, sondern Entwickler können SharePoint 2010 jetzt auf einem Clientbetriebssystem installieren (Windows 7 x64, Windows Vista Service Pack 1 x64 und Windows Vista Service Pack 2 x64). Das macht die Wartung und den Einstieg für viele von uns einfacher.

Beim Erstellen von benutzerdefinierten Lösungen in SharePoint 2010 können Entwickler sehr komplexe Lösungen schaffen, so genannte Farmlösungen, die von einem Administrator auf dem Server bereitgestellt werden. Sie können aber auch Lösungen mit eingeschränkter Sicherheitsstufe mit begrenztem Umfang erstellen, die keinen Farmadministrator erfordern. Websitesammlungsadministratoren können Lösungen mit eingeschränkter Sicherheitsstufe bereitstellen, aktivieren und deaktivieren. Dadurch wird der Zeitaufwand für die Entwicklung und Bereitstellung von benutzerdefinierten Lösungen erheblich verringert, und einige annehmbare Kompromisse werden berücksichtigt.

Traditionell werden die meisten benutzerdefinierten SharePoint-Lösungen auf dem Server bereitgestellt, auf dem SharePoint installiert und konfiguriert ist. In SharePoint 2010 besteht jetzt die Möglichkeit, benutzerdefinierte Lösungen zu erstellen, die abseits des Servers ausgeführt werden, auf dem SharePoint ausgeführt wird, z. B. im Browser. Dazu wird Microsoft Silverlight oder ECMAScript (JavaScript, JScript) verwendet. Diese Option wird durch die Verwendung des neuen SharePoint-Clientobjektmodells ermöglicht.

SharePoint 2010 bietet außerdem neue Möglichkeiten für Probleme, die Entwickler mit früheren Versionen hatten, beispielsweise beim Upgraden von SharePoint-Features, Erzwingen von Abhängigkeiten zwischen zwei Bereitstellungspaketen und Vereinfachen des Protokollierens und Debuggens von benutzerdefinierten Lösungen. All diese Themen und vieles mehr werden in diesem Artikel behandelt.

Komponenten eines SharePoint-Projekts

SharePoint 2010 bietet zahlreiche Arten von Komponenten, mit denen die systemeigene SharePoint-Entwicklung erweitert und angepasst werden kann. Entwickler können drei Arten von Komponenten erstellen:

Assemblys Viele Elemente in SharePoint erfordern benutzerdefinierten Code. Hierzu gehören codebasierte Workflows, Feldtypen, Webparts, Ereignisempfänger und Zeitgeberaufträge, um nur einige zu nennen.
Deklarative Lösungen Neben benutzerdefiniertem Code baut SharePoint 2010 auch in hohem Maße auf deklarativen Lösungen auf. In diesen Komponenten wird XML-Code verwendet, der entweder SharePoint anweist, eine bestimmte Aktion auszuführen (wie etwa bei Featureelementmanifesten) oder eine Komponente definiert (wie bei Websitespalten oder Inhaltstypen).
Ressourcen In der Regel werden Komponenten durch andere Ressourcen referenziert, etwa Bilder, externe Skriptbibliotheken, CSS-Dateien, Gestaltungsvorlagen, Inhaltsseiten (ASPX-Dateien) und Benutzersteuerelemente (ASCX-Dateien).

Beim Erstellen von benutzerdefinierten Komponenten in SharePoint 2010 erstellt der Entwickler selten nur einen dieser Komponententypen isoliert. Beispielsweise wird eine XML-Datei (*.webpart), die deklarativ ist, im Webpartkatalog bereitgestellt, obwohl ein herkömmliches Webpart vollständig in einer Assembly enthalten ist.

Implementierungsoptionen für SharePoint-Projekte

Bevor Sie die Arbeit an einem SharePoint 2010-Projekt aufnehmen, sollten Sie die unterschiedlichen Implementierungsoptionen verstehen, die Entwicklungsteams zur Verfügung stehen. Eines der wichtigsten Themen ist dabei, welche Vorteile, Nachteile und Auswirkungen der Implementierungspfad hat, der für ein Projekt ausgewählt wird, bevor das Projekt beginnt.

Die beiden Projektimplementierungsoptionen sind die SharePoint-Anpassung und die SharePoint-Entwicklung. Diese werden in den folgenden Abschnitten erläutert. Es ist allerdings nicht erforderlich, bei der einmal gewählten Implementierungsoption zu bleiben – in den meisten Projekten werden beide Optionen in einem mehr oder weniger großen Umfang angewendet. Bevor Sie sich jedoch mit diesen beiden Optionen beschäftigen, ist es wichtig, einen weiteren Zusammenhang zu verstehen, der sich auf beide Optionen auswirkt: den Unterschied zwischen angepassten Dateien und nicht angepassten Dateien.

Grundlegendes zu angepassten und nicht angepassten Dateien in SharePoint

Wenn eine neue SharePoint-Website bereitgestellt wird, sei es als Website auf oberster Ebene innerhalb einer neuen Websitesammlung oder als Unterwebsite innerhalb einer vorhandenen Websitesammlung, befinden sich die meisten Dateien im nicht angepassten Status. Das bedeutet: obwohl die Datei im virtualisierten Dateisystem einer SharePoint-Website in der Inhaltsdatenbank vorhanden ist und von SharePoint Designer 2010 aus gesehen wird, zeigt der Eintrag in der Inhaltsdatenbank einfach nur auf die Datei im Dateisystem, auf der sie basiert. Diese Datei wird auch als Vorlagendatei oder Dateidefinition bezeichnet. Wenn in einer SharePoint-Website eine darauf basierende neue Datei erstellt wird – dies wird auch als Bereitstellen der Datei bezeichnet –, dient die Datei nun als Quelle für diejenige Datei, die sich in der Inhaltsdatenbank befindet. Die Datei hat den Status nicht angepasst, solange ihre Quelle nicht mithilfe von SharePoint Designer 2010 oder anderweitig über die SharePoint-API verändert wird.

Eine Datei kann auch eine angepasste Datei werden. Die gängigste Methode zum Anpassen einer Datei besteht darin, sie in SharePoint Designer 2010 zu öffnen, sie nach Bedarf zu ändern und dann zu speichern. Speichert ein Benutzer eine Datei in SharePoint Designer 2010, wird die Quelle der aktualisierten Datei in der Inhaltsdatenbank gespeichert. Bei nachfolgenden Anforderungen der Datei wird deren Quelle aus der Inhaltsdatenbank abgerufen und nicht aus dem Dateisystem. Wenn Sie beispielsweise Ihrer SharePoint-Lösung eine Instanz von default.master hinzufügen, wird eine Kopie der Vorlagendatei default.master, die sich im Dateisystem befindet, mit der Lösung bereitgestellt. Wenn Sie jedoch default.master anpassen, wird die bearbeitete Version der Inhaltsdatenbank hinzugefügt. Bei allen zukünftigen Anforderungen wird die Datei aus der Kopie in der Inhaltsdatenbank abgerufen und nicht aus dem Dateisystem. Abbildung 1 veranschaulicht diesen Prozess der Anpassung und des anschließenden Abrufs aus der Inhaltsdatenbank.

Abbildung 1. SharePoint 2010-Prozess zum Abrufen von Dateien

SharePoint 2010-Prozess zum Abrufen von Dateien

Vielleicht sind Ihnen die älteren Bezeichnungen aus früheren Versionen von SharePoint bekannt, die inzwischen durch die Begriffe "angepasst" und "nicht angepasst" ersetzt worden sind. Damals wurde für "angepasst" der Begriff verwaist und für "nicht angepasst" der Begriff nicht verwaist verwendet.

Weitere Informationen finden Sie unter Grundlegendes zu angepassten und nicht angepassten Dateien und deren Erstellung in Windows SharePoint Services 3.0. In diesem Artikel geht es zwar um Windows SharePoint Services 3.0 und Office SharePoint Server 2007, doch gelten alle behandelten Konzepte und Charakteristika auch für SharePoint 2010.

Projektimplementierungsoption 1: SharePoint-Anpassung

Bei der ersten Projektimplementierungsoption wird ausschließlich mit angepassten Dateien gearbeitet. Das bedeutet, die Dateien werden mithilfe der SharePoint-API oder eines Tools wie etwa SharePoint Designer 2010 direkt auf der SharePoint-Website erstellt. Diese Vorgehensweise beansprucht in der Regel weitaus weniger Zeit als die Alternative und eignet sich mehr für Teams, die über durchschnittliche Kompetenz in der SharePoint-Entwicklung verfügen.

Bei der Anpassung profitieren die Entwickler zudem von der WYSIWYG-Darstellung (what-you-see-is-what-you-get) im Entwurfsmodus von SharePoint Designer 2010. Hier erhalten Entwickler eine Vorschau auf das Erscheinungsbild der Seite im gerenderten Zustand.

Die größte Herausforderung bei der SharePoint-Anpassung betrifft die Portierbarkeit und Wiederverwendbarkeit von benutzerdefinierten Lösungen. Nachdem eine Datei angepasst worden ist (oder wenn eine Datei zuerst im angepassten Status vorliegt), ist sie ausschließlich in der Inhaltsdatenbank mit dem Inhalt der Website vorhanden. Daher ist eine einfache Sicherung der Inhaltsdatenbank aus einer Umgebung in eine andere keine praktikable Option, da hierbei der Inhalt in der Zielumgebung überschrieben wird. Das macht die Verschiebung zwischen den einzelnen Umgebungen kompliziert, z. B. zwischen Entwicklerarbeitsstationen, in eine zentrale Buildumgebung, in die Test-, die Staging- und letztlich die Produktionsumgebung. Das ist zwar machbar, aber nur mit einigem manuellen Aufwand oder mit benutzerdefinierten Skripts.

Eine weitere Schwierigkeit, die größere negative Auswirkungen haben kann, besteht in der Tatsache, dass Anpassungen direkt in der Produktionsumgebung erfolgen, d. h. ohne die Möglichkeit des Testens vor dem Festschreiben der Änderungen. Bevor ein Entwickler die Chance hat, die Auswirkungen von Änderungen zu beobachten, sind diese Änderungen bereits im Produktionssystem festgeschrieben, da sie in einer Liveumgebung vorgenommen wurden. Das bedeutet, dass alle Änderungen sofort von allen Benutzern gesehen werden. Was diese Situation weiter erschwert, ist, dass Dateiänderungen nicht immer problemlos oder aber überhaupt nicht rückgängig gemacht werden können.

Projektimplementierungsoption 2: SharePoint-Entwicklung

Bei der zweiten Implementierungsoption wird angestrebt, die betroffenen Dateien im nicht angepassten Status zu halten. Um den nicht angepassten Status von Dateien in einer SharePoint-Website aufrechtzuerhalten, müssen Sie die Dateien als physikalische Dateien im Dateisystem erstellen. Nachdem Sie die Dateien erstellt und dem Dateisystem auf den SharePoint-Front-End-Webservern hinzugefügt haben, müssen Sie sie irgendwie in die Website einfügen. Dazu verwenden Sie SharePoint-Features, insbesondere das Module-Element und das zugehörige File-Element in der Elementmanifestdatei eines Features. Durch Verwenden des Featureschemas können Entwickler Dateien in SharePoint bereitstellen, die auf den in dem Feature verwendeten Dateivorlagen basieren.

Ein Vorteil dieser Vorgehensweise liegt darin, dass sie gut für Entwicklungsteams geeignet ist, die einen strukturierten Bereitstellungsprozess für die Verschiebung von Projekten von der Entwicklungsumgebung auf einen zentralen Buildserver zur Integration mit anderen Komponenten und von dort zur Test-, Staging- und schließlich zur Produktionsumgebung nutzen. Da diese Dateien im Dateisystem vorhanden sind, eignet sich diese Vorgehensweise auch gut für Unternehmenslösungen für Quellcodeverwaltung, z. B. Microsoft Visual Studio Team Foundation Server 2010.

Da sich diese Dateien im Dateisystem befinden und mithilfe von Features bereitgestellt werden, die ebenfalls im Dateisystem vorhanden sind, können die Dateien relativ einfach gepackt und in den verschiedenen Umgebungen bereitgestellt werden.

Projektbereitstellungsoptionen für SharePoint

Nachdem der Entwickler oder das Entwicklungsteam eine benutzerdefinierte Lösung für SharePoint erstellt hat, ist die nächste Frage: Kann die Lösung in einer Umgebung implementiert werden? Besteht die Lösung auf angepassten Dateien, die über den Browser oder mithilfe von SharePoint Designer 2010 erstellt und angepasst wurden, müssen Sie diese Dateien manuell oder mit einer Kombination aus manuellen Schritten und benutzerdefinierten Skripts zwischen den Umgebungen verschieben, je nachdem, was erstellt wurde.

Wenn der Entwicklungsansatz mit nicht angepassten Dateien gewählt wurde, haben die Entwickler zwei Optionen zur Bereitstellung einer Lösung auf den SharePoint-Servern in der Farm. Bei der einen Option werden Farmlösungen verwendet. Dabei handelt es sich um die gleiche Art von Bereitstellung durch Packen von Lösungen, die auch in Windows SharePoint Services 3.0 und Office SharePoint Server 2007 verfügbar ist. Die andere Option ist neu in SharePoint 2010: Lösungen mit eingeschränkter Sicherheitsstufe.

Verwenden von SharePoint-Farmlösungen

Eine Farmlösung ist ein Paket, das alle Dateien enthält, die auf dem Server bereitgestellt werden müssen. Das Paket ist eine Microsoft-CAB-Datei mit der Dateinamenerweiterung *.wsp. Zusätzlich zu den Dateien in der benutzerdefinierten Lösung enthält das Paket eine Datei manifest.xml, durch die SharePoint angewiesen wird, welche Dateien sich in dem Paket befinden und wo sie bereitgestellt werden müssen. Mit Farmlösungen können Assemblys und beliebige Typen von SharePoint-Ressourcen auf den SharePoint-Servern in der Farm bereitgestellt werden. Im Folgenden werden die Vor- und Nachteile der Verwendung von Farmlösungen beschrieben.

Vorteile von Farmlösungen

Hinsichtlich des Typs der Lösung, Datei oder Ressource, die von einer Farmlösung auf dem Server bereitgestellt werden kann, gibt es keine Beschränkungen.
Assemblys in einer Farmlösung haben Zugriff auf die gesamte SharePoint-API.
Benutzerdefinierter Code, der mithilfe einer Farmlösung bereitgestellt wurde, wird schneller ausgeführt als Code, der mit einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt wurde, da er nicht der mit dem Benutzercodedienst zusammenhängenden Ressourcenüberwachung unterliegt.

Nachteile von Farmlösungen

Sie müssen von einem Farmadministrator bereitgestellt werden.
Da Assemblys, die über Farmlösungen bereitgestellt werden, Zugriff auf die gesamte SharePoint-API haben, müssen diese Assemblys einer sehr sorgfältigen Codeprüfung unterzogen werden.
Da Farmlösungen nicht überwacht werden, können sie Auswirkungen auf die Seite haben, in der sie ausgeführt werden, oder sogar auf den Anwendungspool, von dem die SharePoint-Website gehostet wird.

Verwenden von SharePoint-Sandkastenlösungen

Mit Sandkastenlösungen – neu in SharePoint 2010 – können viele der Schwierigkeiten im Zusammenhang mit Farmlösungen umgangen werden. Ein Websitesammlungsadministrator kann diese Lösungen über einen Browser in einer Websitesammlung hinzufügen und bereitstellen. Das verkürzt den Zeitaufwand für die Entwicklung und Bereitstellung, da der Kunde, in der Regel ein Websitesammlungsadministrator, und der Entwickler bei der Bereitstellung keine Administratoren hinzuziehen müssen. Dies sind wahrscheinlich die einzigen Lösungstypen, die in einer gehosteten Umgebung wie etwa Microsoft SharePoint Online Standard (BPOS-S) erlaubt sind; dagegen werden Farmlösungen von Microsoft SharePoint Online Dedicated (BPOS-D) unterstützt. Die mithilfe einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellten Ressourcen sind außerdem von den Prozessen isoliert, von denen die Anwendungspools gehostet werden. Sollte also ein katastrophaler Fehler auftreten, betrifft dieser nur das Element, von dem das Problem ausgelöst wurde, und nicht die gesamte Seite oder den Anwendungspool.

Diese Flexibilität hat allerdings ihren Preis. Sandkastenlösungen haben keinen Zugriff auf die gesamte SharePoint-API, können nur begrenzte Elemente bereitstellen und unterliegen einer restriktiveren Codezugriffssicherheits-Richtlinie (Code Access Security, CAS). Weitere Informationen zu CAS und SharePoint finden Sie im Administrator- und Entwicklerhandbuch zur Codezugriffssicherheit in SharePoint Server 2007. In diesem Artikel geht es zwar um Windows SharePoint Services 3.0 und Office SharePoint Server 2007, doch gelten alle behandelten Konzepte auch für SharePoint 2010. Darüber hinaus stehen SharePoint-Administratoren Tools wie die automatische Ressourcenüberwachung, -zuweisung und -verwaltung zur Verfügung, mit denen sie sicherstellen können, dass die Integrität der Server in der Farm nicht durch benutzerdefinierten Code gefährdet wird, der ohne ihr Wissen auf den Servern bereitgestellt wird.

Weitere Informationen zu Lösungen mit eingeschränkter Sicherheitsstufe finden Sie unter Sandkastenlösungen im SharePoint 2010 SDK. Daneben ist der Leitfaden zu SharePoint der Microsoft-Gruppe Patterns & Practices eine ausgezeichnete Informationsquelle, wenn Sie mehr über Lösungen mit eingeschränkter Sicherheitsstufe erfahren möchten. Im Folgenden werden die Vor- und Nachteile der Verwendung von Lösungen mit eingeschränkter Sicherheitsstufe beschrieben.

Vorteile von Sandkastenlösungen

Sandkastenlösungen können ohne die Mitwirkung eines Farmadministrators bereitgestellt werden. Dadurch verkürzt sich der Zeitaufwand vom Entwurf bis zur Entwicklung und letztlich bis zur Bereitstellung.
Der Inhalt einer Lösung mit eingeschränkter Sicherheitsstufe wird überwacht, sodass im Falle eines Fehlers nicht der gesamte Webprozess oder die Seite abstürzt, in der die Ressource enthalten ist, sondern nur dieser spezielle Teil der Seite kontrolliert abstürzt.

Nachteile von Sandkastenlösungen

Typischerweise funktionieren Lösungen mit eingeschränkter Sicherheitsstufe nur innerhalb der Grenzen der Websitesammlungen, in denen sie bereitgestellt werden.
Sie sind langsamer als Ressourcen, die in einer Farmlösung bereitgestellt wurden, da sie der automatischen Ressourcenüberwachung und -verwaltung unterliegen.
Entwickler können nicht alle Elemente in einer Lösung mit eingeschränkter Sicherheitsstufe erstellen und bereitstellen, die in einer Farmlösung erstellt und bereitgestellt werden können, z. B. Workflows, die mithilfe von Visual Studio 2010 entwickelt werden, oder Zeitgeberaufträge. Außerdem können Lösungen mit eingeschränkter Sicherheitsstufe keine Rechte auswerten, nicht mit der Farm interagieren und keine Webanwendungen hosten.

Unterschied zwischen SharePoint-Projektentwicklung und Entwicklung mit ASP.NET

Da SharePoint 2010 eine ASP.NET-Anwendung ist, lassen sich viele Techniken und Prozesse, die ASP.NET-Entwickler und -Entwicklungsteams anwenden, auf SharePoint 2010-Projekte übertragen. Aufgrund bestimmter Aspekte von SharePoint 2010 müssen jedoch einige Prozesse und Erwartungen angesprochen werden, wenn man von der Projektentwicklung mit ASP.NET kommt. Ein Beispiel hierfür ist, dass das Schema der gespeicherten Inhalte getrennt vom tatsächlichen Inhalt aufbewahrt werden muss. In einer traditionellen ASP.NET-Anwendung bedeutet das, dass die Datenbanktabellen mit Skripts modifiziert werden müssen. Zum Speichern von Inhalten können in SharePoint-Projekten SharePoint-Listen statt Datenbanktabellen verwendet werden. Die Schwierigkeit bei dieser Vorgehensweise liegt darin, dass das Schema der Liste und deren Inhalt in der gleichen Datenbank gespeichert werden.

Das Schema der Liste kann geändert werden, allerdings müssen dazu benutzerdefinierter Code oder benutzerdefinierte Skripts geschrieben werden, die während des Upgradeprozesses ausgeführt werden. Behalten Sie dies im Hinterkopf, wenn Sie ein benutzerdefiniertes SharePoint-Projekt entwerfen, das primär auf einem Listenschema aufbaut. Eine Möglichkeit, dieses Problem zu umgehen, besteht darin, von Business-Konnektivitätsdienste (Business Connectivity Services) bereitgestellte externe Inhaltstypen und externe Listen zu verwenden. Ein externer Inhaltstyp beschreibt das Schema und wie eine Verbindung zu den Daten hergestellt wird, die in einer Datenbanktabelle vorhanden sind. Eine externe Liste verwendet den externen Inhaltstyp und macht die Daten in der externen Datenbank für den Benutzer als SharePoint-Liste sichtbar. Diese externe Liste ist auch über die SharePoint-API verfügbar. Bei dieser Vorgehensweise können Entwickler die gleichen Verfahren anwenden wie in ihren ASP.NET-Projekten.

Einer der Hauptunterschiede zwischen der Entwicklung mit ASP.NET und der SharePoint 2010-Entwicklung besteht darin, wie die Entwicklungstools verwendet werden. In einem ASP.NET-Projekt öffnet der Entwickler die Website in Visual Studio 2010, bearbeitet die Codedateien direkt und debugt dann die Codedateien direkt. Im Unterschied dazu kann der Entwickler bei SharePoint 2010 keine SharePoint 2010-Website in Visual Studio 2010 öffnen. Vielmehr erstellt er Komponenten, die in SharePoint 2010 bereitgestellt und dann in SharePoint ausgeführt werden. Nach der Bereitstellung der Lösungskomponenten in SharePoint 2010 wird der Visual Studio 2010-Debugger an die Webprozesse angekoppelt, von denen die SharePoint 2010-Website (in der der benutzerdefinierte Code ausgeführt wird) gehostet wird, um die Lösung zu debuggen.

Beibehalten von Konfigurationseinstellungen für SharePoint-Projekte

Eine Frage, die sich Entwicklern in SharePoint-Projekten häufig stellt, ist, wo die Konfigurationseinstellungen gespeichert werden sollen. Beispielsweise müssen manche Projekte eine Verbindung zu einer Datenbank oder einem Webdienst herstellen oder Benutzernamen und -kennwörter speichern. Entwickler haben zahlreiche Möglichkeiten, Konfigurationsinformationen in einem SharePoint-Projekt zu speichern und zu verwalten. Die folgende Liste enthält einige Vorschläge:

SharePoint-Listen (SPList) Eine Liste kann als Datenbanktabelle zum Speichern von Informationen dienen. Dies empfiehlt sich, wenn viele der Einträge mit einem ähnlichen Schema beibehalten werden müssen. Listen werden auch über die Benutzeroberfläche verfügbar gemacht (allerdings können sie aus der Navigation ausgeblendet werden), was für bestimmte Szenarien möglicherweise ungeeignet ist.
Eigenschaftenbehälter von SharePoint-Websites (SPWeb) oder -Listen (SPList) SharePoint-Websites und -Listen enthalten außerdem einen Eigenschaftenbehälter, der aus Name/Wert-Paaren besteht. Diese werden nicht über die Benutzeroberfläche verfügbar gemacht, sondern können über benutzerdefinierten Code verwendet und geändert werden.
Beibehaltene SharePoint-Objekte (SPPersistedObject) Anhand von beibehaltenen Objekten können Entwickler eine serialisierbare Klasse erstellen und an bestimmte Objekte anfügen, z. B. an die Farm, eine Webanwendung oder eine Websitesammlung. Diese Objekte werden dann von SharePoint beibehalten und können mithilfe von benutzerdefiniertem Code gelesen und bearbeitet werden.
Externe Datenbank Wie bei jedem Typ Anwendung können Entwickler eine benutzerdefinierte Datenbank zum Speichern von Konfigurationsinformationen in einer benutzerdefinierten externen Datenbank verwenden.

Im Leitfaden Entwickeln von Anwendungen für SharePoint 2010, der von der Microsoft-Gruppe Patterns & Practices bereitgestellt wurde, wird das Thema Beibehaltung der Konfigurationsinformationen behandelt. Dieser Leitfaden bietet außerdem eine wiederverwendbare Bibliothek zur Verwaltung von Konfigurationsinformationen.

Entwicklungstools für SharePoint-Entwickler und -Implementierer

Microsoft hat die Tools, die Entwicklern und Implementierern für SharePoint 2010 zur Verfügung stehen, erheblich verbessert. Zwei der wichtigsten Tools, SharePoint Designer 2010 und Visual Studio 2010, wurden zu erstklassigen Tools für Poweruser, Websitebesitzer und Entwickler geschmiedet, die für verschiedene Zielgruppen vorgesehen sind.

Verbesserungen in SharePoint Designer 2010

Microsoft hat 32-Bit- und 64-Bit-Versionen von SharePoint Designer 2010 als kostenlose Downloads von der Microsoft-Website für alle Benutzer zur Verfügung gestellt. SharePoint Designer 2010 ist gegenüber der Vorgängerversion SharePoint Designer 2007 umfassend aufgerüstet worden. SharePoint Designer 2010 ist primär für die Aufgaben, Funktionen und Features einer SharePoint-Website vorgesehen und ermöglicht es Entwicklern und Websitebesitzern, Elemente wie Websites, deklarative Workflows, Websitespalten, Inhaltstypen, Listen, Seiten und Gestaltungsvorlagen rasch und einfach zu erstellen.

Hinweis
Alle Änderungen an einer Website, die mithilfe von SharePoint Designer 2010 durchgeführt werden, erfolgen über HTTP/HTTPS. Deshalb werden die Änderungen in der Inhaltsdatenbank der Website gespeichert. Das bedeutet, dass alle Änderungen Anpassungen sind.

Anders als in der früheren Version von SharePoint Designer können die Benutzer jetzt jedoch bestimmte Ressourcen, z. B. Workflows, als Vorlagen speichern, auf ihre lokale Arbeitsstation exportieren und manuell oder mithilfe einer Farm oder einer Lösung mit eingeschränkter Sicherheitsstufe (je nachdem, was exportiert wird) in die Bereitstellung in einer anderen Umgebung einschließen.

Über die Zentraladministration von SharePoint 2010 haben Farmadministratoren außerdem die Möglichkeit, die Verwendung von SharePoint Designer 2010 (und spezieller Aktionen, die damit ausgeführt werden können) in allen Websitesammlungen in einer bestimmten Webanwendung zu blockieren. Hat der Farmadministrator die Verwendung für eine Webanwendung zugelassen, können Websitesammlungsadministratoren die Verwendung über die Seite Websiteeinstellungen der Websitesammlung auf Websitesammlungsebene weiter beschränken.

Hinweis
SharePoint Designer 2010 interagiert nicht mit dem Dateisystem, weder lokal noch auf der Arbeitsstation des Benutzers oder auf den SharePoint-Servern. Die Interaktion findet direkt mit der SharePoint-Website statt. Das bedeutet, dass SharePoint Designer 2010 nicht mit einer Unternehmenslösung für Quellcodeverwaltung interagieren kann.

Weitere Informationen finden Sie unter Verwenden von SharePoint Designer für die SharePoint-Entwicklung.

SharePoint-Entwicklungstools in Visual Studio 2010

Visual Studio 2010 ist die primäre Entwicklungsumgebung für die gesamte Entwicklung von benutzerdefiniertem Code und Ressourcen für SharePoint 2010. Die Versionen Visual Studio 2010 Professional, Visual Studio 2010 Premium und Visual Studio 2010 Ultimate enthalten systemeigene, erstklassige Entwicklungstools, Assistenten, Designer und Toolfenster zum Entwickeln von benutzerdefinierten Lösungen für SharePoint 2010. Visual Studio 2010 umfasst zahlreiche Projektvorlagen und Projektelementvorlagen, mit denen Entwickler Elemente wie Workflows, Inhaltstypen, Listenvorlagen oder Listendefinitionen, Listeninstanzen, Features, Ereignisempfänger und Webparts erstellen können.

Zudem können Entwickler eine neue Projektvorlage verwenden, mit der sie eine Lösung durch Importieren eines vorhandenen Lösungspakets (WSP-Datei) neu erstellen können. Visual Studio 2010 bietet ein neues Erweiterbarkeitsmodell namens Managed Extensibility Framework (MEF) sowie eine SharePoint 2010-Projektsystem-API. Mit dem MEF und der API können Entwickler Visual Studio 2010 erweitern und anpassen. Im Folgenden einige beliebte, von Microsoft und der Community unterstützte Projekte, in denen mithilfe von Visual Studio 2010 zusätzliche Funktionen für SharePoint-Entwickler hinzugefügt werden:

Mit Visual Studio 2010 können Entwicklungsteams darüber hinaus Projekte und Lösungen zu Unternehmenslösungen für Quellcodeverwaltung wie etwa Microsoft Visual Studio Team Foundation Server 2010 hinzufügen und ihre Entwicklung in ihre Prozesse für die Verwaltung des Softwareentwicklungs-Lebenzyklus (Software Development Lifecycle, SDL) und für die Anwendungslebenszyklus-Verwaltung (Application Lifecycle Management, ALM) integrieren.

Konfigurieren der typischen Umgebung für ein SharePoint-Entwicklungsteam

Mit SharePoint 2010 können Entwickler ihre Arbeitsstationen ganz nach Bedarf konfigurieren, um maximale Flexibilität zu gewinnen. Die Konfigurationsoptionen sind im Großen und Ganzen für alle Szenarien die gleichen, egal, ob für ein großes oder ein kleines Team oder für eine Entwicklungsabteilung, die nur aus einer Person besteht. In den folgenden Abschnitten erfahren Sie, was Sie für die Entwicklung in SharePoint brauchen, welche Optionen zur Verfügung stehen und wie Sie SharePoint-Projekte testen.

Konfiguration der Arbeitsstation für die SharePoint-Entwicklung

Die Projektimplementierungsoption, für die Sie sich entschieden haben, und das Bereitstellungsziel der Lösung bedingen, wie die Arbeitsstation des Entwicklers zu konfigurieren ist. Bei einem reinen Anpassungsmodell müssen die Entwickler lediglich SharePoint Designer 2010 auf ihrer Arbeitsstation installieren, da sie eine Verbindung zu einer SharePoint-Website herstellen werden, die sich nicht auf ihrer Arbeitsstation befindet. Beim Entwicklungsmodell müssen die Entwickler SharePoint 2010 auf ihrer Arbeitsstation installieren.

Auf den Systemen der Entwickler muss eine lokale Instanz von SharePoint 2010 installiert sein, damit Lösungen mit SharePoint 2010 entwickelt werden können. Der Grund hierfür ist, dass mit dem neuen SharePoint-Entwicklungstools in Microsoft Visual Studio 2010 nur solche SharePoint-Websites bereitgestellt, debugt und verwendet werden können, die auf dem gleichen Computer ausgeführt werden wie Visual Studio. Daher gibt es keine systemeigene Unterstützung für das Remotedebuggen von SharePoint-Projekten.

Die Arbeitsstation eines Entwicklers wird in der Regel so konfiguriert: entweder durch Installieren von SharePoint auf dem nativen Betriebssystem oder durch Installieren von SharePoint innerhalb eines virtuellen Computers. Da SharePoint 2010 eine reine 64-Bit-Anwendung ist, wird dafür 64-Bit-Host- und -Client-Unterstützung benötigt. Eine weitere Möglichkeit besteht darin, in einer VHD-Datei (Virtual Hard Drive, virtuelle Festplatte) zu starten, vorausgesetzt, das Hostbetriebssystem auf der Arbeitsstation ist entweder Windows 7 oder Windows Server 2008. Dies ähnelt dem herkömmlichen Dual-Boot-Verfahren. Weitere Informationen zum Konfigurieren dieses Setups finden Sie unter Starten von einer virtuellen Festplatte in Windows 7 im Microsoft TechNet.

Die Alternative zum virtuellen Verfahren besteht darin, SharePoint als systemeigene Anwendung zu installieren. Das heißt, Sie installieren Windows Server 2008 entweder direkt auf der Arbeitsstation oder mithilfe einer neuen Funktion: Ab der Produktversion SharePoint 2010 kann SharePoint unter einem clientbasierten 64-Bit-Betriebssystem installiert werden, das entweder Windows Vista Service Pack 1 x64, Windows Vista Service Pack 2 x64 oder Windows 7 x64 sein kann. Die Installationsschritte sind unterschiedlich, je nachdem, ob Sie SharePoint 2010 unter einem serverbasierten oder unter einem clientbasierten Betriebssystem installieren. Installationsanweisungen finden Sie unter Einrichten der Entwicklungsumgebung für SharePoint 2010 unter Windows Vista, Windows 7 und Windows Server 2008.

Eine sehr hilfreiche Funktion von SharePoint 2010 besteht darin, dass es alle erforderlichen Softwarekomponenten herunterladen und installieren und den Hostcomputer automatisch konfigurieren kann. Das vereinfacht den Installationsvorgang für den Entwickler, da er nicht nach unterschiedlichen Installationsdateien suchen muss und die Gewissheit hat, dass er die richtigen und passenden Versionen erhält.

Hinweis
Was nicht installiert wird, ist das ADO.NET Data Services-Update für .NET Framework 3.5 SP1 für Windows 7 und Windows Server 2008 R2. Dieses wird benötigt, um einen von SharePoint bereitgestellten REST-Webdienst zum Lesen von SharePoint-Listen und Schreiben in SharePoint-Listen mithilfe von REST-Verfahren zu aktivieren.

Konfiguration für das SharePoint-Entwicklungsteam

SharePoint-Entwickler arbeiten meist am effizientesten, wenn sie nach dem traditionellen Modell der isolierten Entwicklung vorgehen. Dabei sollte jeder Entwickler im Team die gleiche Konfiguration haben, die unter Konfiguration der Arbeitsstation für die SharePoint-Entwicklung beschrieben wird. Bei dieser Konfiguration ist jede Arbeitsstation im Prinzip eine eigene "Mini"-SharePoint-Farm. Auf jeder Arbeitsstation kann eine eigene lokale Instanz von Microsoft SQL Server ausgeführt werden, oder jede Arbeitsstation kann eine Verbindung zu einer zentralen freigegebenen Instanz herstellen. Entscheidet sich das Team für die Verwendung einer freigegebenen Instanz von SQL Server, müssen Sie sicherstellen, dass nicht alle Entwickler-Arbeitsstationen eine Verbindung zur gleichen Farm herstellen. Sonst wird nämlich Code, den ein Entwickler auf einer Arbeitsstation bereitstellt, auf allen Arbeitsstationen bereitgestellt, wodurch unerwünschte Ergebnisse für andere Entwickler entstehen, die an anderen Lösungen arbeiten. Stattdessen soll jede Arbeitsstation eine eigene Farm haben und die freigegebene Instanz von SQL Server einfach als freigegebene Ressource nutzen.

Nachdem eine Komponente auf einer Arbeitsstation entwickelt worden ist, wird sie in eine Unternehmenslösung für Quellcodeverwaltung eingecheckt, z. B. Microsoft Visual Studio Team Foundation Server 2010. Ein Entwicklungsleiter kann dann einen zentralen Buildserver, auch Integrationsserver genannt, verwenden, um den aktuellen Code abzurufen, die Lösung neu zu erstellen und sie für Integrationstest mit anderen Komponenten bereitzustellen. Weitere Informationen zum Erstellen von SharePoint 2010-Projekten mit Microsoft Visual Studio Team Foundation Server 2010 finden Sie unter How to Build SharePoint Projects with TFS Team Build.

Nach dem Integrationstest auf dem Buildserver kann das Paket verschoben und in einer Test- oder Qualitätssicherungsumgebung getestet werden. Nach Abschluss der Testphase kann das Paket in der Stagingumgebung und schließlich in der Produktionsumgebung bereitgestellt werden.

Testen von SharePoint-Entwicklungsprojekten

Es hat sich generell bewährt, das Testen von benutzerdefinierten entwickelten Komponenten weitest gehend zu automatisieren. Es gibt zahlreiche Verfahren zum Testen von Projekten. Alle Testmethoden, die Entwickler für SharePoint-fremde Projekte anwenden, z. B. Komponententests, fortlaufende Integration, Belastungstests, Auslastungstests und Mocking, sollten in einer SharePoint-Umgebung funktionieren.

Die Microsoft-Gruppe Patterns & Practices hat einen Leitfaden für SharePoint 2010 veröffentlicht, Entwickeln von Anwendungen für SharePoint 2010, der umfassende Hilfestellung für das Testen von SharePoint 2010-Projekten bietet. Diese Dokumentation enthält Anleitungen für die folgenden Bereiche:

Komponententests
Integrationstests
Fortlaufende Integrationstests
Webtests
Belastungstests
Funktionstests
Buildüberprüfungstests
Auslastungstests/Skalierungstests
Benutzerakzeptanztests
Verwenden von SharePoint 2010-Pseudobjekten (Mocking)
Testen mit dem Moles-Framework

Bereitstellungsmodelle für SharePoint

Wie bereits erwähnt, können Sie beim Erstellen von benutzerdefinierten Komponenten bei der SharePoint 2010-Entwicklung eines von zwei Bereitstellungsmodellen wählen: Farmlösungen oder Lösungen mit eingeschränkter Sicherheitsstufe.

Wird bei einem Projekt die Implementierung durch SharePoint-Anpassung angewendet, befinden sich alle Websiteobjekte und Anpassungen in der SharePoint-Inhaltsdatenbank. Diese Option wird typischerweise gewählt, wenn ein wiederkehrender Entwicklungsprozess – der das Durchlaufen der Entwicklungs-, Integrations-, Test-, Qualitätssicherungs-, Staging- und Produktionsprozesse umfasst – nicht erforderlich ist. Wird jedoch die Implementierung durch Anpassung gewählt, und es gibt Änderungen, die diesen sich wiederholenden Entwicklungsprozess durchlaufen müssen, müssen die angepassten Objekte in jeder Umgebung dupliziert werden, während der Prozess fortschreitet. Oder die Entwickler müssen benutzerdefinierte Skripts schreiben, z. B. mithilfe von Windows PowerShell, um diesen Prozess zu extrahieren, zu replizieren und zu automatisieren.

Bereitstellen von SharePoint-Farmlösungen

Farmlösungen müssen der SharePoint-Farm von einem Farmadministrator hinzugefügt werden, der Zugriff auf die Konsole der SharePoint-Server hat. Der Grund hierfür ist, dass Lösungen zuerst mithilfe von Windows PowerShell-Cmdlets (Add-SPSolution) der Farm hinzugefügt werden müssen. Nach dem Hinzufügen zur Farm können die Lösungen über die Website für die Zentraladministration oder über ein weiteres Cmdlet (Install-SPSolution) bereitgestellt werden, wie im folgenden Windows PowerShell-Beispiel dargestellt.

$SolutionPackageName  = "WingtipDevProject.wsp"
# add the solution to the SharePoint solution store
Add-SPSolution -LiteralPath $SolutionPackageName
# deploy the solution globally
Install-SPSolution -Identity $SolutionPackageName -GACDeployment
# OR....
# deploy a solution to a specific Web application
Install-SPSolution -Identity $SolutionPackageName -WebApplication "http://intranet.wingtip.com" -GACDeployment

Nach der Bereitstellung eines Farmlösungspakets auf den Servern sind dessen Komponenten zur Verwendung verfügbar. Beispielsweise ist ein benutzerdefinierter Feldtyp sofort nach der Bereitstellung einsatzbereit, während ein Websitesammlungsfeature nur installiert und zur Aktivierung verfügbar gemacht ist.

Bereitstellen von Sandkastenlösungen

Die Bereitstellung von Lösungen mit eingeschränkter Sicherheitsstufe unterscheidet sich von der Bereitstellung von Farmlösungen. Ein Paket mit einer Lösung mit eingeschränkter Sicherheitsstufe muss in den Lösungskatalog hochgeladen werden, einen speziellen Katalog auf der Website auf oberster Ebene in einer Websitesammlung. Nur Websitesammlungsadministratoren sind berechtigt, Lösungen mit eingeschränkter Sicherheitsstufe in den Lösungskatalog hochzuladen. Sobald sich die Lösung mit eingeschränkter Sicherheitsstufe im Lösungskatalog befindet, muss sie aktiviert werden, damit der Inhalt (z. B. ein Webpart) zur Verwendung verfügbar ist. Durch Aktivieren einer Lösung mit eingeschränkter Sicherheitsstufe werden standardmäßig automatisch alle Features mit Websitesammlungsbereich aktiviert. Die Featureaktivierung kann jedoch mithilfe von Featureeigenschaften angepasst werden, die das Feature auf die Websitesammlungsebene beschränken.

Bereitstellung in Inhaltsverwaltungslösungen

Benutzerdefinierte Entwicklungsprojekte, die die Veröffentlichung von Websites oder Web Content Management (WCM) umfassen, bedürfen besonderer Erwähnung. Web Content Management in SharePoint Server 2010 enthält alle Funktionen und Technologien, mit denen Kunden ein Inhaltsverwaltungssystem (Content Management System, CMS) innerhalb der SharePoint-Plattform implementieren können. Ein CMS zeichnet sich durch die klare Trennung der Inhalte einer Website vom Code und vom Branding aus, über den bzw. das die Website implementiert wird. Manchmal hängen bestimmte Inhalte von anderen Inhalten der Website ab. Entwickler sollten die Inhalte und die sie unterstützenden Ressourcen, z. B. Gestaltungsvorlagen, Seitenlayouts, Brandingdateien und Assemblys, unbedingt voneinander getrennt halten. Inhalte sollten ausschließlich in einer Erstellungsumgebung entwickelt und erstellt werden. Der Prozess für die Bereitstellung, Aktualisierung und Verwaltung der benutzerdefinierten Komponenten in einem CMS-Projekt entspricht dem für eine typische SharePoint-Website für die Zusammenarbeit.

Häufig müssen Entwickler neuen Code oder neue Komponenten anhand von echten Inhalten aus der Praxis testen. Die beste Vorgehensweise in dieser Situation ist es, eine Kopie der Produktionsumgebung (bzw. bei sehr umfangreichen Implementierungen einen Teil der Produktionsumgebung) in einer Entwicklungsumgebung zu replizieren. Anschließend können die Entwickler ihre benutzerdefinierten Komponenten anhand dieser lokalen aktualisierten Kopie der Produktionswebsite testen.

Upgraden von bereitgestellten SharePoint-Projekten

Nach der Bereitstellung eines benutzerdefinierten SharePoint 2010-Projekts in der Produktionsumgebung ist irgendwann eine Aktualisierung einer oder mehrerer Komponenten des Projekts unausweichlich. Unterschiedliche Komponenten und Bereitstellungsmechanismen erfordern unterschiedliche Upgradeprozesse und -methoden. Der bereits erwähnte Leitfaden Entwickeln von Anwendungen für SharePoint 2010 der Microsoft-Gruppe Patterns & Practices bietet umfassende Hilfestellung beim Upgraden von SharePoint 2010-Projekten.

Problembehandlung für benutzerdefinierte Bereitstellungskomponenten

An bestimmten Punkten müssen Entwickler die für SharePoint 2010 erstellten benutzerdefinierten Lösungen debuggen oder darin vorkommende Fehler beheben. Microsoft hat SharePoint 2010 mit einer Reihe von Funktionen ergänzt, die Entwicklern hierbei helfen. Beispielsweise ist es jetzt einfacher, Einträge in den Vereinheitlichten Protokollierungsdienst von SharePoint (Unified Logging Service, ULS) zu schreiben. Dieser enthält das Serverereignisprotokoll und Textdateien, die auf allen Servern vorhanden sind. Benutzerdefinierte Lösungen können durch Verwendung der SharePoint-API in Assemblys, die in Farmlösungen bereitgestellt sind, direkt in die Protokolle schreiben. Sandkastenlösungen können ebenfalls in Protokolldateien schreiben, und zwar über ein Proxyobjekt mit voller Vertrauenswürdigkeit.

SharePoint 2010 enthält außerdem eine Reihe von Zeitgeberaufträgen. Wenn diese aktiviert sind, rufen sie die Inhalte der Protokolldateien, die Systemaktivität und die Leistungskennzahlen aus allen Servern in der Farm ab und stellen sie in einer einzigen Datenbank zusammen. Entwickler und Administratoren können die Datenbank beim Suchen nach Problemen oder einzelne Einträge bei der Problembehandlung abfragen. Darüber hinaus werden alle Fehler und Protokolleinträge mit einem Korrelationstoken gekennzeichnet, einer eindeutigen ID, die einem Benutzer angezeigt wird, wenn ein Fehler auftritt. Anhand dieser IDs können einzelne Einträge in den Protokollen einfacher gefunden werden.

Ebenfalls neu in SharePoint 2010 ist das Entwicklerdashboard. Dieses lässt sich für eine ganze Farm oder für einzelne Seiten aktivieren. Im Entwicklerdashboard werden Details zu den verschiedenen Aktivitäten dargestellt, die in SharePoint für die jeweilige Seitenanforderung stattfinden, z. B. Datenbankabfragen, Dienstaufrufe, demografische Informationen über den aktuellen Benutzer bzw. Server und die aktuelle Seite sowie die Dauer der einzelnen Aktionen. Entwickler können in ihre benutzerdefinierten Lösungen sogar Code einschließen, der im Entwicklerdashboard enthalten ist, wenn dieses auf der Seite angezeigt wird.

Weitere Informationen zum Debuggen und zur Protokollierung in SharePoint 2010 finden Sie unter Funktionen für das Debuggen und die Protokollierung in SharePoint 2010.

Schlussbemerkung

Dieser Artikel bot Entwicklern, Entwicklungsteams und Entwicklungsleitern eine Einführung in die teambasierte Entwicklung in Microsoft SharePoint 2010. Nach der Vorstellung der verschiedenen Komponenten, die erstellt werden können, erhielt der Leser Orientierungshilfen zu den unterschiedlichen Implementierungs- und Bereitstellungsoptionen für benutzerdefinierte Entwicklungen. Die beiden wichtigsten Tools für Entwickler zum Erstellen von benutzerdefinierten SharePoint-Lösungen, SharePoint Designer 2010 und Visual Studio 2010, wurden einschließlich der jeweiligen Vor- und Nachteile erklärt. Anschließend wurden die Optionen für die Konfiguration der Arbeitsstation eines Entwicklers und die Zusammenarbeit im Entwicklungsteam beschrieben. Zuletzt wurden das Upgraden einer Bereitstellung und die Problembehandlung für benutzerdefinierte SharePoint 2010-Entwicklungsprojekte erläutert.

Weitere Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen: