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…

In Visual Studio 2005 gibt es leider einen kleinen Bug in den “Extensions for WF”. Das Debuggen von Workflows, also nicht des Quellcodes, funktioniert oft nur schlecht oder garnicht. Häufig stürzt das Visual Studio sogar ab, wenn man versucht den Debugger an einen Prozess zu hängen, der Workflows verwendet. Einen solchen Prozess erkennt man recht leicht, indem man einen Blick auf den Typ wirft. Steht dort u.a. “Workflow” (siehe Abbildung) sollte man sich besser nicht an den Prozess hängen.

Verhindern lässt sich dieser Effekt indem man das Visual Studio bereits an den Prozess hängt, bevor die Assembly des Workflows geladen wurde, wobei ggf. vorher ein iisreset durchgeführt werden muss. Sobald die Assembly geladen wurde, lässt sich der Quelltext wie gewohnt debuggen.

Bei der Entwicklung von Workflows mit den WSS-Plugins für Visual Studio kommt es häufig vor, dass von einem Workflow nach dem Deployment keine neuen Instanzen mehr gestartet werden können. Der Workflow fehlt dann in der Auswahlliste, obwohl er ordnungsgemäß installiert und aktiviert ist. Ursache des Problems ist, dass der Workflow auf “Keine neuen Instanzen” gestellt wird, nach er deployed wurde. Die Option zur Reaktivierung des Workflows wurde von Microsoft in den Workfloweinstellungen unter “Workflow entfernen” bzw. “Remove Workflows” versteckt.