LINQ to SharePoint erlaubt es SharePoint Entwicklern auf den lokalen SharePoint unter Verwendung eines generierten LINQ Contextes streng typisiert auf die Daten in SharePoint zuzugreifen. Doch gerade im täglichen Geschäft werden hierbei immer wieder Fehler gemacht, die leider dazu führen, dass die Anwendungen welche auf LINQ to SharePoint basieren auf Produktivsystem nicht oder nicht korrekt funktionieren.
Aus diesem Grund habe ich einfach mal einen, meiner Meinung nach, sinnvollen Weg zur Verwendung von LINQ to SharePoint identifiziert, welchen ich hier erläutern möchte.
Die Probleme in vielen Projekten
Wenn man mit LINQ to SharePoint arbeiten möchte, muss man zunächst den DataContext erstellen, dieser Datacontext ist der zentrale Punkt (LinqProvider) für den Zugriff mittels LINQ auf SharePoint als Backend. Genau an diesem Punkt werden oftmals schon die ersten und gravierendsten Fehler gemacht.
Problem 1: Kontinuierliche Erstellung des DataContextes fehlt
Der LINQ to SharePoint DataContext sollte automatisiert erstellt werden, darüber hinaus sollte er vor dem eigentlichen Build Vorgang der custom Solution erstellt werden.
Lösung 1:
Der Aufruf von SPMetal.exe muss im PreBuild-Event des gewünschten SharePoint Projektes integriert sein.
“C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\bin\SPMetal.exe” /web:http://youtSPwebURL /code:TargetSourceFile.cs /language:cshar /namespace:TargetName.Space
Wie im Screenshot zu sehen ist, habe ich beim CodeParameter die MSBuild Variable $(ProjectDir) verwendet, welche gefolgt von einem Dateinamen dafür sorgt, das mein LINQ to SharePoint Context an der richtigen Stelle auf der Festplatte erstellt wird. Durch die Integration des SPMetal.exe aufrufes in das PreBuild-Event, kann sicher gestellt werden, dass die aktuelle Solution stets gegen die aktuellste Version des DataContextes kompiliert wird.
Problem 2: Der Scope des DataContext ist zu groß
In vielen Demos und Projekten wird immer der folgende SPMetal.exe Aufruf verwendet oder gezeigt
SPMetal.exe /web:http://youtSPwebURL /code:TargetSourceFile.cs /language:cshar /namespace:TargetName.Space
Hierbei wird der LINQ Context für sämtliche Listen erstellt, was im Umkehrschluss bedeutet, dass die erstellte Lösung meistens unnötige Angriffsflächen bietet. Durch den gezeigten Aufruf von SPMetal.exe werden auch für die Listen Proxy-Klassen erstellt, welche im Projekt- oder Produktscope gar keine Rolle spielen. Anwender mit entsprechenden Rechten auf der SharePoint Seite können nun durch Löschen von Spalten die Funktionalität des LINQ Contextes und somit auch unserer Anwendung beeinträchtigen bzw. gefährden.
Lösung 2:
An SPMetal.exe kann man mit dem Parameter parameters eine eigene XML Konfiguration mitgeben, so dass nur explizit angegebene Listen in den LINQ to SharePoint Kontext aufgenommen werden.
Der korrekte SPMetal Aufruf würde demnach wie folgt aussehen
SPMetal.exe” /web:http://youtSPwebURL /code:TargetSourceFile.cs /language:cshar /namespace:TargetName.Space /parameters: $(ProjectDir)MyCustomLinqConfiguration.xml
Auch an dieser Stelle wieder die Verwendung der $(ProjectDir) Variable von MSBuild, um die XML-Datei aus der aktuellen Projektstruktur zu verwenden.
Was alles im LINQ to SharePoint Parameters File definiert werden kann, kann man der MSDN entnehmen http://msdn.microsoft.com/en-us/library/ee535056.aspx
Problem 3: Vorhandene / manuell erstellte Listen
Auch wenn man die in den LINQ Context aufzunehmenden Listen einschränkt besteht natürlich immer noch die Gefahr, dass diese sich auf dem Staging- oder Developmentsystem vom Produktivsystem unterscheiden. Bei einer solchen Unterscheidung ist die korrekte Funktionsweise des LINQ to SharePoint Contextes ebenfalls nicht gewährleistet.
Lösung 3:
Um die LINQ to SharePoint Proxy-Klassen wirklich richtig zuverlässig zu erstellen, bieten sich hier allerdings bekannte Funktionalitäten aus dem SharePoint an. Zunächst sollten die benötigten Listen in der custom Solution erstellt werden (deklarativ oder programmatisch spielt an dieser Stelle keine Rolle)
Diese ContentType und Listendefinitionen müssen dann über ein separates Feature in SharePoint deployet werden.
Dieses „separate Feature“ kann man auch als Core-Feature bezeichnen. Durch eine Feature Dependency auf dem Feature welches die LINQ to SharePoint Lösung verteilt, muss dieses Core-Feature also als Feature Dependency eingetragen werden.
Optional kann das Core Feature an dieser Stelle dann noch als „Hidden-Feature“ ausgerollt werden. Hierbei ist allerdings zu beachten, dass das Hidden-Feature selbst keine Feature-Dependencies haben darf!
Fazit
Beachtet man meiner Meinung nach diese 3 Regeln, kann man mit LINQ to SharePoint schöne und robuste Solutions bauen, welche die Vorteile von LINQ to SharePoint gegenüber dem „Old-School-Way“ mitbringen.
Happy LINQ’in