Grundlegendes zum visuellen Upgrade in SharePoint 2010

Zusammenfassung: Hier finden Sie Informationen zum visuellen Upgrade in Microsoft SharePoint 2010 und zu den Optionen für die erneute Bereitstellung der Benutzeroberfläche sowie angepasster Seiten und benutzerdefinierter Lösungen aus Windows SharePoint Services 3.0 und Microsoft Office SharePoint Server 2007.

Letzte Änderung: Mittwoch, 12. Januar 2011

Gilt für: Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Inhalt dieses Artikels
Übersicht über das visuelle Upgrade für SharePoint 2010
Motivation für das visuelle Upgrade
Funktionsweise des visuellen Upgrades
Verwalten des Vorgangs für visuelle Upgrades
Aktualisieren von benutzerdefinierten SharePoint-Lösungen
Abschluss
Weitere Ressourcen

Inhalt

  • Übersicht über das visuelle Upgrade für SharePoint 2010

  • Motivation für das visuelle Upgrade

  • Funktionsweise des visuellen Upgrades

  • Verwalten des Vorgangs für visuelle Upgrades

  • Aktualisieren von benutzerdefinierten SharePoint-Lösungen

  • Abschluss

  • Weitere Ressourcen

Übersicht über das visuelle Upgrade für SharePoint 2010

In Microsoft SharePoint 2010 wurde eine neue standardisierte Benutzeroberfläche eingeführt, die gegenüber der Verwendung der Benutzeroberfläche von Windows SharePoint Services 3.0 und Microsoft Office SharePoint Server 2007 einen großen Fortschritt darstellt. Zur Unterstützung von Unternehmen beim Aktualisieren von Farmen und Inhalten enthält SharePoint 2010 ein Feature, das als Visuelles Upgrade bezeichnet wird und den Übergang zur neuen Benutzeroberfläche von SharePoint 2010 erleichtern soll. In diesem Artikel wird das visuelle Upgrade aus der Sicht von Entwicklern und Websitedesignern beschrieben. Außerdem erhalten Sie Empfehlungen zum Aktualisieren angepasster Seiten und benutzerdefinierter Komponenten, die ursprünglich für Windows SharePoint Services 3.0 und Office SharePoint Server 2007 entworfen wurden.

Motivation für das visuelle Upgrade

Die Benutzeroberfläche von SharePoint 2010 ist eine deutliche Verbesserung gegenüber der Benutzeroberfläche von Windows SharePoint Services 3.0 und Office SharePoint Server 2007. Bei der neuen Benutzeroberfläche von SharePoint 2010 wurden viele der unnötigen Postbacks, die verwirrenden Seitenübergänge und die tabellenbasierten Seitenlayouts der vorherigen Version vermieden. Dadurch ist eine erheblich verbesserte Benutzererfahrung entstanden, die ein serverseitiges Menüband und neues clientseitiges Verhalten umfasst, mit dem Standardbenutzerbefehle mithilfe asynchroner Rückrufe an den Webserver im Hintergrund ausgeführt werden.

Obwohl die Verbesserungen an der Benutzeroberfläche von SharePoint 2010 einen großen Schritt nach vorn darstellen, ist auch festzuhalten, dass sich die neue Benutzererfahrung stark von der von Windows SharePoint Services 3.0 und Office SharePoint Server 2007 unterscheidet. Die Links und Schaltflächen für Standardbenutzerbefehle befinden sich an neuen Positionen hinter Registerkarten des Menübands. Die Benutzererfahrung für die Ausführung vieler gängiger Aufgaben wird jetzt durch Dialogfelder gesteuert und erfordert möglicherweise eine gewisse Eingewöhnungszeit. Obwohl die neue Benutzeroberfläche offensichtliche langfristige Vorteile bietet, können sich auch kurzfristige Auswirkungen auf die Benutzerproduktivität ergeben. Daher sollten Unternehmen die Migration zur neuen Benutzeroberfläche von SharePoint 2010 sorgfältig planen und bei der Migration auch Endbenutzerschulungen einplanen.

Es ist nicht nur notwendig, dass sich die Benutzer mit der neuen Benutzeroberfläche vertraut machen, sondern es sind auch Seitenanpassungen und benutzerdefinierte Komponenten, die für Windows SharePoint Services 3.0 und Office SharePoint Server 2007 entworfen und getestet wurden, zu berücksichtigen. Unternehmen, die Websites mit angepassten Seiten migrieren, oder Websites, für die benutzerdefinierte Komponenten (beispielsweise Webparts) benötigt werden, sollten durch proaktive Schritte sicherstellen, dass diese Seitenanpassungen und benutzerdefinierten Komponenten bei Verwendung auf der neuen Benutzeroberfläche von SharePoint 2010 richtig angezeigt werden und sich ordnungsgemäß verhalten. In manchen Szenarien müssen angepasste Seiten und benutzerdefinierte Lösungen, die für Windows SharePoint Services 3.0 und Office SharePoint Server 2007 entworfen wurden, möglicherweise aktualisiert werden, damit sie auf der neuen Benutzeroberfläche richtig verwendet werden können.

SharePoint 2010 enthält das Feature Visuelles Upgrade, das entworfen wurde, um Unternehmen zu unterstützen, die vorhandene Websites für die Ausführung in einer SharePoint 2010-Umgebung aktualisieren. Der wichtigste Vorteil des visuellen Upgrades besteht darin, dass Unternehmen Websites auf SharePoint 2010 aktualisieren können, ohne die Benutzer dazu zu zwingen, sofort die neue Benutzeroberfläche von SharePoint 2010 zu verwenden. Stattdessen können die Benutzer dank des visuellen Upgrades während einer Übergangsphase weiter die alte vertraute Benutzeroberfläche in einer SharePoint 2010-Farm verwenden. Wenn die Benutzer später für den Umstieg bereit sind, kann der Websiteadministrator die Website neu konfigurieren, sodass die neue Benutzeroberfläche von SharePoint 2010 verwendet wird.

