Communardo Techblog

Mit den Visual-Studio-Erweiterungen für Sharepoint wird der Entwickler schon sehr gut beim Deployment auf seinem Entwicklungssystem unterstützt. Ein Nachteil ist jedoch, dass der Deployment-Prozess recht lang dauert. Der Grund ist, dass der Workflow in eine Solution verpackt und deployed wird.

Um das Deployment während der Entwicklung zu beschleunigen, kann direkt nach dem Build eine Batch-Datei ausgeführt werden, die diese Aufgabe übernimmt. Post-build events werden direkt in den Projekteigenschaften unter “Build Events” konfiguriert. Um eine Batch-Datei aufzurufen ist folgender Befehl notwendig:

call “$(ProjectDir)\PostBuildEvent.bat”

Um die Batch-Datei möglichst generisch zu gestalten stehen diverse Makros zur Verfügung, die als Parameter übergeben werden können.

Folgende Aktionen sind per Batch auszuführen:

1. Assembly zum GAC hinzufügen mittels GACUtil
2. Kopieren von Dateien in den 12-Ordner von Sharepoint
3. Kopieren von Dateien direkt in die Sharepoint-Datenbank. Dies kann mittels UNC-Pfad geschehen. Bsp: \\server\website1\documents
4. Deaktivieren des Features
5. Deinstallieren des Features
6. Installieren des Features
7. Aktivieren des Features
8. IISRESET

Sollte es nur ein Webpart sein, können die Punkte 4-7 ausgelassen werden. Alternativ kann die DLL auch ins BIN-Verzeichnis von Sharepoint kopiert werden, anstatt sie im GAC zu deployen. Die Verzeichnisse können mittels Umgebungsvariablen und der oben bereits erwähnten Makros systemunabhängig ermittelt werden. Mit dem eigenen Deployment lässt sich während der Entwicklung viel Zeit sparen…

Dieser Blogeintrag stellt eine Deployment-Variante für Sharepoint-Enwicklungen, wie z.B. WebParts oder Workflows, vor. Im Mittelpunkt stehen zwei Open-Source-Tools zur Erstellung und zum Deployment von Sharepoint Solutions.

Zuerst werde ich jedoch kurz beispielhaft die manuelle Vorgehensweise vorstellen: Ausgangspunkt ist ein Sharepoint-Workflow, der mit Visual Studio entwickelt wurde. Auf dem Entwicklersystem geschieht das Deployment mittels des Visual Studio-Plugins vollautomatisch. Soll der Workflow nun auf einem fremden System deployed werden, sind eine Reihe von Schritten notwendig:

1. Compilieren des Projekts
2. Kopieren/Installieren der Assembly auf das Zielsystem
3. Kopieren der Feature-Dateien auf das Zielsystem
4. Ggf. Deaktivieren/Deinstallieren des vorhandenen Features
5. Installieren/Aktivieren des Features auf dem Zielsystem
6. IISRESET

Die einzelnen Schritte lassen sich durchaus scripten, aber eine einfache und elegante Deployment-Möglichkeit wird dadurch nicht geschaffen. Abhilfe schaffen hier zwei Open-Source-Tools: WSPBuilder und SharepointInstaller.

Der WSPBuilder erstellt aus einer vorgegebenen Struktur eine WSP-Datei. Im Wesentlichen müssen nur die notwendigen Dateien in eine Sharepoint-ähnliche Ordnerstruktur (12/…) kopiert und das Programm gestartet werden. Es können alle Dateien automatisch deployed werden, die unter dem 12-Pfad liegen müssen. Assemblies müssen in ein spezielles Verzeichnis namens GAC kopiert werden, damit Sie automatisch in den Assembly Cache deployed werden. Der WSPBuilder ist sehr gut per Kommandozeile konfigurierbar. Sinnvoll ist es, den Namen der Solution (WSPName) sowie den Ausgabepfad selbst festzulegen (OutputPath). Letzteres ist insbesondere für die Nutzung des SharepointInstallers hilfreich. Die Kommandozeilenoptionen können mit Hilfe des Parameters /? abgerufen werden.

