Upgraden von Webparts
Letzte Änderung: Donnerstag, 1. September 2011
Gilt für: SharePoint Foundation 2010
In diesem Thema wird die korrekte und umfassendste Vorgehensweise zum Aktualisieren von Webparts beschrieben. Bei diesem Verfahren wird berücksichtigt, ob es sich bei dem Webpart um ein SharePoint Foundation-, ein Hybrid- oder ein ASP.NET-Webpart handelt, ob es aus einem Webparttyp in einen anderen konvertiert wird, welche Upgradeaktion stattfindet und unter welchen Umständen der Upgradecode ausgeführt wird oder nicht. Wenn Sie eine neue Version eines Webparts erstellen und Upgradelogik für die Eigenschaftenwerte ausführen müssen, die für frühere Versionen des Webparts gespeichert wurden, bietet Microsoft SharePoint Foundation 2010 die folgenden Optionen.
Implementieren von AfterDeserialize
Wenn alle älteren Versionen Microsoft SharePoint Foundation-Webparts sind und es sich bei der neuen Version entweder um ein SharePoint Foundation 2010-Webpart oder ein Hybridwebpart handelt, implementieren Sie die AfterDeserialize()-Methode, um das Webpart zu aktualisieren. Diese Methode wird immer dann aufgerufen, wenn die alte Version in die neue Version deserialisiert wird. Dies ist dann true, wenn das Webpart seitenstatisch (außerhalb einer Zone) oder dynamisch (innerhalb einer Zone) ist bzw. über einen Objektmodellaufruf instanziiert wird. AfterDeserialize() wird jedoch nur einmal aufgerufen, wenn die alte deserialisierte Version auf die neue Version aktualisiert wird. Nachdem das Webpart zu einem Hybridwebpart aktualisiert wurde, wird AfterDeserialize() nicht mehr aufgerufen. Wenn Sie Ihr SharePoint Foundation-Webpart also in ein Hybridwebpart konvertiert haben und später Upgradelogik zum als solches bereitgestellten Hybridwebpart hinzufügen, müssen Sie AfterDeserialize() implementieren, um das Upgrade eines SharePoint Foundation-Webparts zu einem Hybridwebpart 2.0 zu verarbeiten. Außerdem müssen Sie die nachfolgend beschriebenen Schnittstellen implementieren, um das Upgrade eines Hybridwebparts von Version 1.0 auf Version 2.0 zu verarbeiten. Zu diesem Zweck wird empfohlen, eine freigegebene Upgradefunktion (in diesem Fall TransformMyString) zu erstellen, die sowohl von der AfterDeserialize()-Methode als auch von Ihren Schnittstellenimplementierungen aufgerufen wird.
Wenn es sich bei der alten Version des Webparts um ein Hybridwebpart oder ein ASP.NET-Webpart handelt und die neue Version ein Hybridwebpart oder ein ASP.NET-Webpart ist, wird AfterDeserialize() nicht aufgerufen und die Upgradelogik für das Webpart muss von OnInit(), EndLoad() und Load() aufgerufen werden, je nachdem, was mit dem Upgrade erreicht werden soll.
Weitere Informationen zur Verwendung der AfterDeserialize()-Methode finden Sie unter Aktualisieren einer Webpartassembly für Microsoft SharePoint-Produkte und -Technologien und AfterDeserialize().
Erkennen des Eigenschaftenstatus
Angenommen, Sie haben eine Zeichenfolgeneigenschaft namens SampleProperty und das Format wurde so verändert, dass der Upgradecode den Inhalt von SampleProperty aus dem alten in das neue Format konvertieren muss. Es wird empfohlen, eine TransformSampleProperty-Methode zu erstellen, mit der sich effizient feststellen lässt, ob SampleProperty bereits transformiert wurde oder nicht. Ist dies nicht der Fall, führt sie die Transformation durch. Im folgenden Beispiel wird beschrieben, wie Sie dabei vorgehen müssen:
using Asp = System.Web.UI.WebControls.WebParts
public class MyWebPart : Asp.WebPart
{
private m_dirty = false;
[Insert your standard Web Part logic here…]
private void TransformMyString()
{
if ([SampleProperty is in the old format…])
{
[Transform the SampleProperty value to the new format…]
m_dirty = true;
}
if (m_dirty && null != WebPartManager)
{
SetPersonalizationDirty();
m_dirty = false;
}
}
}
Durch den Aufruf von TransformSampleProperty durch die Methoden OnInit() und EndLoad() wird sichergestellt, dass der Upgradecode aufgerufen wird, wenn es sich um ein seitenstatisches, dynamisches oder über einen Objektmodellaufruf aufgerufenes Webpart handelt. Möglicherweise müssen Sie dem Webpart eine upgraded- oder version-Eigenschaft hinzufügen, damit TransformSampleProperty die Eigenschaft nach dem Upgrade festlegen kann und damit spätere Aufrufe von TransformSampleProperty effizient feststellen können, ob MyString bereits aktualisiert wurde oder nicht. Sie sollten die IPersonalizable-Schnittstelle zum Speichern der version-Eigenschaft verwenden, da diese Eigenschaft zusammen mit dem Rest der Webparteigenschaften dauerhaft im Speicher persistiert wird. Diese Eigenschaft erscheint nicht auf der Toolbereich-Benutzeroberfläche, wenn die Webparteigenschaften bearbeitet werden, und sie erscheint auch nicht im Markup für das Webpart, wenn es in Microsoft SharePoint Designer bearbeitet wird.
Im vorherigen Beispiel wird EndLoad() aufgerufen, sobald das Webpart deserialisiert wurde. Da SampleProperty tatsächlich im alten Format vorliegt, wird der Code für die Transformation des SampleProperty-Werts ausgeführt. Da das Webpart noch nicht zum WebPartManager hinzugefügt wurde, bleibt MyWebPart.WebPartManager NULL und SetPersonalizationDirty wird nicht aufgerufen. Nachdem das Webpart zum WebPartManager in der Seite hinzugefügt wurde, wird sein Lebenszyklus aktuell und MyWebPart.OnInit wird aufgerufen. Daraufhin ist jedoch MyString nicht mehr im alten Format, und MyWebPart.WebPartManager wird gültig. Deshalb wird SetPersonalizationDirty aufgerufen, wodurch unabhängig von den Benutzerrechten ein automatischer Speichervorgang des aktualisierten Webparts in der Datenbank ausgelöst wird.
Bei einem seitenstatischen Webpart wird das Ändern des Markups in der Seite nach dem Ausführen des Upgradecodes für das Webpart nicht unterstützt. Das bedeutet, dass das Markup immer im Zustand vor dem Upgrade verbleibt und dass der Upgradecode immer wieder in OnInit() ausgeführt wird, wenn die Seite aufgerufen wird. Ein Sonderfall ist, wenn das Webpart versucht, Eigenschaften in die Inhaltsdatenbank zurückzuschreiben, während die Datenbank in SQL Server schreibgeschützt ist. Dies kann dadurch verursacht werden, dass das Upgrade des Webparts bis zur ersten Verwendung pro Instanz verschoben wurde und die erste Verwendung auftreten kann, während die Datenbank schreibgeschützt ist. Das Webpart sollte zwar gerendert werden, aber dann die Aktualisierung nicht in der Datenbank speichern.
Ändern von Eigenschaftennamen
Angenommen, die X-Eigenschaft in der alten Version wurde in der neuen Version in Y umbenannt. Implementieren Sie in diesem Fall Load(), kopieren Sie den Wert, der in X gespeichert war, nach Y, und legen Sie ein Dirty-Flag fest. Prüfen Sie dann die OnInit()-Methode auf das Dirty-Flag, und rufen Sie SetPersonalizationDirty auf. Im folgenden Beispiel wird beschrieben, wie Sie dabei vorgehen müssen.
using Asp = System.Web.UI.WebControls.WebParts
public class MyWebPart : Asp.WebPart
{
private m_dirty = false;
[Standard Web Part logic here...]
void IVersioningPersonalizable.Load(IDictionary unknownProperties)
{
[Copy X into Y here…]
m_dirty = true;
}
protected override void OnInit(EventArgs e)
{
if (m_dirty && null != WebPartManager)
{
SetPersonalizationDirty();
m_dirty = false;
}
}
}
Im vorherigen Beispiel wird Load() aufgerufen, wenn das Teil dynamisch ist oder über einen Objektmodellaufruf instanziiert wird, diese Methode wird aber bei einem seitenstatischen Webpart NICHT aufgerufen.
Das Webpartframework ruft IVersioningPersonalizable-Schnittstellenmethoden unabhängig von den Anmeldeinformationen eines Benutzers auf. Wenn das Webpart im vorherigen Beispiel vom IVersioningPersonalizable-Code korrekt as Dirty gekennzeichnet wurde, wird dadurch ein automatischer Speichervorgang des aktualisierten Webparts im Speicher ausgelöst. Hierzu wird interner Code verwendet, der keine Prüfung der Anmeldeinformationen vornimmt. Das Upgrade wird also auch dann wie erwartet ausgeführt, wenn der erste Besuch der Seite durch einen Benutzer mit eingeschränkten Berechtigungen (z. B. einem Leser) erfolgt.
Im Fall eines seitenstatischen Webparts wird Load() nicht aufgerufen. Allerdings können Sie im OnInit()-Aufruf Code hinzufügen, um die expando-Eigenschaften (ein Konzept von ASP.NET-Steuerelementen, das im Webpartframework nicht vorkommt) des Webparts zu untersuchen, den X-Wert aus den expando-Eigenschaften zu kopieren und diesen Wert Y zuzuweisen. Darüber hinaus gibt es in diesem Fall keine Unterstützung für das Ändern des Seitenmarkups nach dem Ausführen des Upgradecodes für das Webpart. Das bedeutet, dass das Markup immer im Zustand vor dem Upgrade verbleibt und der OnInit()-Upgradecode immer wieder ausgeführt wird, wenn die Seite aufgerufen wird.
Siehe auch
Konzepte
Webparts in SharePoint Foundation
Durchführen eines Upgrades für Seiten