Durchführen eines Upgrades für Seiten
Letzte Änderung: Dienstag, 6. April 2010
Gilt für: SharePoint Foundation 2010
Allgemeine Seitenupgrades
Microsoft SharePoint Foundation 2010 verwendet eine unterschiedliche Strategie zum Upgraden einer Seite, abhängig davon, ob die Seite angepasst wurde.
In SharePoint Foundation wird die Version der Websitedefinition, über die eine Website erstellt wurde, nachverfolgt. Für eine Website kann ein Upgrade durchgeführt werden, wenn sie eine Updatedefinition besitzt, die die nicht angepassten Front-End-Websitedefinitionsdateien übersetzt. Nach dem Upgradeprozess werden alle Verweise auf nicht angepasste Front-End-Dateien aus dem vorherigen Verzeichnis dem aktuellen Verzeichnis zugeordnet. Das heißt Folgendes:
%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\
Nicht für jeden Websitepfad wird beim ersten Upgrade ein Upgrade durchgeführt. Alle vorhandenen Websitedefinitionen, die keine Upgradepfade besitzen, sind weiterhin funktionsfähig. Sie zeigen jedoch noch auf die ursprünglichen Seiten. Zudem enthält eine aktualisierte Website möglicherweise weiterhin die angepassten Seiten der vorherigen Version, die in der Datenbank gespeichert wurden.
Wenn Code analysiert wird und Seiten gerendert werden, wird von SharePoint Foundation bestimmt, welcher Website die Seite zugeordnet ist, und daher wird auch die Version der nicht angepassten Dateien auf dem Front-End-Webserver bestimmt. Die Seiten einer vorherigen Version sind nicht kompatibel mit den Standards der aktuellen Version. Diese Seiten werden in einem Kompatibilitätsmodus ausgeführt, wenn für die Website kein Upgrade durchgeführt wurde. Nachdem jedoch eine Upgradedefinition angewendet und für die Website ein Upgrade durchgeführt wurde, wird von SharePoint Foundation vorausgesetzt, dass die Seiten vollständig mit Microsoft ASP.NET 3.5 kompatibel sind. Dies bedeutet beispielsweise, dass sie einen Webpart-Manager besitzen, wenn sie Webpartzonen enthalten, dass sie gültige Steuerelement-IDs besitzen und dass sie einer Gestaltungsvorlage zugeordnet sind.
Seitenkompatibilität
In vorherigen Versionen von SharePoint Foundation wurden angepasste Seiten in der Datenbank mithilfe des Parsers "Windows SharePoint Services" analysiert, der andere Toleranzen besaß als der ASP.NET-Parser. Falls eine Seite nicht wohlgeformte Markupsprache enthält, kann es vorkommen, dass die Seite zwar in einer vorherigen Version verwendet werden konnte, in ASP.NET und in der aktuellen Version von SharePoint Foundation jedoch wegen der Unterschiede zwischen den Parsern nicht funktionsfähig ist.
Der SharePoint Foundation-Parser behandelt eine Teilmenge der bekannten Unterbrechungsprobleme im Seitenmarkup, dazu zählen Folgende:
Ungültige Steuerelement-IDs, die mit ASP.NET nicht kompatibel sind, z. B. für den Fall, dass ein Name ungültig ist, da die ID mit einer Zahl oder einem nicht unterstützten Zeichen beginnt, die ID eine leere Zeichenfolge ist oder die ID im Hinblick auf andere IDs auf der Seite nicht eindeutig ist. Durch diese Änderung kann eine Seite beschädigt werden, wenn ein clientseitiges Skript auf die ehemaligen ID-Namen vertraut.
Bekannte Attribute, die auf der Seite durch SharePoint Foundation (z. B. __Preview, __Error, __Web PartId, WebPart) eingefügt werden, werden durch die Implementierung der SharePoint-Schnittstelle IAttributeAccessor in Webparts behandelt.
Entfernung von Trace-Attributen.
Hinzufügung von entsprechenden Direktiven für Registrierungstags wie <WebPart:WebPartZone> oder <SharePoint:Theme>.
Die folgenden Unterbrechungsprobleme auf Seiten werden von SharePoint Foundation nicht repariert:
Unbekannte Attribute in Steuerelementen.
Vorhandensein von <object runat=server>-Tags.
Vorhandensein von Datenbindungsausdrücken innerhalb von Attributen (<% ... %>)
SharePoint Foundation speichert eine ganzzahlige Version für jede angepasste Seite in der Datenbank. Wenn eine angepasste Seite durchsucht wird, überprüft SharePoint die Versionsnummer der Seite. Falls die Versionsnummer einer vorherigen Version entspricht, für die kein Upgrade durchgeführt wurde, repariert SharePoint diese verschiedenen Unterbrechungsprobleme und aktualisiert die Seite im Hintergrund.
Anwendungsseiten
SharePoint Foundation speichert Layoutdateien in einem sprachenabhängigen Ordner und richtet automatisch eine Umleitung ein, die Benutzer vom vorherigen /_layouts-Speicherort zum aktuellen Speicherort führt.
Layoutseiten sind im Allgemeinen so festgelegt, dass sie eine Gestaltungsvorlage verwenden, die über die SPWeb.MasterUrl-Eigenschaft festgelegt wird. Für Websitedefinitionen der vorherigen Versionen sollte diese Eigenschaft auf eine Gestaltungsvorlage verweisen, die das vorherige Aussehen und Verhalten beibehält.
Webparts
Webparts aus vorherigen Versionen von SharePoint Foundation sind in der aktuellen Version weiterhin funktionsfähig, es sind jedoch unter Umständen einige Änderungen an der Konfiguration erforderlich. Wenn Sie eine neue Webanwendung zum Hosten einer SharePoint Foundation-Installation erstellen, muss die web.config-Datei für diese Installation aktualisiert werden, um die zusätzlichen Richtlinien für das Sicherungssteuerelement und die Codezugriffssicherheit (Code Access Security, CAS) einzuschließen.
Die allgemeine Ebene der CAS-Einschränkungen bleibt zwar in SharePoint Foundation identisch, Richtliniendateien werden jedoch geändert, sodass sie für ASP.NET aktuell bleiben. Aus diesem Grund ist es möglicherweise nicht möglich, die CAS-Richtliniendateien einer vorherigen Version in der aktuellen Version von SharePoint Foundation wiederzuverwenden. Am besten erstellen Sie eine Kopie der wss_minimaltrust.config-Datei der aktuellen Version, und fügen bei Bedarf Berechtigungen inkrementell hinzu.
Weitere Informationen zum Durchführen eines Upgrades für Webparts finden Sie unter Upgraden von Webparts.