Der größte Nutzen des Features Visuelles Upgrade besteht darin, dass die Migration der Websites und Inhalte effektiv von der Migration der Endbenutzer zur neuen Benutzeroberfläche von SharePoint 2010 getrennt wird. Auf diese Weise kann der Farmadministrator Websites und Inhalte auf SharePoint 2010 aktualisieren, ohne sich im Vorfeld um die Koordinierung der Endbenutzerschulungen zu kümmern. Mit dem visuellen Upgrade ist es außerdem nicht mehr notwendig, dass Geschäftsbenutzer verfrüht zur Verwendung der neuen Benutzeroberfläche von SharePoint 2010 gezwungen werden. Es spielt keine Rolle, welchen Zeitpunkt der Farmadministrator für die Ausführung des Upgrades auswählt.

Grundlegendes zur Gestaltungsvorlage "default.master"

Zum Verständnis der inneren Funktionsweise eines visuellen Upgrades müssen Sie kurz die in Windows SharePoint Services 3.0 verwendeten standardmäßigen Benutzeroberflächenkomponenten betrachten. Beim Bereitstellen einer neuen Website in Windows SharePoint Services 3.0 wird eine spezielle ausgeblendete Dokumentbibliothek erstellt, die als Gestaltungsvorlagenseite bezeichnet wird. Neben der Erstellung der Gestaltungsvorlagenseite auf jeder neuen Website wird außerdem eine Instanz einer Gestaltungsvorlage mit dem Namen default.master bereitgestellt. Dabei handelt es sich um die primäre Gestaltungsvorlage in Windows SharePoint Services 3.0, die verwendet wird, um das Aussehen und Verhalten von Websites festzulegen.

Das Layout der in default.master definierten HTML-Elemente hängt von Regeln in Cascading Stylesheets (CSS-Dateien) ab. Die Gestaltungsvorlagendefinition in default.master enthält das serverseitige CssLink-Steuerelement, mit dem einer wichtigen Datei mit dem Namen core.css automatisch ein Link hinzugefügt wird. Von vielen angepassten Seiten und benutzerdefinierten SharePoint-Lösungen in Windows SharePoint Services 3.0 und Office SharePoint Server 2007werden die in core.css definierten Regeln für Cascading Stylesheets um zusätzliche Regeln erweitert.

Sehr wichtig ist dabei, dass default.master ohne DOCTYPE-Element definiert wird. Durch das Weglassen des DOCTYPE-Elements auf den Seiten einer Windows SharePoint Services 3.0-Website werden Browser gezwungen, die enthaltenen HTML-Elemente anhand eines älteren Regelsatzes zu interpretieren und zu rendern. Ebenso wichtig ist, dass Sie sich dessen bewusst sind, dass sich das DOCTYPE-Element bzw. im Fall von Windows SharePoint Services 3.0 das Fehlen eines DOCTYPE-Elements ebenfalls auf die HTML-Seiten zugrunde liegenden Regeln für Cascading Stylesheets auswirkt.

Wenn auf einer Seite kein DOCTYPE-Element definiert ist, werden die der Seite zugrunde liegenden Regeln für Cascading Stylesheets vom Browser anhand eines älteren Regelsatzes interpretiert, der von vielen Webdesignern als "Quirksmodus" bezeichnet wird. Der Name "Quirksmodus" rührt daher, dass die browserübergreifende Anwendung der Regeln für Cascading Stylesheets recht inkonsistent ist.

In Windows SharePoint Services 3.0 sind Websiteseiten normalerweise mithilfe eines speziellen Tokens anstatt mit einem hartcodierten Pfad mit default.master verknüpft. Konkret enthält die Page-Direktive auf Windows SharePoint Services 3.0-Websiteseiten das MasterPageFile-Attribut, dem wie im folgenden Beispiel der Tokenwert ~masterurl/default.master zugewiesen wird.

<%@ Page MasterPageFile="~masterurl/default.master" %>

Der Nutzen dieses speziellen Tokens besteht darin, dass das Token bei der Verarbeitung der Seite durch Windows SharePoint Services 3.0 dynamisch ersetzt wird. Jede Windows SharePoint Services 3.0-Website hat eine MasterUrl-Eigenschaft, der zunächst ein Wert zugewiesen wird, der auf die Instanz von default.master auf der Gestaltungsvorlagenseite der Website verweist. Es ist jedoch möglich, mit einer benutzerdefinierten Lösung eine benutzerdefinierte Gestaltungsvorlage auf die Gestaltungsvorlagenseite hochzuladen und die MasterUrl-Eigenschaft zu aktualisieren, um die Websiteseiten so umzuleiten, dass anstelle von default.master die benutzerdefinierte Gestaltungsvorlage verwendet wird.

Wichtig ist bei Gestaltungsvorlagen und Anwendungsseiten, dass das Verknüpfen von Anwendungsseiten mit default.master oder mit einer anderen Gestaltungsvorlage auf der Gestaltungsvorlagenseite einer Website von Windows SharePoint Services 3.0 und Office SharePoint Server 2007 nicht unterstützt wird. Stattdessen werden Anwendungsseiten so geschrieben, dass eine Verknüpfung mit Gestaltungsvorlagen erstellt wird, die im Verzeichnis LAYOUTS bereitgestellt werden. Beispielsweise ist der Großteil der Anwendungsseiten, die von Windows SharePoint Services 3.0 und Office SharePoint Server 2007 bereitgestellt werden, mit der Standardgestaltungsvorlage application.master verknüpft, die im Verzeichnis LAYOUTS bereitgestellt wird.

<%@ Page MasterPageFile="~/_layouts/application.master" %>

