Gelegentlich kann es vorkommen, dass aus einem Teilprojekt ein Projekt oder sogar ein Produkt wird. Um die Abspaltung vom eigentlichen Projekt sauber zu vollziehen, ist es notwendig auch die Sourcen in Source Control in ein neues TFS-Projekt zu verschieben.

Folgende Schritte sind notwendig:

1. Lokale Workspaceverknüpfungen für das alte und das neue TFS-Projekt muss vorhanden sein (z.B. mit Check-Out anlegen)
2. Visual Studio-Kommandozeile aufrufen
3. In das Quellverzeichnis des Projektes wechseln
4. Aufruf tf.exe: tf rename <Root-Ordner des alten Projekts> $/NeuesProjekt/
5. Check-In der Änderung (z.B. im Visual Studio)

Um WorkItems zu verschieben, hab ich leider keine gute Lösung gefunden. Wenn jemand einen Hinweis hat, freue ich mich über einen entsprechenden Kommentar.

Der Communardo Inline Process Editor (IPE) ist ein Silverlight-Control, welches es ermöglicht, klar definierte Prozesse direkt in einem angebundenen Content Management System zu modellieren. Zur Zeit ist die Anbindung an den Microsoft Sharepoint Server 2007 und Atlassian Confluence realisiert. Eine Anbindung an beliebige weitere webbasierte Systeme ist dank einer klar definierten Schnittstelle mit nur wenig Aufwand möglich.

Nachdem wir den IPE auf verschiedenen UserGroups und Konferenzen vorgestellt haben, gibt es nun ein Demo-System wo jeder den IPE einmal ausprobieren kann.

Zugangsdaten zum DemoSystem:

http://projekte.communardo.de/websites/ipedemo (User: ipedemo, Password: Communardo09!)

Auch wenn der IPE nicht so bunt und animiert wie die meisten Silverlight-Anwendungen ist, hat er doch einen entscheidenden Vorteil: Er ist praxisrelevant. Daher haben wir uns entschlossen, ihn bei der Silverlight Coding Competition von ComponentArt.com einzureichen. Wir freuen uns natürlich über jede positive Bewertung und jede Menge Feedback (Kommentarfunktion an diesem Artikel oder gern auch per Mail).

Nachdem im ersten Teil dieser Reihe hauptsächlich Voraussetzungen für den Einsatz behandelt wurden, möchte ich nun einen Überblick über neue Features geben. Einige der nun folgenden Features werden ich in einem eigenen Beitrag genauer unter die Lupe nehmen.

Team Build

Der Build-Prozess kann nun mittels Activities innerhalb eines Workflows gesteuert werden. Das lästige Schreiben von XML-Dateien entfällt nun. Die Workflows basieren natürlich auf der Workflow Foundation von .NET 4.0. Außerdem gibt es in der neuen Version ein Build Agent Pooling. Man kann also mehrere Build Agents parallel laufen lassen und Team Build wählt selbstständig je nach Lastverhalten einen verfügbaren Agent aus. Hier kann es selbst in kleinen Teams sinnvoll sein, mit Hilfe von Virtualisierung mehrere Agents auf einer physischen Maschine aufzusetzen.

Version Control

In Version Control gibt es zwei wichtige Neuerungen. Die Branching-Strategie kann nun graphisch geplant und ausgewertet werden. Es ist z.B. möglich, genau nachzuverfolgen, in welchen Branches ein bestimmtes Work Item (mit seinen Changesets) eingeflossen ist. Direkt aus der Visualsierung kann per Drag&Drop gemergt werden.
Eine weitere Neuerung sind die Gated check-ins. Mit dieser Funktion soll verhindert werden, dass ein Projekt nach einem Check-in nicht mehr automatisch gebaut werden kann. Bei einem gated check-in wird der check-in erstmal vorläufig ausgeführt. Erst, wenn je nach Konfiguration ein erfolgreicher Build und die Tests durchgelaufen sind, wird der Check-In final. Falls nicht, wird alles zurückgerollt.

