Erneutes Bereitstellen von Anpassungen und Lösungen in SharePoint Foundation 2010 und SharePoint Server 2010

Artikel
06/24/2015

Zusammenfassung: In diesem Artikel finden Sie Informationen zum erneuten Bereitstellen von Anpassungen und benutzerdefinierten Lösungen, die Sie für Windows SharePoint Services 3.0 und Microsoft Office SharePoint Server 2007 in Microsoft SharePoint Server 2010 und Microsoft SharePoint Foundation 2010 erstellt haben.

Letzte Änderung: Mittwoch, 12. Januar 2011

James Crowley, Microsoft Corporation

Inhalt dieses Artikels
Erste Schritte mit dem Objektmodell für 2010-Versionen
Installieren der Upgrades
Arbeiten mit dem Objektmodell für 2010-Versionen
Änderungen an der Benutzeroberfläche
Schlussbemerkung
Weitere Ressourcen

Michael Washam, Microsoft Corporation

Oktober 2009

Inhalt

Erste Schritte mit dem Objektmodell für 2010-Versionen
Installieren der Upgrades
Arbeiten mit dem Objektmodell für 2010-Versionen
Änderungen an der Benutzeroberfläche
Schlussbemerkung
Weitere Ressourcen

Laden Sie die Listen mit den veralteten Typen und Methoden zu diesem Artikel herunter:Microsoft SharePoint Server 2010: Veraltete Typen und Methoden

Erste Schritte mit dem Objektmodell für 2010-Versionen

Microsoft SharePoint Foundation 2010 und Microsoft SharePoint Server 2010 enthalten Objektmodellupgrades, die mit vorhandenen für Windows SharePoint Services 3.0 und Microsoft Office SharePoint Server 2007 entwickelten Lösungen kompatibel sind. Einige Namespaces, Klassen und Methoden sind jetzt veraltet, stehen aber noch zur Verfügung und liefern weiterhin das erwartete Ergebnis in benutzerdefiniertem Code. Obwohl die Benutzeroberfläche umfassend geändert wurde, können Sie mithilfe des visuellen Modus für die Abwärtskompatibilität visuelle Anpassungen beibehalten, bis Sie die Benutzeroberflächenverbesserungen übernehmen können. Sie können vorhandene Anpassungen und Anwendungen mit den aktualisierten Versionen von Microsoft SharePoint Foundation 2010 und Microsoft SharePoint Server 2010 synchronisieren, wenn Sie diese erneut bereitgestellt haben. In diesem Artikel finden Sie Anleitungen, die Ihnen helfen sollen, Herausforderungen beim erneuten Bereitstellen, Testen und Debuggen von Code für Windows SharePoint Services 3.0 und Office SharePoint Server 2007 in SharePoint Foundation 2010 bzw. Microsoft SharePoint Server 2010 zu vermeiden oder zu bewältigen.