Außerdem sollten Sie verstehen, dass von vielen benutzerdefinierten SharePoint-Lösungen, die für Windows SharePoint Services 3.0 und Office SharePoint Server 2007 entworfen wurden, eigene benutzerdefinierte Anwendungsseiten bereitgestellt werden. Bei den meisten dieser benutzerdefinierten Anwendungsseiten wird mit der gleichen Methode eine Verknüpfung mit application.master oder einer anderen im Verzeichnis LAYOUTS bereitgestellten Gestaltungsvorlage erstellt.

Funktionsweise des visuellen Upgrades

Die neue Benutzeroberfläche von SharePoint 2010 wurde von Grund auf neu erstellt. Daher werden neue Gestaltungsvorlagen und CSS-Dateien verwendet, die in Windows SharePoint Services 3.0 oder Office SharePoint Server 2007 nicht enthalten waren. Um die für das visuelle Upgrade erforderliche Funktionalität bereitzustellen, müssen in SharePoint Foundation 2010 jedoch weiter die gleichen Standardgestaltungsvorlagen und CSS-Dateien wie in Windows SharePoint Services 3.0 verwendet werden. Aus diesem Grund werden von SharePoint Foundation 2010 verschiedene Dateien bereitgestellt, die die gleichen Namen haben wie in Windows SharePoint Services 3.0, beispielsweise default.master, application.master und core.css.

Zur Unterscheidung zwischen den älteren für Windows SharePoint Services 3.0 erstellten Dateien und den neueren für SharePoint Foundation 2010 erstellten Dateien, wurde von Microsoft ein einfaches Versionsverwaltungsschema festgelegt. Die Benutzeroberfläche von Windows SharePoint Services 3.0 und Office SharePoint Server 2007 hat den Namen Version 3, da Windows SharePoint Services 3.0 die Versionsnummer 3.0 hat. Die neue Benutzeroberfläche von SharePoint 2010 hat den Namen Version 4. Sie werden sehen, dass die Namen einiger in SharePoint Foundation 2010 enthaltener Dateien im Namen die Zeichenfolge v3 oder v4 enthalten. Dies ist ein Hinweis darauf, welche Benutzeroberflächenversion unterstützt wird.

Beim Bereitstellen einer neuen Website in SharePoint 2010 wird die Gestaltungsvorlagenseite erstellt, und es wird eine Gestaltungsvorlage mit dem Namen default.master bereitgestellt, genau wie in Windows SharePoint Services 3.0. In SharePoint 2010 werden jedoch zwei zusätzliche Gestaltungsvorlagen mit den Namen v4.master und minimal.master bereitgestellt.

Die Gestaltungsvorlage v4.master wird als primäre Gestaltungsvorlage zum Erstellen der neuen Benutzeroberfläche von SharePoint 2010 verwendet. Durch v4.master erhalten beispielsweise Teamwebsites in SharePoint 2010 ein gemeinsames Seitenlayout für alle Seiten einer Website. Dazu gehören vertraute Elemente wie beispielsweise das Menü Websiteaktionen, die Breadcrumbspur, das Menüband, das Menü Willkommen, das Websitesymbol, die obere Navigationsleiste und die Schnellstart-Symbolleiste.

Eine erwähnenswerte Verbesserung der Benutzeroberfläche von SharePoint 2010 besteht darin, dass Anwendungsseiten jetzt mit Gestaltungsvorlagen auf der Gestaltungsvorlagenseite verknüpft werden können. Viele der in Microsoft SharePoint Foundation 2010 und Microsoft SharePoint Server 2010 enthaltenen Standardanwendungsseiten sind anfangs mit v4.master verknüpft. Die Tatsache, dass Websiteseiten und Anwendungsseiten jetzt mit einer einzigen Gestaltungsvorlage verknüpft werden können, sorgt für ein einheitlicheres Aussehen und Verhalten aller Seiten einer Website.

Die Gestaltungsvorlage minimal.master enthält ein Seitenlayout für Version 4 ohne das in v4.master enthaltene Chrom, beispielsweise das Menü Websiteaktionen, das Menüband, die obere Navigationsleiste und die Schnellstart-Symbolleiste. Minimal.master wird von mehreren der Standardvorlagen für Websiteseiten und Anwendungsseiten verwendet, die zusammen mit SharePoint Foundation 2010 und SharePoint Server 2010 verteilt werden.

Die dritte Gestaltungsvorlage, die auf der Gestaltungsvorlagenseite für jede neue SharePoint 2010-Website bereitgestellt wird, heißt default.master. Diese Gestaltungsvorlage enthält das HTML-Layout und Chrom einer Windows SharePoint Services 3.0-Website. Die CSS-Datei (Cascading Stylesheets) von Windows SharePoint Services 3.0 mit dem Namen core.css ist ebenfalls in SharePoint Foundation 2010 enthalten, um das gleiche Formatierungsverhalten wie in einer Windows SharePoint Services 3.0-Farm zu ermöglichen. Sie sollten wissen, dass default.master und core.css ausdrücklich enthalten sind, um Szenarien für visuelle Upgrades zu unterstützen, in denen SharePoint 2010-Websites mit der älteren Benutzeroberfläche von Windows SharePoint Services 3.0 gerendert werden müssen.

Grundlegendes zur Gestaltungsvorlage "v4.master"

Die Gestaltungsvorlage v4.master gehört zum Kern der neuen Benutzeroberfläche von SharePoint 2010. Der in v4.master definierte HTML-Code und die zugrunde liegenden Regeln für Cascading Stylesheets unterscheiden sich deutlich von denen von default.master. Das liegt daran, dass v4.master und die zugrunde liegenden Regeln für Cascading Stylesheets für die Unterstützung neuer Internetstandards für Webdesign entworfen wurden und erheblich größere Konsistenz zwischen den heute gängigsten Browsern wie beispielsweise Internet Explorer, Firefox und Safari erreicht werden sollte.