Administration

Für die Administratoren stellt Microsoft jetzt eine MMC bereit. Die Konfiguration per Kommandozeile ist also nicht mehr notwendig. Durch eine sauberere Trennung der einzelnen Bestandteile soll der TFS leichter skalierbar sein. Neu sind auch Team Project Collections, mit denen sich Team Projekte zusammenfassen lassen. Das neue Setup soll die Installation besonders für kleinere Umgebungen vereinheitlichen. Ziel ist es, dass der TFS in 30 min. installiert werden kann.

Reports und Office

Die Reports, welche wie bisher im Sharepoint-Portal verankert sind, werden jetzt vom SQL Server 2008 (Reporting Server) generiert und wurden von Micrsosoft komplett überarbeitet. In der aktuellen CTP sollen sie bereits im finalen Zustand enthalten sein.
Die Integration mit Excel wurde verbessert. Es ist nun möglich, die konkrete Entwicklung detailliert zu planen. Hier ist eine klare Konkurrenz zu MS Project zu erkennen, auch wenn der TFS natürlich bei weitem nicht an den Funktionsumfang eines Project Servers heranreicht. Mit Spannung ist daher die Umsetzung der angekündigten Integration in den Project Server zu erwarten.

Quality Tools

In Bezug auf Qualität hat sich sehr viel getan. Größtes Paket ist wohl die neue Unterstützung beim Testen. Es wird fortan ein eigenes Tool zum Testen geben, den Test Suite Manager (Codename: Camano). In diesem kann man alle Testarten und die jeweiligen Fälle sowie Ergebnisse verwalten und auswerten. Die Basis bildet der TFS. Insbesondere für manuelle Tests gibt es eine umfangreiche Unterstützung. Mit dem Manual Test Runner können manuelle Tests anhand eines Testplans durchgeführt werden. Der Test wird dabei aufgezeichnet. Wird ein Fehler gefunden, kann der Tester zum Bug auch ein Video liefern. Aus aufgezeichneten manuellen Tests können automatisierte Tests gemacht werden (CodedUI Test). Eine weitere Neuheit rund ums Testen ist das Team Test Lab. Mit diesem ist es in Verbindung mit Hyper-V möglich, nach einem Test den Urzustand wiederherzustellen. All dies geschieht automatisiert.

In diesem Beitrag (und in den folgenden) sollen bis zum Erscheinen des Visual Studio Team System 2010 die wichtigsten Neuerungen sowie Gedanken und Vorschläge zum Umstieg vorgestellt werden.

Das VSTS 2010 soll aktuellen Prognosen zufolge Ende 2009 erscheinen. Erfahrungsgemäß liegen die finalen (und ggf. lokalisierten) Versionen dann Anfang 2010 vor. Ein aktuelles CTP (als VirtualPC Image) kann hier heruntergeladen werden.

Systemvoraussetzungen

Bevor überhaupt an einen Umstieg zu denken ist, stellt sich die Frage, welche Systemvoraussetzungen erfüllt sein müssen, damit der TFS 2010 eingesetzt werden kann. Brian Harry (Produktmanager für den TFS) hat in seinem Blog diese Frage recht ausführlich beantwortet. Hier eine kurze Zusammenfassung:

