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…

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