Die Gestaltungsvorlage v4.master unterscheidet sich von default.master, da ein DOCTYPE definiert wird. Dies ist einer der entscheidenden Aspekte, wenn Sie Konsistenz zwischen unterschiedlichen Browsern erreichen möchten. Konkret wird in v4.master der DOCTYPEXHTML 1.0 Strict definiert.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Aus Sicht eines Webdesigners ist es auch wichtig, zu wissen, dass der HTML-Code auf oberster Ebene, der für das Layout von Seiten in v4.master verwendet wird, im Gegensatz zum in default.master verwendeten tabellenbasierten Layout auf div-Elementen basiert. Durch Verwendung von div-Elementen kann mit v4.master die Barrierefreiheit im Vergleich zu Windows SharePoint Services 3.0 und Office SharePoint Server 2007 verbessert werden. Webdesigner begrüßen die Eliminierung des tabellenbasierten Seitenlayouts, da sich dadurch die Möglichkeit bietet, moderne Entwurfsmethoden zu verwenden, die auf anderen beliebten und vertrauten Websites im Internet verwendet werden.

Außerdem werden Sie beobachten, dass die Einbeziehung von XHTML StrictDOCTYPE in v4.master Auswirkungen darauf hat, wie die einer Seite zugrunde liegenden Regeln für Cascading Stylesheets vom Browser interpretiert werden. Beispielsweise kann eine Regel für Cascading Stylesheets eine bestimmte Auswirkung auf ein HTML-Element haben, wenn die hostende Seite kein DOCTYPE-Element enthält. Die gleiche Regel für Cascading Stylesheets kann völlig andere oder gar keine Auswirkungen haben, wenn der hostenden Seite später ein bestimmtes DOCTYPE-Element zugewiesen wird, beispielsweise XHTML Strict. Aus diesem Grund werden von v4.master nicht die Regeln für Cascading Stylesheets in core.css verwendet, da dessen Regeln für Cascading Stylesheets für Seiten entworfen wurden, auf denen kein DOCTYPE-Element definiert wird. Stattdessen wird v4.master mit der neuen CSS-Datei corev4.css verknüpft, die für die Verwendung mit XHTML StrictDOCTYPE entworfen wurde.

Verknüpfen mit Gestaltungsvorlagen in SharePoint 2010

Websiteseiten werden in SharePoint 2010 auf die gleiche Weise mit einer Gestaltungsvorlage verknüpft wie in Windows SharePoint Services 3.0 und Office SharePoint Server 2007. Wenn Sie die von SharePoint Foundation 2010 und SharePoint Server 2010 bereitgestellten Vorlagen für Websiteseiten untersuchen, werden Sie feststellen, dass wie im folgenden Beispiel gezeigt das standardmäßige MasterPageFile-Attribut mit dem gleichen dynamischen Token wie in Windows SharePoint Services 3.0 verwendet wird.

<%@ Page MasterPageFile="~masterurl/default.master" %>

Genau wie in Windows SharePoint Services 3.0 hat das SPWeb-Objekt, das eine Website darstellt, eine MasterUrl-Eigenschaft, mit deren Hilfe SharePoint 2010 informiert wird, mit welcher Gestaltungsvorlage für Seiten, auf denen das dynamische Token ~masterurl/default.master verwendet wird, eine Verknüpfung erstellt werden soll. Wenn Sie in SharePoint 2010 eine neue Website erstellen, wird die MasterUrl-Eigenschaft initialisiert, um auf die Instanz von v4.master auf der aktuellen Website zu verweisen. Wenn Sie jedoch eine Website von Windows SharePoint Services 3.0 oder Office SharePoint Server 2007 aktualisieren, wird der aktuelle MasterUrl-Eigenschaftswert der Seite übernommen, der in den meisten Fällen auf default.master verweist. Eine Windows SharePoint Services 3.0-Website, auf der eine benutzerdefinierte Brandinglösung verwendet wird, kann jedoch auch auf eine benutzerdefinierte Gestaltungsvorlage verweisen, die auf die Gestaltungsvorlagenseite hochgeladen wurde.

Die Methode für das Verknüpfen von Websiteseiten mit einer Gestaltungsvorlage ist zwar zwischen Windows SharePoint Services 3.0 und SharePoint Foundation 2010 im Wesentlichen unverändert geblieben, dies gilt jedoch nicht für Anwendungsseiten. In SharePoint Foundation 2010 können jetzt Anwendungsseiten mit der gleichen Gestaltungsvorlage verknüpft werden wie Websiteseiten. Wenn Sie beispielsweise eine SharePoint Foundation 2010-Teamwebsite unter Version 4 der Benutzeroberfläche ausführen, sind die meisten Anwendungsseiten ebenso wie die Webseiteseiten mit v4.master verknüpft. Wenn Sie die MasterUrl-Eigenschaft einer Website aktualisieren, wird sowohl für die Websiteseiten als auch für die Anwendungsseiten die neue Gestaltungsvorlage verwendet.

In SharePoint 2010 wurde eine neue Syntax eingeführt, mit der Anwendungsseiten mithilfe des gleichen dynamischen Tokens, das von Websiteseiten verwendet wird, mit einer Gestaltungsvorlage verknüpft werden können. Bei dieser Syntax fügen Sie wie im folgenden Beispiel gezeigt das DynamicMasterPageFile-Attribut in der Page-Direktive hinzu.

<%@ Page DynamicMasterPageFile="~masterurl/default.master" %>

Diese Syntax kann zunächst verwirrend sein, da das DynamicMasterPageFile-Attribut von der ASP.NET-Laufzeit nicht erkannt wird. DynamicMasterPageFile ist stattdessen ein benutzerdefiniertes Attribut, das von SharePoint 2010 in einer früheren Phase des Seitenlebenszyklus gelesen und interpretiert wird. Wie bei einer Websiteseite kann von SharePoint 2010 der MasterUrl-Eigenschaftswert für die aktuelle Website abgerufen und zum dynamischen Verknüpfen der Anwendungsseite mit der richtigen Gestaltungsvorlage verwendet werden.