• Betriebssystem: Windows Server 2003 oder 2008, wobei 2008 empfohlen wird und dies wohl der letzte Version mit Unterstützung für 2003 ist. Ebenfalls empfohlen wird der Einsatz eines 64bit-Servers. 32bit werden dennoch weiter unterstützt.
• SQL Server: In der neuen Version wird nur noch SQL Server 2008 unterstützt. Diese Entscheidung wurde wohl hauptsächlich wegen der erweiterten Reporting-Fähigkeiten des SQL Server 2008 getroffen.
• Sharepoint: Unterstützt werden WSS 3.0 und MOSS 3.0, wobei unter MOSS mehr Funktionen und eine “hübschere” Oberfläche zur Verfügungen stehen sollen. Es ist nun auch möglich, den TFS ganz ohne Sharepoint oder mit einem alternativen Portal zu betreiben.
• Project Server: Die Integration mit Project Server 2007 ist nun “ab Werk” vorgesehen. Vorraussetzung ist er natürlich nicht.
• Build Servers: Build Servers (TFS Build) müssen zusammen mit dem TFS aktualisiert werden. Wesentliche Neuerung ist die automatische Erkennung der jeweiligen Ziel-Framework-Version.
• Client: Es werden Windows XP und neuer sowie Windows Server 2003 und neuer als Client-Platform unterstützt. Der TFS soll mit allen Version von Visual Studio funktionieren, die auch den TFS 2008 unterstützen. Die Installation eines Updates für die jeweiligen Team Explorer ist jedoch notwendig. Anders herum soll der Team Explorer 2010 problemlos mit dem TFS 2005 und dem TFS 2008 funktionieren.
• Office: Es wird nur noch Office 2007 oder neuer unterstützt.

Administratoren sollten anhand der Informationen bereits weit im Voraus planen, wir sich die lokale TFS-Umgebung entwicklen soll. Wenn noch SQL Server 2005 oder Sharepoint 2.0 eingesetzt wird, wäre eine Migration auf TFS 2008 SP1 mit SQL Server 2008 und WSS/MOSS 3.0 für die zwischenzeit denkbar.

Schnell ist es passiert und man hat sich im Übereifer beim Anlegen des TFS-Projekts vertippt. Die Lösung klingt einfach: Da Umbenennen nicht geht, muss das Projekt gelöscht und mit dem richtigen Namen neu angelegt werden. Also im Team-Explorer auf “Remove” und weg ist das alte Projekt. Das neue ist ebenso schnell angelegt.

Leider trügt hier der Schein. In Wirklichkeit wurde das alte Projekt nur aus der Ansicht im Team Explorer gelöscht. Im TFS und den dazugehörigen Systemen existiert es weiterhin. Richtig löschen kann man das Projekt nur mit Hilfe eines Kommandozeilentools. Dieses wird zum Glück mit dem Team Explorer mitgeliefert und ist unter folgendem Pfad zu finden:

C:\Programme\Microsoft Visual Studio 9.0\Common7\IDE\TFSDeleteProject.exe

Der Aufruf erfolgt mit (%ProjektName% ist durch den Namen des Projekts zu ersetzen):

TFSDeleteProject.exe /server:tfs-server %ProjektName%

Die folgende Sicherheitsabfrage ist zu bejaen, falls man sich sicher ist .
Als Ergebnis erscheint folgende Ausschrift:

Deleting from Build ...
Done
Deleting from Work Item Tracking ...
Done
Deleting from Version Control ...
Done
Deleting Report Server files ...
Done
Deleting SharePoint site ...
Done
Deleting from Team Foundation Core ...
Done

Sind im Projektnamen Leerzeichen vorhanden, sollte dieser in Anführungszeichen stehen. Folgende Kommandozeilenoptionen sind möglich:

• /q

  Keine Sicherheitsnachfrage

• /force

  Setzt auch bei Fehlern das Löschen weiterer Bestandteile fort.

In verschiedenen Anwendungsfällen kann es vorkommen, dass eine Liste mit den dazugehörigen Einträgen dem Nutzer der Site verborgen bleiben soll. Trotzdem muss der Nutzer einen Workflow mit Instantiation-Form starten können und ein entsprechendes Listenelement anlegen können. Für diesen Beitrag wird von einem vorhandenen Infopath-Formular ausgegangen, welches als Instantiation-Form verwendet wird.

Hier die Schritt-für-Schritt-Anleitung:

1. ASPX-Seite oder Webpart zum Anlegen des List-Items
Zum Anlegen des List-Items, für den der Workflow gestartet werden soll, kann ein einfaches ASPX-Formular oder ein Webpart zum Einsatz kommen. Dem Formular muss als Parameter die Listen-ID mitgegeben werden.