Wenn Sie Projekte für Windows SharePoint Services 3.0 oder Office SharePoint Server 2007 mit Microsoft Visual Studio 2005 Extensions for Windows SharePoint Services 3.0, Version 1.1, Microsoft Visual Studio 2005 Extensions for Windows SharePoint Services 3.0, Version 1.2 und Microsoft Visual Studio 2005 Extensions for Windows SharePoint Services 3.0, Version 1.3 erstellt haben, können Sie diese Projekte mit dem VSeWSS-Upgradetool aktualisieren. Mit diesem Tool werden Vorlagen installiert, mit denen vorhandene Visual Studio-Erweiterungen für Windows SharePoint Services-Lösungspakete (die in Microsoft Visual Basic oder Microsoft Visual C# geschrieben wurden) in Microsoft Visual Studio 2010-Lösungen konvertiert werden können (Abbildung 1).

Abbildung 1. Importieren eines Visual Studio Extensions for Windows SharePoint Services-Projekts in Visual Studio 2010

Importieren von VSeWSS in Visual Studio 2010

Wenn Sie die Visual Studio Extensions for Windows SharePoint Services-Lösungen in Visual Studio 2010-Lösungen konvertiert haben, müssen Sie die neuen Lösungspakete im aktualisierten Framework bereitstellen.

Installieren der Upgrades

Sie können die Upgrades direkt (in einer Serverfarm, in der Windows SharePoint Services 3.0 oder Office SharePoint Server 2007 bereits installiert ist) oder in einer neuen Serverfarm ausführen, der Sie oder der Administrator die vorhandene Inhaltsdatenbank anfügen. In beiden Fällen erzielen Sie das beste Ergebnis, wenn Sie SharePoint-Lösungspaketdateien (WSP) anstelle von Windows Installer-Paketen (MSI) verwenden. Wenn Sie eine Websitevorlage erneut bereitstellen müssen, müssen Sie eine Websitevorlage von der Vorlage erstellen und als Lösungspaket speichern. Am wichtigsten ist dabei zunächst, dass Sie sicherstellen, dass für alle Bereitstellungen als Zielspeicherort der "14"-Ordner und nicht der "12"-Ordner festgelegt ist; dies wird durch Lösungspakete vereinfacht. Sowohl in SharePoint Foundation 2010 als auch in SharePoint Server 2010 wird der Ordner 12\TEMPLATE\FEATURES überprüft, wenn im entsprechenden "14"-Ordner keine Datei gefunden wird. Möglicherweise werden jedoch in anderen Ordnern bereitgestellte benutzerdefinierte Dateien nicht gefunden. Außerdem können Sie Installationen deutlich leichter debuggen, wenn alle benutzerdefinierten Dateien im "14"-Ordner bereitgestellt werden.

Verwenden von Lösungspaketen (WSP-Dateien)

Stellen Sie nach Möglichkeit benutzerdefinierte Lösungen mithilfe von Lösungspaketen (WSP-Dateien) bereit, da Sie auf diese Weise am besten sicherstellen können, dass alle benutzerdefinierten Dateien in den richtigen Speicherorten bereitgestellt werden. Weitere Informationen zum Erstellen von Lösungsdateien in Windows SharePoint Services 3.0 und Office SharePoint Server 2007 finden Sie unter Erstellen einer Lösung. Weitere Informationen zum Bereitstellen von Lösungsdateien in SharePoint Foundation 2010 und SharePoint Server 2010 finden Sie unter Installieren und Bereitstellen einer Farmlösung.

Verwenden von Windows Installer-Dateien

Wenn Sie benutzerdefinierte Lösungen mithilfe von Windows Installer-Paketen (MSI) bereitstellen, müssen Sie diese unbedingt ändern, damit die benutzerdefinierten Dateien in den richtigen Speicherorten im "14"-Ordner bereitgestellt werden. Dies gilt insbesondere, wenn Sie Dateien in anderen Speicherorten als im Ordner TEMPLATE\FEATURES bereitstellen.

Erneute Bereitstellung von Websitevorlagen

Websitevorlagen sind veraltet. Wenn Sie eine Websitevorlage für SharePoint Foundation 2010 oder SharePoint Server 2010 erneut bereitstellen müssen, führen Sie diese Schritte aus:

Erstellen Sie eine Website von der Websitevorlage.
Installieren Sie SharePoint Foundation 2010 oder SharePoint Server 2010 in der vorhandenen Serverfarm oder in einer neuen Serverfarm. Wenn Sie die Upgrades in einer neuen Serverfarm installieren, fügen Sie die Inhaltsdatenbank, die die von Ihnen erstellte Website enthält, der neuen Farm an.
Wählen Sie in der neuen Installation die Option Website als Vorlage speichern auf der Seite Websiteeinstellungen aus. Daraufhin wird ein Lösungspaket mit der Dateinamenerweiterung WSP erstellt.

Arbeiten mit dem Objektmodell für 2010-Versionen

Das Objektmodell enthält viele Änderungen und Verbesserungen. Benutzerdefinierter Code kann dennoch kompiliert werden und wird, mit einer möglichen Ausnahme, wie erwartet ausgeführt. Wenn für eine der Anpassungen Listenabfragen verwendet werden, bei denen Ergebnissätze mit mehr als 5.000 Elementen generiert werden können oder bei denen alle Zeilen von Listen mit mehr als 5.000 Elementen durchsucht werden, müssen Sie den Schwellenwert für die Abfragegröße ändern (Anweisungen hierzu finden Sie unter Abfrageeinschränkung für umfangreiche Listen). Anderenfalls können Sie die Änderungen untersuchen und die neuen Elemente des Objektmodells nach Ihrem eigenen Zeitplan integrieren. Das aktualisierte Objektmodell ermöglicht alternative Methoden, mit denen Sie in vielen Fällen das Design und die Leistung von Anpassungen verbessern können.

Abwärtskompatibilität

Da die Änderungen an der API in den Upgrades abwärtskompatibel sind, sollten keine Änderungen an benutzerdefiniertem Code notwendig sein, bevor Sie diesen in SharePoint Foundation 2010 oder SharePoint Server 2010 bereitstellen. Einige Klassen und Namespaces sind veraltet, sind aber weiterhin wie erwartet funktionsfähig. Wenn Sie mit dem Aktualisieren von Anwendungen beginnen möchten, damit die aktuellen Klassen und Methoden verwendet werden, kompilieren Sie den Code erneut. Den Compilerwarnungen können Sie entnehmen, welche Elemente des Objektmodells veraltet sind und welche neueren Alternativen Sie verwenden sollten. In Abbildung 2 werden ein Beispiel für eine Compilerwarnung und die entsprechende Mouseoverwarnung in Visual Studio 2010 gezeigt.

Abbildung 2. Compilerwarnung für veralteten Konstruktor in Visual Studio 2010

Compilerwarnung in Visual Studio 2010

Eine Liste mit den veralteten Typen und Methoden im Objektmodell von Microsoft SharePoint 2010 finden Sie unter Microsoft SharePoint Server 2010: Veraltete Typen und Methoden.

SharePoint Server 2010 enthält mehr als 1.500 veraltete Typen, die meisten davon im Microsoft.SharePoint.Portal-Namespace. SharePoint Foundation 2010 enthält erheblich weniger veraltete Typen, aber mehrere Hundert veraltete Methoden und Eigenschaften.

Benutzerdefinierten Code, der für Windows SharePoint Services 3.0 und Office SharePoint Server 2007 geschrieben wurde und in den Internetinformationsdiensten (Internet Information Services, IIS) ausgeführt wird, müssen Sie nicht erneut kompilieren. Das bedeutet, dass Sie benutzerdefinierte DLLs ohne erneutes Kompilieren wiederverwenden können; die DLLs sind jedoch möglicherweise nicht wie erwartet funktionsfähig. Wenn Sie beispielsweise alle Dateien im "14"-Ordner erneut bereitgestellt und den "12"-Ordner geleert haben, sind Verweise auf Dateien unterhalb des "12"-Ordners nicht funktionsfähig. Ebenso wie Sie die Windows Installer-Pakete erneut schreiben müssen, wenn diese auf Speicherorte im "12"-Ordner verweisen, müssen Sie auch sämtlichen Code erneut schreiben und kompilieren, in dem auf Dateien und Speicherorte verwiesen wird, die Sie an neue Speicherorte verschoben haben. Bewerten Sie die Anpassungen im Hinblick auf die neue Installation, und stellen Sie sicher, dass sämtlicher Code, der auf bestimmte Details der alten Installation angewiesen ist, auch nach dem Installieren der Upgrades funktionsfähig ist.

Sie sollten für Office SharePoint Server 2007 geschriebenen benutzerdefinierten Code erneut kompilieren, wenn die Lösung einen Featureempfänger enthält, durch den die Methoden FeatureInstalled, FeatureUninstalling, FeatureActivated oder FeatureDeactivating implementiert werden, und Sie die Bereitstellung mithilfe des Befehlszeilentools Stsadm oder des Timerdiensts ausführen. Assemblyumleitungen in SharePoint Server 2010 werden durch Einträge in der Datei web.config des Servers behandelt, und Befehlszeilentools leiten möglicherweise erst nach der Installation der Lösung an die neueren Assemblyversionen um.

Für Windows SharePoint Services 3.0 und Office SharePoint Server 2007 geschriebenen benutzerdefinierten Code, der nicht in IIS ausgeführt wird (beispielsweise Konsolenanwendungen und Dienste), müssen Sie erneut kompilieren.

Abfrageeinschränkung für umfangreiche Listen

In SharePoint Foundation 2010 und SharePoint Server 2010 wird für Abfragen ein Standardschwellenwert von 5.000 Elementen angewendet. Benutzerdefinierter Code, in dem Abfrageergebnissätze verwendet werden, die diesen Maximalwert überschreiten können, zeigt nach dem Upgrade nicht das erwartete Verhalten. Bei Abfragen für Listen mit mehr als 5.000 Elementen, deren Abfragebedingungen nicht indizierte Felder enthalten, treten ebenfalls Fehler auf, da bei diesen Abfragen alle Zeilen der Liste durchsucht werden müssen. Sie können diesen Grenzwert erhöhen (durch Festlegen der EnableThrottling-Eigenschaft für das SPList-Objekt) oder die Außerkraftsetzung durch das Objektmodell aktivieren. Anleitungen für die effiziente Behandlung von umfangreichen Ordnern und Listen finden Sie unter Arbeiten mit umfangreichen Ordnern und Listen und Schreiben von effizientem Code in SharePoint Server.

Erhöhen des Standardschwellenwerts für Abfragen

Klicken Sie auf der Website für die Zentraladministration unter Anwendungsverwaltung auf Webanwendungen verwalten.
Klicken Sie auf Allgemeine Einstellungen und dann auf Ressourcensteuerung (Abbildung 3).

Abbildung 3. Festlegen des Schwellenwerts für die Abfragegröße in SharePoint Foundation 2010 und SharePoint Server 2010

Festlegen des Schwellenwerts für die Abfragegröße

Neue SharePoint-Funktionen

Zu den wichtigen Ergänzungen des Objektmodells von SharePoint Foundation 2010 und SharePoint Server 2010 gehören die folgenden neuen Funktionen:

Der Microsoft.SharePoint.Linq-Namespace, durch den ein LINQ-to-SharePoint-Anbieter definiert wird. Durch diesen werden LINQ-Abfragen in CAML-Abfragen (Collaborative Application Markup Language) übersetzt (sodass Sie die Möglichkeit haben, Listenabfragen und CAML-Abfragen durch LINQ zu ersetzen).
Drei clientseitige APIs im Microsoft.SharePoint.Client-Namespace, die Interaktionen mit SharePoint-Websites über Skripts ermöglichen, die im Browser über verwalteten Microsoft .NET Framework-Code und in Microsoft Silverlight-Anwendungen ausgeführt werden.
SharePoint Foundation 2010 und SharePoint Server 2010 enthalten zahlreiche Ergänzungen, die durch Business Connectivity Services bereitgestellt werden. Aufgrund dieser Änderungen können Sie externe Geschäftsdaten und -prozesse leichter in Server- und Clientanwendungen integrieren.

Weitere Informationen zur Verwendung dieser und anderer neuer APIs finden Sie unter Neuerungen in SharePoint Foundation 2010 und Neues in SharePoint Server 2010.

Im Diagramm in Abbildung 4 wird ein Beispiel für die Namespaces gezeigt, denen zahlreiche Typen hinzugefügt wurden.

Abbildung 4. Neue Typen nach Namespace in SharePoint Server 2010

Neue Typen nach Namespace

Änderungen an der Benutzeroberfläche

Da die Benutzeroberfläche in SharePoint Foundation 2010 und SharePoint Server 2010 umfassend geändert wurde, erzielen Sie für Benutzer die besten Ergebnisse, wenn Sie für Anpassungen, in denen bestimmte CSS-Klassen und Benutzeroberflächenelemente verwendet werden, den Abwärtskompatibilitätsmodus verwenden. Sie können beim Aktualisieren auf SharePoint Foundation 2010 oder SharePoint Server 2010 auswählen, ob Sie den Abwärtskompatibilitätsmodus oder die aktualisierte Benutzeroberfläche verwenden möchten. Sie können auf Websitesammlungsebene oder auf Websiteebene zwischen dem Abwärtskompatibilitätsmodus und der neuen Oberfläche wechseln:

Wenn Sie das Aussehen und Verhalten vorhandener Websites beibehalten möchten, verwenden Sie PSConfig und PSConfigUI.
Wenn Sie das Aussehen und Verhalten vorhandener Websites beim Aktualisieren durch Anfügen der alten Inhaltsdatenbank an eine neue Serverfarm beibehalten möchten, verwenden Sie Stsadm.

Sie können auch die Webbenutzeroberfläche verwenden, um alle Websites in einer Websitesammlung auf die aktualisierte Benutzeroberfläche festzulegen (und zu verhindern, dass Benutzer die ältere Benutzeroberfläche verwenden).

Festlegen aller Websites in einer Websitesammlung auf die aktualisierte Benutzeroberfläche

Klicken Sie unter Websiteeinstellungen auf Websitesammlungsverwaltung
Klicken Sie auf Unterstützte Benutzeroberflächen (Abbildung 5).

Abbildung 5. Ändern der Benutzeroberfläche auf Websitesammlungsebene

Ändern der Benutzeroberfläche auf Websitesammlungsebene

Sie können auch das vorherige Aussehen und Verhalten für eine bestimmte Website auswählen. Klicken Sie unter Websiteeinstellungen auf Titel, auf Beschreibung und dann auf Darstellung (Abbildung 6).

Abbildung 6. Ändern der Benutzeroberfläche auf Websiteebene

Ändern der Benutzeroberfläche auf Websiteebene

Sie können die Version der Benutzeroberfläche auch programmatisch abrufen oder festlegen (3 für den Abwärtskompatibilitätsmodus und 4 für die neue Oberfläche), indem Sie die SPWeb.UIVersion-Eigenschaft verwenden.

Hinweis
Wenn Sie SPWeb.UIVersion auf 3 oder 4 festgelegt haben, müssen Sie die SPWeb.Update-Methode verwenden, um die Änderung zu speichern.

Die UIVersion-Eigenschaft ist auch für die Steuerelemente SharePoint:VersionedContent und SharePoint:VersionedPlaceHolder verfügbar. Mit beiden Steuerelementen werden Inhalte mit Versionsanmerkungen auf der Seite platziert, SharePoint:VersionedPlaceHolder wird jedoch nach dem Rendern verwendet, wenn die Seite fertig geladen wurde.

In den folgenden Beispielen wird gezeigt, wie diese Steuerelemente in ASPX-Dateien implementiert werden.

<SharePoint:VersionedPlaceHolder ID="vph4" runat="server" UIVersion="4">
   <div>Content</div>
</SharePoint:VersionedPlaceHolder>

<SharePoint:UIVersionedContent ID="vc4" runat="server" UIVersion="4">
<ContentTemplate>
<div>Content</div>
</ContentTemplate>
<SharePoint:UIVersionedContent>

Sie können die Einstellung Unterstützte Benutzeroberflächen auf der Weboberfläche aktivieren oder deaktivieren, indem Sie die Boolean-Eigenschaften SPWeb.UIVersionConfigurationEnabled, SPSite.UIVersionConfigurationEnabledInAllWebs und SPSite.UIVersionConfigurationEnabled festlegen. Das Festlegen von SPSite.UIVersionConfigurationEnabled auf false hat die gleiche Auswirkung wie das Auswählen der Option Commit für neue Benutzeroberfläche ausführen unter Websiteaktionen. In beiden Fällen können Sie nicht mehr über die Weboberfläche zwischen den Benutzeroberflächenversionen wechseln (Sie können jedoch nach wie vor programmatisch wechseln, indem Sie die genannten Eigenschaften festlegen).

Im Abwärtskompatibilitätsmodus sind die visuellen Anpassungen weiterhin funktionsfähig, und Sie haben Zugriff auf die gesamte Infrastruktur (einschließlich CSS) im Zusammenhang mit Designs. Dank des Abwärtskompatibilitätsmodus können Sie sich beim Migrieren und Aktualisieren von Anpassungen für die neue Benutzeroberfläche Zeit lassen. Einige visuelle Elemente sind auf der neuen Benutzeroberfläche möglicherweise wie erwartet funktionsfähig, aber einige wenige benutzerdefinierte Aktionen (bei denen die Attribute ControlAssembly, ControlClass und ControlSrc verwendet werden) sind nicht funktionsfähig. Wenn Sie zahlreiche visuelle Anpassungen vorgenommen haben, insbesondere CSS-Anpassungen und Symbolleistenanpassungen, sollten Sie mit dem Abwärtskompatibilitätsmodus beginnen. Wenn Sie die Anpassungen bereitgestellt haben, sollten Sie diese mit der aktualisierten Benutzeroberfläche testen, um zu ermitteln, welche Elemente Sie ändern müssen.

Änderungen an CSS-Klassen

Da die neue CSS-Funktionalität deutlich geändert wurde, sind Anpassungen und Designs, für die die CSS-Klassen in Windows SharePoint Services 3.0 und Office SharePoint Server 2007 verwendet werden, nur im Abwärtskompatibilitätsmodus funktionsfähig. Da Designs in SharePoint Foundation 2010 und SharePoint Server 2010 nicht mehr vorhanden sind, müssen alle Anpassungen und Designarbeiten, bei denen Sie Designs verwendet haben, in die neue Oberfläche importiert werden. Wenn Sie die Seite nach dem Aktualisieren und erneuten Bereitstellen neu entwerfen, sollten Sie die neue Gestaltungsvorlage anpassen, anstatt zu versuchen, die alte CSS-Funktionalität an die überarbeitete Benutzeroberfläche anzupassen.

Benutzerdefinierte Aktionen und Symbolleistenergänzungen

Die meisten benutzerdefinierten Aktionen, einschließlich der benutzerdefinierten Aktionen für Links und ECB-Menüs (Edit Control Block), sind auf der aktualisierten Oberfläche wie erwartet funktionsfähig. Da die Symbolleiste durch das Menüband ersetzt wurde, werden die meisten benutzerdefinierten Aktionen, durch die einer Symbolleiste Schaltflächen hinzugefügt werden, auf der Registerkarte Benutzerdefinierte Befehle des Menübands platziert (Abbildung 7).

Abbildung 7. Benutzerdefinierte Aktionen auf der Symbolleiste und auf der Registerkarte "Benutzerdefinierte Befehle" des Menübands

Benutzerdefinierte Aktionen auf der Symbolleiste und im Menüband

EinCustom Action Element, für das die Attribute ControlAssembly, ControlClass oder ControlSrc verwendet werden, wird jedoch auf der neuen Oberfläche nicht angezeigt. Sie können diese Symbolleistenergänzungen vor dem erneuten Entwerfen der Anwendung funktionsfähig machen, indem Sie den Abwärtskompatibilitätsmodus verwenden. Alternativ können Sie die Option Vollständige Symbolleiste anzeigen für die einzelnen Listenansichten und Listenformulare auswählen, in denen eine benutzerdefinierte Symbolleiste mit diesem Typ von benutzerdefinierter Aktion verwendet wird. Mit der Option Vollständige Symbolleiste anzeigen bewirken Sie, dass die Symbolleiste mit dem Menüband angezeigt wird. Obwohl dadurch eine gewisse Funktionalitätsredundanz entsteht, bietet sich diese Option möglicherweise an, wenn die benutzerdefinierten Symbolleisten nur in begrenztem Kontext angezeigt werden.

Schlussbemerkung

Sie können sofort nach der Installation von den erweiterten Funktionen in SharePoint Foundation 2010 und SharePoint Server 2010 profitieren; Sie müssen Ihren Code jedoch nicht sofort neu schreiben. Alle veralteten Elemente der API stehen weiter zur Verfügung, sodass Sie Zeit haben, die neueren Elemente der API zu untersuchen, bevor Sie diese in Anpassungen integrieren. Außerdem können Sie sich dank des Abwärtskompatibilitätsmodus Zeit nehmen, um die Anpassungen zu überdenken und gegebenenfalls erneut zu entwerfen, um die neue Benutzeroberfläche in vollem Umfang zu nutzen. Es ist auch nicht notwendig, die neue Benutzeroberfläche für alle Websites gleichzeitig zu übernehmen. Sie können für manche Websites weiterhin die letzte Version der Oberfläche verwenden und für andere Websites sofort die neue Version übernehmen. Das Framework gibt Ihnen die Möglichkeit, die Anpassungen methodisch und phasenweise zu migrieren und von den neuen Funktionen zu profitieren, sodass Sie die Erweiterungen im für Sie optimalen Tempo übernehmen können.

Freigeben über