Websiteseiten und Anwendungsseiten werden auf unterschiedliche Weise mit einer Gestaltungsvorlage verknüpft, jedoch wird in beiden Fällen mithilfe des Tokens ~masterurl/default.master der gleiche Effekt erzielt. Dadurch wird es möglich, die Gestaltungsvorlage für jede Seite einer SharePoint 2010-Website einfach durch Aktualisieren der SPWeb.MasterUrl-Eigenschaft auszutauschen.

Es gibt ein gängiges Szenario in Office SharePoint Server 2007 und SharePoint Server 2010, bei dem die Seiten einer Website nicht mit der Gestaltungsvorlage verknüpft sind, auf die mit der MasterUrl-Eigenschaft verwiesen wird. In diesem Szenario werden Websites veröffentlicht, die eine spezielle Dokumentbibliothek mit dem Namen Seiten enthalten. Die Dokumentbibliothek Seiten enthält einen speziellen Seitentyp, die so genannte Veröffentlichungsseite. Alle Veröffentlichungsseiten werden dynamisch mithilfe einer weiteren Eigenschaft der SPWeb-Klasse (CustomMasterUrl) mit einer Gestaltungsvorlage verknüpft. Daher müssen Sie, wenn Sie Code schreiben, um die Gestaltungsvorlage auf einer Veröffentlichungssite auszutauschen, anstelle der bzw. zusätzlich zur MasterUrl-Eigenschaft die CustomMasterUrl-Eigenschaft aktualisieren.

Wechseln zwischen Versionen der SharePoint-Benutzeroberfläche

Standardmäßig werden beim Aktualisieren einer Windows SharePoint Services 3.0-Website oder einer Office SharePoint Server 2007-Website auf SharePoint 2010 die entsprechenden Seiten zunächst mit Version 3 der Benutzeroberfläche von Windows SharePoint Services 3.0 gerendert. Websiteadministratoren können jedoch mithilfe von Standardbefehlen im Browser die Benutzeroberfläche der Websites einzeln zu Version 4 migrieren. Im Browser steht außerdem ein Befehl zur Verfügung, mit dem Websitesammlungsbesitzer alle Websites innerhalb einer Websitesammlung gleichzeitig migrieren können. Dies bedeutet, dass einzelne Teams entscheiden können, wann der richtige Zeitpunkt zum Migrieren der Benutzeroberfläche der Websites zu Version 4 gekommen ist.

Nun kommen wir zu den Implementierungsdetails, die es ermöglichen, die Benutzeroberfläche einer Website in SharePoint 2010 zwischen Versionen hin- und herzuschalten. Jede SharePoint-Website wird durch ein SPWeb-Objekt dargestellt. Beginnend mit SharePoint 2010 verfügt jedes SPWeb-Objekt über eine neue UIVersion-Eigenschaft, die in der Inhaltsdatenbank nachverfolgt wird. Die UIVersion-Eigenschaft basiert auf Ganzzahlen, und die gültigen Werte lauten 3 oder 4. Wenn eine Website den UIVersion-Eigenschaftswert 3 hat, werden die Seiten der Website in SharePoint 2010 mit Version 3 gerendert. Wenn eine Website den UIVersion-Eigenschaftswert 4 hat, werden die Seiten der Website in SharePoint 2010 mit Version 4 gerendert.

In SharePoint 2010 kann außerdem die Möglichkeit, dass ein Websiteadministrator die Benutzeroberflächenversion neu konfigurieren kann, aktiviert oder deaktiviert werden. Diese Steuerung wird durch eine weitere neue SPWeb-Eigenschaft ermöglicht, die UIVersionConfigurationEnabled-Eigenschaft. Wenn diese Eigenschaft den booleschen Wert true hat, hat der Websiteadministrator in SharePoint 2010 die Möglichkeit, mithilfe des Browsers zwischen den Versionen hin- und herzuwechseln. Wenn eine Website den UIVersionConfigurationEnabled-Eigenschaftswert false hat, hat der Websiteadministrator in SharePoint 2010 keine Möglichkeit, zwischen den Benutzeroberflächenversionen zu wechseln.

Wenn Sie in SharePoint 2010 eine neue Website erstellen, ist das Feature Visuelles Upgrade nicht notwendig. Daher werden neue Websites mit dem UIVersion-Eigenschaftswert 4 und dem UIVersionConfigurationEnabled-Eigenschaftswert false erstellt. Dies bedeutet, dass die Benutzeroberfläche für neue Websites mit Version 4 ausgeführt wird. Außerdem bedeutet es, dass der Websiteadministrator keine Möglichkeit hat, die Benutzeroberfläche der Website wieder in Version 3 zu ändern.

Beim Aktualisieren vorhandener Websites von Windows SharePoint Services 3.0 und Office SharePoint Server 2007 bestehen Unterschiede. Wenn Sie eine Website aktualisieren, sieht das Standardverhalten von SharePoint 2010 vor, dass anfangs der UIVersion-Eigenschaftswert 3 und der UIVersionConfigurationEnabled-Eigenschaftswert true zugewiesen wird. Dies bedeutet, dass die Benutzeroberfläche für aktualisierte Websites anfangs unter Version 3 ausgeführt wird. Bei aktualisierten Websites hat außerdem der Websiteadministrator die Möglichkeit, die Benutzeroberfläche für die Website neu zu konfigurieren, sodass Version 4 verwendet wird. Wenn ein Websiteadministrator jedoch die unter Version 4 ausgeführte Website neu konfigurieren möchte, wird von SharePoint 2010 die UIVersionConfigurationEnabled-Eigenschaft auf false aktualisiert, sodass der Websiteadministrator nicht mehr zu Version 3 zurückwechseln kann.

Aktualisieren der UIVersion-Eigenschaft mithilfe von Code