2. Anlegen der Eingabefelder für das Listenelement
Das ASPX-Formular sollte nun alle Datenfelder abfragen und ein neues Listenelement mit entsprechenden Werten anlegen. Dies muss unbedingt mit erhöhten Privilegien geschehen:

SPSecurity.RunWithElevatedPrivileges(delegate()

{

    using (SPSite site = new SPSite(web.Site.ID))

    {

    // implementation details omitted

    }

});

Zu beachten ist, dass keine Kontext-Objekte (SPContext) verwendet werden dürfen, da diese mit den Rechten des aktuellen Nutzers laufen.

3. Weiterleitung zum Instatiation-Form
Nachdem das Item angelegt wurde (Update nicht vergessen), kann der Workflow gestartet werden. Voraussetzung ist, dass dieser bereits mit der Liste verknüpft ist und neue Instanzen gestartet werden dürfen. Der Aufruf des Instantiation-Form erfolgt mittels Response.Redirect. Folgende Url muss übergeben werden:

"_layouts/IniWrkflIP.aspx?List=<listID>&ID=<itemID>&TemplateID=<WFAID>&Source=<webUrl>"

Folgende Parameter müssen ersetzt werden:
<listID> – ID der Liste (siehe 1.)
<itemID> – ID des soeben erzeugten Items (siehe 2.)
<WFAID> – ID der WorkflowAssoziation (diese hängt an der Liste)
<webUrl> – Url an die weitergeleitet wird, nachdem der Workflow gestartet wurde

Den Rest erledigen Infopath und die aufgerufene ASPX-Datei.

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…

Bei der Arbeit mit dem Microsoft Office Sharepoint Server 2007 oder den Windows Sharepoint Services 2007 treten gelegentlich Fehler auf, die leider nur mit nichtssagenden Fehlermeldungen quittiert werden. Bekannte Beispiele sind u.a. „File not found.“ oder „Unexpected Exception.“. Dieser Artikel gibt einen Überblick, an welchen Stellen die wirklichen Fehler gefunden werden können und unterstützt den Entwickler oder Administrator somit bei der Fehlersuche.

1. Fehlermeldung vorhanden?

Als Erstes ist zunächst die Fehlermeldung, die Sharepoint im Browser anzeigt zu untersuchen. Gelegentlich werden Fehlercodes (z.B. „HRESULT“) angegeben, die einen ersten Hinweis auf den realen Fehler geben können. Auch eine Internet-Recherche mit der fehlgeschlagenen Aktion und der Standard-Fehlermeldung kann hilfreich sein, wenn das Problem häufiger auftritt.

2. Sharepoint Log durchsuchen

Der zweite Schritt ist ein Blick in die Logs, welche von Sharepoint erstellt werden. Diese befinden sich in der Regel im Ordner %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\12\LOGS. Dieser Ordner enthält eine Reihe von Log-Dateien. Am besten ist es, den Ordner nach dem Datum der letzten Änderung zu sortieren und die aktuellste Datei mit einem Editor zu öffnen. Innerhalb des Logs sollte von unten nach oben nach Begriffen wie „Exception“ oder „ERR“ gesucht werden. Ist der genaue Zeitpunkt bekannt, kann auch anhand dessen gesucht werden.

3. Windows Event Log

Weitere Informationen zum Fehler können sich auch im Event Log des Systems befinden. Dieser kann durch den Befehl „Eventvwr“ in der Kommandozeile aufgerufen werden. Unter „Application“ finden sich Anwendungsfehler, -warnungen und -informationen, die ggf. Aufschluss über den aufgetretenen Fehler und seine Ursachen geben können.

4. SQL Server Log

Im Log des eingesetzten SQL Server können Fehler gefunden werden, die von der Datenbank kommen. Dies sind insbesondere Probleme mit dem Datenbankserver oder fehlende Berechtigungen auf der Datenbank.