Die nun vorhandene WSP-Datei kann mit dem Sharepoint-eigenen Tool STSADM deployed werden. Einfacher ist es aber, den SharepointInstaller zu verwenden. Dieser bietet eine Standard-Installationsoberfläche und prüft zudem ob bestimmte Voraussetzungen für die Installation von Sharepoint-Solutions vorhanden sind. Für die Installation sind drei Dateien notwendig: setup.exe, setup.exe.config und die zuvor erstellte Solution. Alle Parameter für das Setup können in der config-Datei eingestellt werden. Besonders wichtig ist die Solution-ID, welche der WSPBuilder im gleichen Verzeichnis wie die Solution ablegt. Genauere Informationen zur Konfiguration enthält die Readme-Datei.

Das vorhandene Setup-Paket kann nun ausgliefert und installiert werden. Es werden alle Features aktiviert. Beim Ausliefern eines Updates oder eines Patches kann ebenfalls der SharepointInstaller verwendet werden. Während der Installation muss hier Repair ausgewählt werden.

Bei der Verwendung von Spring stellt sich im Buildmanagement die Frage wie mit Properties umgegangen wird. So hat jeder Test-, Live- und Entwicklungsserver seine eigene Datenbank oder andere unterschiedliche Einstellungen. Eine oft gewählte Variante ist die Ersetzung der Properties durch den Buildprozess. Dies hat allerdings den Nachteil, dass für eine Änderung der Properties der Buildprozess neu ausgeführt werden muss.

Mit Spring bietet sich dabei eine Alternative: Hier kann ein Propertyfile welches z. B. im Classpath liegt eingebunden werden:

<bean id="propertyPlaceholder" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="classpath:hibernate.properties" />
</bean>

Die Properties, die dann in dem File ‘hibernate.properties’ definiert sind, können innerhalb der Springkonfiguration genutzt werden:

...
<property name="hibernateProperties">
<props>
<prop key="hibernate.show_sql">${hibernate.show_sql}</prop>
<prop key="hibernate.dialect">${hibernate.dialect}</prop>
<prop key="hibernate.hbm2ddl.auto">${hibernate.hbm2ddl.auto}</prop>
...
</props>
</property>
...


Das Property File selbst ist dabei einfach wie erwartet:

hibernate.show_sql=true
hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
hibernate.hbm2ddl.auto=update

Da man ja sehr oft und sehr gerne auf virtuellen Maschinen entwickelt und auch zum Deployment nicht unbedingt ein paar hundert Kilometer reisen möchte, wird gerne zur Remote Desktop Verbindung gegriffen.

Dazu gibt es bei Unterwegs im Net eine ausführliche Beschreibung. Unter anderem die notwendigen Ports, damit man nicht an der Firewall des Kunden hängenbleibt.

Link: Unterwegs im Net

Eigenentwickelte Webparts werden oftmals in den Global Assembly Cache (GAC) des Sharepoint Servers deployed, da dort z.B. die erforderlichen Sicherheitseinstellungen und die Versionsverwaltung gegeben sind. Während der Entwicklungszeit ist dies aber wegen des dafür erforderlichen iisreset ziemlich lästig und in der Regel auch nicht notwendig. Eine bequemere Lösung ist es, während der Entwicklungszeit in den Sharepoint bin-Ordner zu deployen.

Folgende Schritte sind dafür erforderlich:

1. Die Assembly kann, muss aber nicht mit einem Strong Name versehen werden.
2. Referenz auf System.Security zum Webpart-Projekt hinzufügen
3. In AssemblyInfo.cs einfügen:
   
   using System.Security;
   [assembly: AllowPartiallyTrustedCallers()]

4. –> Project Properties –> build auf den Sharepoint bin-Ordner einstellen (bzw. im PostBuilt Event dorthin kopieren)
   (standardmäßig ist dieser nicht vorhanden - einfach einen Ordber “bin” unterhalb des Ordners für die Sharepoint Anwendung anlegen)
5. <SafeControls> Eintrag in der web.config der Sharepoint Anwendung wie gehabt, z.B.

   <SafeControl>Assembly=”TestWebPartLibrary, Version=1.0.0.0, Culture=neutral,
   PublicKeyToken=3f4ba00116c78ec4″ Namespace=”TestWebPartLibrary” TypeName=”*”
   Safe=”True” />

6. <securityPolicy> Eintrag in der web.config wie folgt ergänzen:

   <securityPolicy>
   [...]
   <trustLevel name=”Full” policyFile=”internal”/>
   </securityPolicy>

7. <trust> Eintrag in der web.config auf “Full” einstellen:

   <trust level="Full" originUrl="" />

Nun genügt ein einfaches Build in der VS.Net Entwicklungsumgebung und der Webpart ist deployed