Mit dem serverseitigen Objektmodell von SharePoint 2010 kann die UIVersion-Eigenschaft einer oder mehrerer Websites relativ leicht aktualisiert werden, um die Migration der Benutzeroberfläche von Websites in einer Farm von Version 3 zu Version 4 zu automatisieren. Mit dem folgenden einfachen C#-Codeausschnitt, der mit Microsoft Visual Studio 2010 geschrieben wurde, werden alle Websites in einer Websitesammlung neu konfiguriert, sodass die Benutzeroberfläche unter Version 4 ausgeführt wird.

string url = "http://intranet.wingtip.com";
using (SPSite siteCollection = new SPSite(url)) {
  foreach (SPWeb site in siteCollection.AllWebs) {
    site.UIVersion = 4;
    site.UIVersionConfigurationEnabled = false;
    site.Update();
  }
}

Was müssen Sie tun, wenn Sie als Farmadministrator das gleiche Ergebnis erzielen möchten, ohne eine kompilierte Komponente oder Anwendung zu schreiben? Sie können den entsprechenden Code schreiben, um die UIVersion-Eigenschaft einer oder mehrerer Websites mithilfe eines Windows PowerShell-Skripts zu aktualisieren. Wie müssen Sie beispielsweise vorgehen, wenn Sie eine einzige Website, die zurzeit unter Version 3 ausgeführt wird, auf die Verwendung von Version 4 umstellen möchten? Sie können ein Windows PowerShell-Skript schreiben, mit dem ein SPWeb-Objekt für die Zielwebsite erstellt wird und die gleichen Eigenschaften wie mit dem C#-Code im vorherigen Beispiel aktualisiert werden.

Wenn Sie ein Windows PowerShell-Skript erstellen, in dem Sie von SharePoint 2010 bereitgestellte Cmdlets aufrufen möchten, sollten Sie zunächst das Add-PSSnapin-Cmdlet aufrufen, um das Windows PowerShell-Snap-In zu laden, das die SharePoint 2010-Cmdlets enthält. Dann können Sie das Zielwebsiteobjekt mit dem Get-SPWeb-Cmdlet abrufen, um das SPWeb-Zielobjekt abzurufen. Anschließend können Sie wie im folgenden Beispiel gezeigt der UIVersion-Eigenschaft den Wert 4 und der UIVersionConfigurationEnabled-Eigenschaft den Wert zuweisen und dann Update aufrufen.

Add-PSSnapin "Microsoft.SharePoint.PowerShell"
$site = Get-SPWeb "http://intranet.wingtip.com"
$site.UIVersion = 4
$site.UIVersionConfigurationEnabled = false
$site.Update()

Verwalten des Vorgangs für visuelle Upgrades

Wenn Sie mit dem Migrieren vorhandener Websites von Windows SharePoint Services 3.0 und Office SharePoint Server 2007 zu SharePoint Foundation 2010 und SharePoint Server 2010 beginnen, müssen Sie unbedingt berücksichtigen, welche Anpassungen angewendet wurden. Aktualisieren Sie beispielsweise Websites, auf denen Benutzer mithilfe von Microsoft Office SharePoint Designer 2007 Seiten mit eigenem HTML-Code angepasst haben? Außerdem müssen Sie berücksichtigen, ob für einige der zu aktualisierenden Websites benutzerdefinierte SharePoint-Lösungen verwendet werden, die von den Entwicklungsmitarbeitern des Unternehmens oder von Softwaredrittanbietern erstellt wurden. Werden beispielsweise für die Websites, die Sie aktualisieren möchten, benutzerdefinierte Gestaltungsvorlagen oder Webparts verwendet, mit denen HTML-Code erzeugt wird, der nicht richtig gerendert wird, wenn die Gestaltungsvorlagen oder Webparts auf einer Seite gehostet sind, für die XHTML StrictDOCTYPE definiert ist? Diese Probleme müssen Sie beim Aktualisieren von Websites auf SharePoint 2010 vorhersehen und lösen können.

Aktualisieren von SharePoint-Seitenanpassungen

Stellen Sie sich ein Szenario vor, in dem die Seiten einer Windows SharePoint Services 3.0-Website von Benutzern mithilfe von Office SharePoint Designer 2007 angepasst wurden. Nach dem Upgrade der Website stellen Sie möglicherweise fest, dass sich diese Seiten erwartungsgemäß verhalten, da die Seiten unter Version 3 ausgeführt werden. Jedoch bemerken Sie möglicherweise, dass die gleichen Seiten nicht richtig gerendert werden, wenn der Websiteadministrator die Website für die Ausführung unter Version 4 neu konfiguriert hat. In diesem Abschnitt werden einige der häufigsten Probleme erläutert, die auftreten können, und Lösungsmaßnahmen beschrieben.

Sicherstellen, dass auf Websiteseiten das Token "~masterurl/default.master" verwendet wird

Wie bereits erwähnt sind die meisten Websiteseiten mithilfe des dynamischen Tokenwerts ~masterurl/default.master mit einer Gestaltungsvorlage verknüpft. Dies ist jedoch bei Websiteseiten, die mit Office SharePoint Designer 2007 erstellt wurden, möglicherweise nicht der Fall. Eventuell stellen Sie fest, dass einige Websiteseiten einer aktualisierten Website mithilfe eines hardcodierten Pfads anstatt mithilfe des dynamischen Tokens mit default.master oder einer anderen benutzerdefinierten Gestaltungsvorlage verknüpft sind. Dadurch entstehen Probleme, da SharePoint 2010 darauf angewiesen ist, dass die Gestaltungsvorlagenverknüpfung durch das dynamische Token von default.master an v4.master umgeleitet wird, wenn die UIVersion-Eigenschaft der Website von 3 in 4 geändert wird. Daher sollten Sie alle Websiteseiten so aktualisieren, dass diese mithilfe des Tokenwerts ~masterurl/default.master anstatt mithilfe eines hardcodierten Pfads mit einer Gestaltungsvorlage verknüpft sind.

Umgestalten von benutzerdefiniertem HTML-Code in Abschnitte für SharePoint v3 und v4