5. Best Practices Analyzer for WSS 2007 and MOSS 2007

Der BPA ist ein Tool zur Analyse der Sharepoint Installation und Konfiguration. Er untersucht die aktuelle Installation und gleich diese mit einigen Vorgaben („Best Practices“) ab. Weicht die aktuelle Version von diesen ab, werden entsprechende Hinweise zur Behebung der Probleme gegeben. Der BPA kann direkt bei Microsoft heruntergeladen werden:

http://www.microsoft.com/downloads/details.aspx?familyid=cb944b27-9d6b-4a1f-b3e1-778efda07df8&displaylang=en

Nach dem Download kann der BPA mit dem Befehl sharepointbpa –cmd analyze gestartet werden. Nach Abschluss der Analyse stehen eine HTML-Auswertung und ein Log zur Verfügung.

6. Sharepoint Spy

Mit Hilfe des Sharepoint Spys ist es möglich, die Konfiguration des Sharepoint Servers genauer zu untersuchen. Es werden sämtliche Einstellungen der einzelnen Komponenten angezeigt. Zudem besteht die Möglichkeit, die Konfiguration zweier Element direkt zu vergleichen. Der Sharepoint Spy kann nach Registrierung kostenlos heruntergeladen werden:

http://www.echotechnology.com/products/spy/Pages/default.aspx

Abbildung 1: Sharepoint Spy (Quelle: http://echotechnologie.com/products/spy)

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.

In einem Blogeintrag vom 20. Juli 2007 habe ich bereits über diese Fehlermeldung berichtet und einen Lösungsweg aufgezeigt. In einem aktuellen Projekt trat der Fehler jedoch erneut auf, diesmal mit einer anderen Ursache.

Entwickelt wurde ein automatisch ablaufendener Workflow für den MOSS 2007, der manuell sofort oder mit festgelegter Startzeit gestartet werden werden konnte. Um den verzögerten Start zu realisieren wurde eine DelayActivity eingesetzt.

Eine erste prototypische Implementierung zeigte einen interessanten Effekt: Der Workflow funktionierte ohne Probleme, wenn er sofort gestartet wurde. Kam jedoch die DelayActivity für einen verzögerten Start zum Einsatz, wurde der Workflow-Status sofort auf “Beendet” gesetzt. Die Aktionen, die laut Workflow ausgeführt werden sollten, blieben unbeachtet. Eine Fehlermeldung fand sich nur nach intensiver Suche im Sharepoint-Log:

DehydrateInstance: System.Runtime.Serialization.SerializationException: End of Stream encountered before parsing was completed.

Trotzdem in diesem Workflow keine InfoPath-Dokumente verwendet wurden, gab die Exception den entscheidenen Hinweis: Es gibt ein Problem mit der Serialisierung. Anders als im vorangegangen Blogeintrag lag das Problem nicht bei der Serialisierung der Daten, die von einem Formular übergeben werden, sondern bei der Serialisierung des Workflows selbst. Eine Bereinigung bzw. Konvertierung der Attribute der Workflowklasse brachte letztlich den Erfolg. Hierzu sei anzumerken, dass besonders die Sharepoint-Klassen SP* in den meisten Fällen nicht serialisierbar sind.

Abschließend bleibt noch die Frage, warum der Fehler nur beim verzögerten Start des Workflows auftritt. Dies lässt sich mit der Grundfunktionalität der Windows Workflow Foundation erklären. Die in Sharepoint integrierte Workflow Runtime verwaltet alle Workflowinstanzen. Wird eine solche Instanz mittels einer DelayActivity angehalten, wird diese aus Speicher- und Performancegründen persistent ausgelagert. Für diese Auslagerung muss die Instanz natürlich serialisiert werden. Ohne die DelayActivity wird die Instanz im Speicher gehalten, bis der Workflow beendet wurde. Der Fehler tritt also nicht auf.