CMS mit SharePoint 2007 - Teil 1: Das SharePoint Variation System

Ich weiß, dass es einige Webseiten gibt, die insgesamt wahrscheinlich eine Menge Gründe nennen können, warum man Variations mit SharePoint 2007 nicht einsetzen sollte.

Im aktuellen Projekt war die Entscheidung für Variations bereits lange vor Beginn gefallen…

Daher ein paar nützliche Hinweise die man evtl. vorher beachten sollte oder die im Nachhinein vielleicht noch was retten können. ;-)

1. Insgesamt ist das Variationsystem leider sehr instabil, auch mit installiertem SP1.
   Beispiel: Für die Migration von einem vorhandenen alten System haben wir u.a. ein Tool geschrieben, um aus Einträgen einer SharePoint Liste Sites und Pages auf einem Zielsystem zu erstellen. Sei es über as SP Objektmodell oder über stsadm, stellenweise und aus unerfindlichen Gründen knallt es beim Anlegen der Variations. Da die Sourcesprache aber (durch unseren code) (meistens) korrekt angelegt wird, ist der dahinterliegende Timerjob des Variationsystems das Problem.
   Eine wirkliche Lösung gibt es offensichtlich bisher nicht, daher führen wir das Erstellen der Sites und Pages nun verzögert aus, um jeweils nach ein paar Sites erstmal auf den SharePoint Timerjob zu warten…
2. Variations per SharePoint Solution/Feature deployen bereitete uns ebenfalls einige Kopfschmerzen.
   Die Labels der Variationen die man anlegen möchte, lassen sich noch relativ leicht über ein paar Zeilen code in einem Feature Receiver anlegen. Um nun die Hierarchien zu erstellen, kann man entweder über die GUI gehen und auf den Button “Create Hierarchies” klicken oder man macht auch das per Code. Sinnvoll ist es, damit man später das ganze wirklich ohne manuelle Eingriffe von einem Administrator installieren lassen kann. Leider will Microsoft das wohl nicht, denn die zugehörige Klasse, bzw. Methode ist als internal deklariert und somit nicht verfügbar. Da das inakzeptabel ist, half nur ein Artikel von Codeplex, in dem beschrieben wird, wie man mittels Reflection doch noch zum gewünschten Ergebnis kommt. Und ja, die Alternative die Seite per WebRequest aus dem Code raus anzustoßen und vorher entsprechend zu manipulieren funktioniert nur bedingt und natürlich schon gar nicht zusammen mit Mehrsprachigkeit ;-)

Custom ASP.NET 2.0 WebParts und Variations vertragen sich leider gar nicht! Beispiel: Eine Page erstellen, ein (selbst geschriebenes) WebPart hinzufügen und Publish klicken. Das Ergebnis ist ein leerer Eintrag im Variation Log, wo dann zwar Datum und Uhrzeit, aber weder Success, noch Failure Meldungen stehen. Weiterhin passiert dann einfach nichts mehr. Entfernt man das WebPart und klickt erneut auf Publish, funktioniert alles wieder wie es sollte. Nach einiger Recherche gibt es dazu offensichtlich 2 Lösungen: 1\. Man erbt von Microsoft.SharePoint.WebPartPages.WebPart anstatt von System.Web.UI.WebControls.WebParts.WebPart, was jedoch laut Microsoft nicht empfohlen ist, oder 2\. Installiert neben den [Post-SP1 Hotfixes vom 31\. Januar 2008](http://support.microsoft.com/kb/941274/en-us) auch noch das [21\. Februar 2008 Hotfix Package](http://support.microsoft.com/kb/948947/en-us), was genau dieses Problem behebt. Somit können dann auch bereits vorhandene ASP.NET WebParts verwendet werden.

Weitere Teile folgen, denn noch ist das Projekt nicht zu Ende… Im nächsten Beitrag geht es dann um das ebenfalls allseits beliebte Content Deployment und warum  ich das ganze nahezu komplett neu Entwickelt habe…