Wenn Sie die Benutzeroberfläche für eine Website neu konfigurieren von Version 3 in Version 4, treten dabei normalerweise zwei wichtige Änderungen auf, die sich auf das Rendern von HTML-Code auswirken. Erstens wird die Gestaltungsvorlage von default.master (ohne DOCTYPE) in v4.master (mit XHTMLDOCTYPEStrict) geändert. Zweitens wird die primäre CSS-Dateiverknüpfung durch SharePoint 2010 von core.css in corev4.css geändert. Beide Änderungen können dazu führen, dass HTML-Layouts, die für Windows SharePoint Services 3.0 und Office SharePoint Server 2007 entworfen wurden, bei der Ausführung unter Version 4 nicht richtig gerendert werden.

Wenn Sie feststellen, dass benutzerdefinierte Websiteseiten oder Gestaltungsvorlagen HTML-Fragmente enthalten, die unter Version 4 nicht richtig gerendert werden, können Sie diesen HTML-Code in getrennte Abschnitte für Version 3 und Version 4 verlagern. Hierzu können Sie das UIVersionedContent-Steuerelement verwenden, das in SharePoint 2010 eingeführt wurde.

Im folgenden Codeausschnitt wird an einem Beispiel gezeigt, wie Sie ein Paar von UIVersionedContent-Steuerelementen verwenden, um abhängig davon, ob die Website für Version 3 oder Version 4 konfiguriert ist, unterschiedliche HTML-Inhalte auszugeben.

<Sharepoint:UIVersionedContent ID="myContentIDv3" runat="server" UIVersion="3">
  <ContentTemplate>
    <p>This content displays only when UIVersion=3.</p>
  </ContentTemplate>
</SharePoint:UIVersionedContent>
<Sharepoint:UIVersionedContent ID=" myContentIDv4" runat="server" UIVersion="4">
  <ContentTemplate>
    <p>This content displays only when UIVersion=4.</p>
  </ContentTemplate>
</SharePoint:UIVersionedContent>

Umgestalten von benutzerdefinierten Regeln für Cascading Stylesheets in getrennte CSS-Dateien

Da auf Seiten einer SharePoint-Website für Version 3 und Version 4 jeweils ein anderes DOCTYPE-Element verwendet wird, führt ein einziger Satz von Regeln für Cascading Stylesheets nicht zu konsistenten Ergebnissen, wenn die Regeln sowohl in Version 3 als auch in Version 4 verwendet werden. Darüber hinaus sind die IDs der HTML-Elemente und die Klassennamen der Cascading Stylesheets, auf die von Regeln für Cascading Stylesheets verwiesen werden muss, für die Dateien default.master und v4.master unterschiedlich. Daher ist es sinnvoll, Regeln für Cascading Stylesheets in getrennte Dateien für Version 3 und Version 4 umzugestalten. Nehmen Sie beispielsweise an, Sie aktualisieren eine Website mit der benutzerdefinierten CSS-Datei WingtipStyles.css. Es wird empfohlen, eine neue CSS-Datei zu erstellen (oder eine Kopie der vorhandenen Datei zu erstellen) und dieser den Namen WingtipStylesv4.css zu geben. Auf diese Weise haben Sie die Möglichkeit, getrennte Sätze von Regeln für Cascading Stylesheets für Version 3 und Version 4 zu verwalten. Anschließend können Sie wie im folgenden Beispiel gezeigt mithilfe von zwei UIVersionedContent-Steuerelementen eine Verknüpfung mit der entsprechenden CSS-Datei erstellen.

<Sharepoint:UIVersionedContent ID="myLinkIDv3" UIVersion="3" 
                               runat="server" >
  <ContentTemplate>
   <link href="WingtipStyles.css" rel="stylesheet" type="text/css" />
  </ContentTemplate>
</SharePoint:UIVersionedContent>
<Sharepoint:UIVersionedContent ID="myLinkIDv4" UIVersion="4"
                               runat="server" >
  <ContentTemplate>
   <link href="WingtipStylesv4.css" rel="stylesheet" type="text/css" />
  </ContentTemplate>
</SharePoint:UIVersionedContent> 
TippTipp

Wenn Sie SharePoint Server 2010 verwenden, können Sie stattdessen ein CSSLink-Steuerelement einfügen und dann mithilfe des CSSRegistration-Steuerelements das richtige Cascading Stylesheet anwenden. Mit dem CSSRegistration-Steuerelement können Sie Version 3 oder Version 4 der Benutzeroberfläche auswählen.

Aktualisieren von benutzerdefinierten SharePoint-Lösungen

Manche benutzerdefinierte SharePoint-Lösungen, die für Windows SharePoint Services 3.0 und Office SharePoint Server 2007 entworfen wurden, müssen aktualisiert werden, um die richtige Funktionsweise bei Verwendung auf SharePoint Foundation 2010 und SharePoint Server 2010-Websites unter Version 4 der Benutzeroberfläche sicherzustellen. Zu den allgemeinen Beispielen für Projektelemente, die möglicherweise aktualisiert werden müssen, gehören Webparts und benutzerdefinierte Anwendungsseiten.

Aktualisieren von Webparts zum Prüfen der UIVersion-Eigenschaft

Viele benutzerdefinierte Webparts, die für Windows SharePoint Services 3.0 und Office SharePoint Server 2007 entwickelt wurden, sind so geschrieben, dass HTML-Elemente innerhalb der M:System.Web.UI.WebControls.RenderContents-Methode gerendert werden. Der folgende Codeausschnitt beispielsweise ist ein Ausgangspunkt für die Erstellung eines Webparts, mit dem ein einfaches Absatztag gerendert wird.

protected override void RenderContents(HtmlTextWriter writer) {
  writer.RenderBeginTag(HtmlTextWriterTag.P);
  writer.Write("Hello World");
  writer.RenderEndTag(); // </p>
}

