Die Windows SharePoint Services 3.0 Infrastruktur sieht vor, dass SharePoint Erweiterungen (Web Parts, Templates, Event handlers, ...) via SharePoint Solutions und Features deployed werden. Damit wird ein End-to-end Prozess für den Entwicklungs-, Test- und Deploymentprozess von Individuallösungen zur Verfügung gestellt: Entwickler erstellen die Deployment Pakete, Tester testen die Lösung im Staging und die Administratoren können diese in der SharePoint Administration auf ausgewählten SharePoint Servern deployen. Power Users oder "lokale Administratoren" können anschliessend die gewünschten Features aktivieren.

Die erwähnten Features sind den meisten SharePoint Power Usern bekannt. Sie erlauben, eine gewisse Funktionalität (z.B. ein Web Part) zu aktvieren resp. zu deaktivieren:

image

Um SharePoint Funktionalität zu deployen, kommen grundsätzlich mehrere Zielorte auf dem Server in Frage:

  • Der Global Assembly Cache für die dlls (Web Part Logik, Event handlers, ...) oder /bin Verzeichnis
  • Das web.config File im virtuellen SharePoint Verzeichnis auf dem IIS
  • Das Verzeichnis C:\Program Files\Common Files\Microsoft Shared\web server extensions\12 für "globale Definitionen" wie z.B. Features und Site Definitions

Dies verdeutlicht die Komplexität des Deployments. SharePoint Solutions bieten die Möglichkeit, mehrere Programmkomponenten (Web Parts, Event handlers, ...) als eine Einheit zu deployen. Dies sind die sogenannten WSP Dateien, welche das CAB Format verwenden.

Die Vorteile von SharePoint Solutions und deren Komplexität sind auch hier genauer beschrieben: http://blogs.msdn.com/cjohnson/archive/2006/09/11/749105.aspx.

Die Vereinfachung des Solution Deployments

Seit wenigen Tagen steht nun das sogenannte STSDEV Tool zur Verfügung. Dieses nimmt dem Entwickler im Prinzip die ganze Komplexität des Packaging und Deployments ab. Das Open Source Tool von Ted Pattison kann hier runtergeladen werden: http://www.codeplex.com/stsdev.

Es werden zahlreiche Projekttypen für Visual Studio 2005 und Visual Studio 2008 unterstützt:

image

Das Tool eignet sich also auch hervorragend für Entwickler, welche die SharePoint Projekttemplates in Visual Studio 2008 vermissen. Via Build in Visual Studio kann die Lösung direkt installiert, desinstalliert, usw. werden. Im Hintergrund wird dazu das SharePoint STSADM command line Tool verwendet:

image

Ich hoffe, dass Sie damit vermehrt das Solution Deployment von SharePoint verwenden werden!

Übrigens: Wenn Sie eigene Workflows für SharePoint entwickeln möchten, setzen Sie am besten Visual Studio 2008 ein: Hier wird nämlich ein brandneues Template genau für diesen Zweck zur Verfügung gestellt. Dieses erledigt neu auch das Packaging und Deployment für Sie.