Das Beispiel ist sehr einfach; mit den meisten Webparts, von denen diese Methode verwendet wird, werden aufwändigere HTML-Fragmente erzeugt, die möglicherweise bei Ausführung mit dem DOCTYPE-Element und den Regeln für Cascading Stylesheets, die bei Ausführung unter Version 4 verwendet wurden, nicht richtig angezeigt werden. Am besten können Sie damit umgehen, indem Sie wie im folgenden Beispiel gezeigt zusätzliche Logik hinzufügen, sodass abhängig davon, ob die aktuelle Website den Eigenschaftswert UIVersion3 oder 4 aufweist, mit jedem Webpart eine andere HTML-Ausgabe bereitgestellt wird.

protected override void RenderContents(HtmlTextWriter writer) {
  int UIVersion = SPContext.Current.Web.UIVersion;
  if (UIVersion == 3) {
    // Write HTML for site running under version 3.
  }
  if (UIVersion == 4) {
    // Write HTML for site running under version 4.
  }
}

Verwenden des dynamischen Tokens zum Aktualisieren von benutzerdefinierten Anwendungsseiten, um Verknüpfungen mit Gestaltungsvorlagen zu erstellen

Wie weiter oben in diesem Artikel erläutert können in SharePoint 2010 Anwendungsseiten mithilfe des gleichen dynamischen Tokens wie Websiteseiten mit einer Gestaltungsvorlage verknüpft werden. Diese Funktionalität war in Windows SharePoint Services 3.0 oder Office SharePoint Server 2007 jedoch nicht vorhanden. Daher enthalten die meisten benutzerdefinierten Anwendungsseiten, die für Windows SharePoint Services 3.0 und Office SharePoint Server 2007 entworfen wurden, hartcodierte Verknüpfungen mit Gestaltungsvorlagen im Verzeichnis LAYOUTS, beispielsweise application.master.

<%@ Page MasterPageFile="~/_layouts/application.master" %>

Wenn eine mit application.master verknüpfte Anwendungsseite unter Version 3 ausgeführt wird, verhält sich die Seite wie erwartet. Die Anwendungsseite ist mit der Datei application.master verknüpft, die von SharePoint 2010 bereitgestellt wird und das gleiche HTML-Layout aufweist wie die von Windows SharePoint Services 3.0 bereitgestellte Datei application.master. SharePoint 2010 wurde jedoch so entworfen, dass eine spezielle Verarbeitungslogik hinzugefügt wird, wenn die gleiche Seite unter Version 4 ausgeführt wird. Wenn eine mit application.master verknüpfte Anwendungsseite unter Version 4 ausgeführt wird, wird die Anwendungsseite von SharePoint 2010 dynamisch so geändert, dass die Seite mit einer anderen Gestaltungsvorlage mit dem Namen applicationv4.master verknüpft ist. DOCTYPE und HTML-Layout dieser Seite sind sehr ähnlich wie bei v4.master. Auf diese Weise können ältere Anwendungsseiten mit dem gleichen neuen Seitenlayout von SharePoint 2010 gerendert werden.

Obwohl dieses Verhalten von SharePoint 2010, das heißt die Umleitung von Anwendungsseiten von application.master an applicationv4.master, hilfreich ist, stellt es nicht die optimale Lösung dar. Wenn Sie eine benutzerdefinierte Brandinglösung verwenden, mit der die MasterUrl-Eigenschaft aktualisiert wird, werden Anwendungsseiten, die mit application.master verknüpft sind, nicht so weitergeleitet, dass die gleichen Gestaltungsvorlagen verwendet werden wie für die anderen Seiten der Website. Das gleiche Problem besteht, wenn Sie versuchen, die von einer Veröffentlichungssite verwendete Gestaltungsvorlage zu ändern.

Das Problem kann gelöst werden, indem Sie die Page-Direktive einer beliebigen Gestaltungsvorlage aktualisieren, die direkt mit einer Gestaltungsvorlage im Verzeichnis LAYOUTS verknüpft ist. Entfernen Sie das MasterPageFile-Attribut aus der Page-Direktive, und ersetzen Sie es durch das DynamicMasterPageFile-Attribut.

<%@ Page DynamicMasterPageFile="~masterurl/default.master" %>

Abschluss

Die in SharePoint 2010 eingeführte Benutzeroberfläche bedeutet einen großen Schritt nach vorn für die SharePoint-Plattform. Die stark veränderte Benutzererfahrung kann jedoch kurzfristig eine Beeinträchtigung der Benutzerproduktivität zur Folge haben. Diese Auswirkung auf Benutzer soll durch das Feature Visuelles Upgrade gemindert werden, indem die Migration der Farmen und Inhalte von der Migration zur neuen Benutzeroberfläche getrennt wird. Das visuelle Upgrade ermöglicht darüber hinaus die Migration der Benutzeroberfläche von Version 3 zu Version 4 für einzelne Websites. Aufgrund dieser hohen Granularität können verschiedene Teams innerhalb eines Unternehmens oder einer Organisation zur neuen Version 4 der Benutzeroberfläche übergehen und dabei das Tempo unabhängig von anderen Teams selbst bestimmen.

Sie kennen jetzt die Implementierungsdetails der Funktionsweise des visuellen Upgrades und verfügen über die notwendigen Kenntnisse, um die Konvertierung von Websites auf Version 4 der Benutzeroberfläche zu automatisieren, indem Sie in Visual Studio 2010 Code schreiben oder Windows PowerShell-Skripts schreiben. Außerdem verstehen Sie die Probleme, die beim Aktualisieren von Websites auftreten können, die angepasste Seiten und benutzerdefinierte SharePoint-Lösungen enthalten. Wenn Sie die potenziellen Probleme kennen und proaktive Maßnahmen zur Lösung dieser Probleme ergreifen, können Sie einen möglichst reibungslosen Übergang vornehmen, um Websites von Windows SharePoint Services 3.0 und Office SharePoint Server 2007 zu SharePoint Foundation 2010 und SharePoint Server 2010 zu migrieren.

Weitere Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen: