Das Build System des TFS bietet die Möglichkeit einfach neue Parameter für den Build-Workflow zu definieren.

In diesem Beispiel habe ich ein neues String-Argument mit dem Namen “ServerPath” hinzugefügt. Dieses Argument können nun in der Build Definition eingestellt werden.

Etwas unschön ist noch, dass wir den Pfad als Text eingeben müssen, schöner wäre hier, wenn wir den Pfad aus der Versionsverwaltung auswählen können. Man kann für die Attribute einen Editor angeben und glücklicherweise gibt es für die Auswahl einer Datei oder eines Pfades aus der Versionsverwaltung bereits einen entsprechenden Editor. Den wollen wir nun einbinden. Dazu müssen wir die Metadaten konfigurieren.

Der Parameter Name muss hier genau dem Argument-Name entsprechen. Und nun kommt der entscheidende Punkt, wir geben im Feld Editor “Microsoft.TeamFoundation.Build.Controls.ServerFileBrowserEditor, Microsoft.TeamFoundation.Build.Controls” ein. Damit wird nun neben dem Eingabefeld in der Build-Definition ein Button angezeigt mit dem sich der entsprechende Editor öffnen lässt.

Der TFS bietet die schöne Funktion, Benachrichtigungen per Mail zu versenden. Dafür gibt es eine einfache Einstellung in der Team Foundation Server Administration Console unter dem Punkt „Email Alert Settings“.

Leider kommt es hier manchmal zu dem Problem, dass die Kommunikation zwischen dem TFS und dem SMTP-Server nicht auf Anhieb klappt und der TFS bietet da leider keine vernünftigen Analyse-Möglichkeiten. Um die Kommunikation zu testen kann man sich behelfen indem man einen Telnet-Client benutzt. Dieser ist auf dem Windows 2008 Server nicht mehr standardmäßig vorhanden, also muss man den erst mal installieren. Dazu einfach im Server-Manager unter Features den Telnet-Client hinzufügen.

Dann gibt man in der Kommandozeile folgenden Befehl ein:

telnet mymailserver 25

Damit öffnet sich nun eine Telnet session und der SMTM Server gibt eine entsprechende Meldung aus. Darunter kann man nun Kommandos eingeben. Folgende Abfolge muss man dabei nacheinander eingeben und zwar ohne sich zu vertippen, da eine Korrektur nicht funktioniert. Blau dargestellt sind die jeweiligen Antworten des Systems.

helo

250 VS2010.Mobile.Demo Hello [192.168.77.66]

mail from:tfs@artiso.com

250 2.1.0 tfs@artiso.com....Sender OK

rcpt to:tschissler@artiso.com

250 2.1.5 tschissler@artiso.com

data

354 Start mail input; end with <CRLF>.<CRLF>

Subject: TestMail

Das ist eine Test-Mail

Abgeschlossen wird die Eingabe durch Drücken von Enter, einem Punkt (.) und dann nochmals Enter.

Wenn so eine E-Mail zugestellt wird und man die hier verwendeten Serveradresse und Absender nun auch im TFS einträgt, sollte die Kommunikation auch dort funktionieren. Andernfalls sollte der Telnet eine Fehlermeldung ausgeben. Hilfreich ist, wenn man auf dem TFS mit demselben Account angemeldet ist mit dem auch der TFS läuft da einige SMTP-Server auch den angemeldeten User prüfen.

Eine häufige Frage ist, wie ich mit dem TFS und Microsoft Test Manager (MTM) die Versionierung von Test Cases bewerkstellige. Ziel dabei ist, dass ich verschiedene Releases meiner Software mit den dazu passenden Test Cases testen möchte, also z.B. für die aktuelle Entwicklung nutze ich einen neueren Test Cases da sich die Funktion inzwischen verändert hat aber wenn ich einen Hotfix für eine frühere Version testen möchte, benötige ich dafür natürlich den passenden Test Cases zu diesem Release.

Die aktuelle Lösung sieht im MTM so aus, dass man einen Test-Plan je Version einrichtet. In diesem Test-Plan habe ich dann die Test-Cases für die aktuelle Version referenziert. Für die nächste Version legt man einen neuen Test-Plan an und kopiert die Test-Suites.

Durch dieses Kopieren wird ein neuer Test-Plan angelegt der dann allerdings auf die selben Test Cases verweist wie die der Plan für die erste Version. Das ist ja genau die Ausgangssituation die man in den meisten Fällen haben möchte denn die meisten Test Cases sind ja in der neuen Version gleich wie in der Vorgänger-Version und diese werden ggf. durch neue Test Cases (z.B. 4a) ergänzt. Wenn sich ein Test Case nun ändert, dann darf dieser im neuen Test-Plan nicht angepasst werden, sonst würde ja damit auch der Test-Plan der Vorgängerversion geändert werden. Statt dessen muss der Test Case kopiert und die Kopie (2b) dem neuen Test Plan zugeordnet werden. Die Kopie kann nun geändert werden.

Wer eine größere Menge von Test Cases kopieren muss kann dafür übrigens auch ein Tool verwenden das Anna Russo veröffentlicht hat:

http://improvingsoftwarequality.blogspot.com/2011/11/bulk-copy-test-cases-tool-for-microsoft.html

Beim Deployment einer neuen Environment kommt folgende Fehlermeldung:

TF259115: Team Foundation Server could not find any suitable host to deploy the virtual machine: HPC Template.
Contact your administrator to fix the issues on the hosts below. (Hosts are listed in brackets)
1. Memory requirement of the virtual machine(s) exceeds the available host resources. The placement policy for this host group is set to be conservative and hence virtual machines that are in stopped state are also accounted as consuming host resources. Your administrator can change this policy by running the TfsLabConfig tool. (SarHyperV04)

Der Grund für die Meldung liegt darin, dass das Lab Management zunächst davon ausgeht, dass auf dem Hyper-V Host ausreichend Ressourcen (RAM) verfügbar sein müssen um alle Environments gleichzeitig zu starten um hier auf Nummer sicher zu gehen. Das ist allerdings für die Praxis eher ungeeignet. Hier möchte man auf einem Host mehrere, teilweise sogar viele Environments anlegen von denen dann aber immer nur einzelne laufen.

Glücklicherweise kann man das Verhalten aber konfigurieren. Dazu geht man einfach auf den TFS App-Tier und gibt dort folgenden Befehl ein:

tfsconfig lab /settings /CollectionName:<Collection> /hostGroup /edit /name:<Host Group Name> /labenvironmentplacementpolicy:aggressive

Dabei ist zu beachten, dass für den CollectionName auch wirklich nur der Name und nicht wie an anderen Stellen üblich die URI angegeben wird.

Weitere Infos finden sich hier: http://msdn.microsoft.com/en-us/library/dd547199(VS.100).aspx

Im Team Build lässt sich die Statische Code-Analyse (FxCop) recht einfach aktivieren. 

Leider geht es mit StyleCop nicht ganz so einfach. Eine Möglichkeit ist, in den Projektdateien die StyleCop-Analyse einzutragen und dann auf dem Build-Rechner MSBuild die StyleCop-Analyse auszuführen (siehe http://stylecop.codeplex.com/wikipage?title=Setting%20Up%20StyleCop%20MSBuild%20Integration&referringTitle=Documentation)

Alternativ kann man sich auch einfach eine Build Activity bauen die die StyleCop Analyse ausführt. Eine solche Activity habe ich am Ende dieses Posts zum Download bereitgestellt. Um diese zu nutzen entpackt man einfach die DLLs. Diese werden dann in der Versionsverwaltung abgelegt. Diesen Pfad muss man anschließend auf dem Build-Controller registrieren.

Nun können wir im Visual Studio ein Projekt anlegen. Hier referenzieren wir die DLLs aus der ZIP-Datei und kopieren unseren Build-Workflow hinein. Nun können wir im Workflow ein neues Argument vom Typ StyleCopSettings anlegen.

Dann brauchen wir noch eine Variable

Nun können wir den Workflow erweitern.

  <If Condition="[Not String.IsNullOrEmpty(StyleCopSettings.StyleCopSettingsFile) And StyleCopSettings.PerformStyleCopAnalysis]" DisplayName="If StyleCop Settings not empty run StyleCop">
    <If.Then>
      <Sequence>
        <sap:WorkflowViewStateService.ViewState>
          <scg:Dictionary x:TypeArguments="x:String, x:Object">
            <x:Boolean x:Key="IsExpanded">True</x:Boolean>
          </scg:Dictionary>
        </sap:WorkflowViewStateService.ViewState>
        <mtbwa:ConvertWorkspaceItem DisplayName="Convert Server Path to Local Path" mtbwt:BuildTrackingParticipant.Importance="Low" 
               Input="[StyleCopSettings.StyleCopSettingsFile]" Result="[StyleCopLocalSettingsFile]" Workspace="[Workspace]" />
        <absa:StyleCopVerifier AnalysisResults="{x:Null}" ViolationCount="{x:Null}" SettingsFile="[StyleCopLocalSettingsFile]" SourcesDir="[SourcesDirectory]" />
      </Sequence>
    </If.Then>
  </If>

Wenn wir nun auf Basis dieses Workflows eine Build Definition anlegen, können wir die StyleCop Settings dort einstellen und unser Build ob unsere StyleCop Rules auch alle eingehalten werden.

Ich verwende gerne Excel um mein Product Backlog im TFS zu sortieren. Dazu rufe ich die Work Items des PBL einfach aus Excel ab, sortiere diese und verwende dann die Excel Autonummerierungs-Funktion um den Stack Rank neu zu nummerieren. Das funktioniert sehr gut. Einziger Punkt der immer etwas nervt ist das Ausschneiden und Einfügen der Zeilen im Excel um diese zu verschieben. Hier gibt es allerdings eine elegante Lösung die allerdings ein wenig Fingerspitzengefühl erfordert und die nicht gerade intuitiv ist.

Zuerst markiert man die Zeile(n) die man verschieben möchte

Dann fährt man mit der Maus auf die obere Kante der Markierung

Nun kann man mit gedrückter rechter Maustaste die Zeile an eine andere Position schieben. Danach öffnet sich ein Kontext-Menü in dem man dann verschiedene Optionen zur Auswahl hat. “Move here” bedeutet das das Ziel überschrieben wird. Für den oben beschriebenen Fall brauchen wir also “Schift Down and Move” damit die verschobene Zeile eingefügt wird.

Alternativ kann man auch mit der linken Maustaste verschieben und dann im Verschieben die Shift-Taste drücken. Die Einfügezeile passt sich dann entsprechend an um anzuzeigen das die Zeile eingefügt wird und nicht der Inhalt überschrieben wird (ohne gedrückter Shift-Taste)

Wir hatten heute die Anforderung dass wir im Lab eine Software installieren mussten die über eine Lizenz freigeschaltet wird. Diese Lizenz is an die MAC-Adresse der Netzwerkkarte gebunden. Ziel war es nun, dass wir mit der selben Lizenz die Software auf mehreren Lab Environments betreiben können. Dabei ging es nicht darum die Lizenzprüfung auszuhebeln sondern mit der selben Konfiguration auf mehreren Labs zu testen. Was nicht funktioniert, ist dass man im Netz mehrere Netzwerkkarten mit der selben MAC Adresse hat. Aber für die virtuellen Maschinen gibt es da eine einfache Lösung. Man fügt einfach eine virtuelle Netzwerkkarte hinzu die nicht mit dem Netz verbunden ist.

Dazu müssen wir in der VM einen weiteren Netwerkadapter hinzufügen den wir einfach auf “Not connected” stellen und für den wir dann eine MAC-Adresse angeben können.

Heute hatte ich das Problem bei einem Kunden dass neu angelegte Areas nicht sofort auf den Work Items sichtbar waren. Was zuverlässig geholfen hat, war eine Recycle des Application Pools. Das ist aber natürlich auch keine Lösung. Im Web habe ich einige Threads zu diesem Problem gefunden, aber keine wirkliche Lösung. Deshalb möchte ich hier kurz beschreiben, welche Analysemöglichkeiten es hier gibt.

Zunächsteinmal habe ich folgende Zusammenhänge herausgefunden:

Wenn man in einem Client (Visual Studio, Excel, Project, Web Access etc.) eine Iteration anlegt, wird diese in der DB der Project Collection unter der Tabelle tbl_Nodes eingetragen. Dann wird eine Stored Procedure aufgerufen die eine Verarbeitung antriggert. Diese Verarbeitung wird vom Visual Studio Team Foundation Background Job Agent ausgeführt. Dieser schreibt dann einen neuen Eintrag in die Tabelle TreeNodes. Von dort werden die Items für die Work Items gelesen.

Damit ergeben sich folgende Schritte die ich empfehlen kann um das Problem zu untersuchen:

1. Prüfen ob der Visual Studio Team Foundation Background Job Agent Dienst läuft und ob dieser mit dem Account ausgeführt wird mit dem auch der TFS installiert wurde.
2. Prüfen ob die neuen Areas sowohl in tbl_Nodes als auch in TreeNodes eingetragen werden
3. Für den Visual Studio Team Foundation Background Job Agent kann ein Tracing aktiviert werden. In diesem sollte ein entsprechender Eintrag für die Verarbeitung der Area stehen. Man kann einfach nach dem Namen der neuen Area suchen. Das Tracing aktiviert man in der Datei "C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\TFSJobAgent\TfsJobAgent.exe.config"

   1:  ...

   2:    <system.diagnostics>

   3:      <trace autoflush="false" indentsize="4">

   4:        <!--To enable tracing to file, simply uncomment listeners section and set trace switch(es) below.

   5:            Directory specified for TextWriterTraceListener output must exist, and job agent service account must have write permissions. -->

   6:        <!--<listeners>

   7:          <add name="myListener" 

   8:            type="System.Diagnostics.TextWriterTraceListener" 

   9:            initializeData="C:\Replace_Me_With_A_Directory_The_Service_Account_Can_Write_To\jobagent.log" />

  10:          <remove name="Default" />

  11:        </listeners>-->

  12:      </trace>

  13:      <switches>

  14:        <!--  Trace Switches

  15:              Each of the trace switches should be set to a value between 0 and 4, inclusive.

  16:                0: No trace output

  17:                1-4: Increasing levels of trace output; see Systems.Diagnostics.TraceLevel-->

  18:        <add name="API" value="0" />

  19:        <add name="Authentication" value="0" />

  20:        <add name="Authorization" value="0" />

  21:        <add name="Database" value="0" />

  22:        <add name="General" value="0" />

  23:        <add name="traceLevel" value="0" />

  24:      </switches> 

  25:     </system.diagnostics>

  26:  ...

Die Zeilen 6-11 müssen einkommentiert und für das Log-File ein gültiger Pfad angegeben werden. Dann kann man die Trace-Levels auf einen Wert zwischen 1 und 4 für die einzelnen bereiche setzen. Ich hatte einfach mall alles auf 4 gesetzt. Natürlich nicht vergessen das nach der Fehleranalyse wieder zurückzusetzen.

Damit sollte sich der Fehler identifizieren und beheben lassen. Viel Erfolg!

Erstellen einer simplen Custom Checkin Policy

In diesem Beispiel wollen wir eine Custom Checkin Policy erstellen die prüft, ob beim Checkin ein Kommentar min einer bestimmten Mindestlänge angegeben wurde. Es gibt ja bereits mit den Powertools eine Policy die prüft, ob überhaupt ein Kommentar angegeben wurde, aber wir wollen auch zu einem gewissen Maße prüfen, ob der Kommentar auch sinnvoll ist indem wir eine Mindestlänge erwarten. Zur Erstellung dieser Policy gehen wir als folgendermaßen vor:

1.)      Wir erstellen ein neues ClassLibrary Projekt in Visual Studio

2.)      Wir fügen eine Referenz zur Microsoft.Teafoundation.VersionControl.Client.dll hinzu. Diese findet man unter ReferenceAssemblies im VS DIE Ordner, also z.B. C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.VersionControl.Client.dll

3.)      Wir leiten unsere Klasse von PolicyBase ab und lassen Stubs generieren. Der Zwischenstand sieht dann so aus:

4.)      Wir setzen nun die Properties mit entsprechenden Werten, z.B.

public override string Description

        {

            get

            {

                return "Will check if the checkin comment is at least 10 letters long.";   

            }

        }

        public override bool Edit(IPolicyEditArgs policyEditArgs)

        {

            return true;

        }

        public override PolicyFailure[] Evaluate()

        {

            throw new NotImplementedException();

        }

        public override string Type

        {

            get

            {

                return "Changeset Comments Length Policy";

            }

        }

        public override string TypeDescription

        {

            get

            {

                return "This policy will require users to provide checkin comments of a minimum length.";

            }

        }

Wichtig sind hier vor allem Type und Type Description da diese bei der Auswahl der Policy angezeigt werden.

5.)      Nun wollen wir die Evaluate-Methode implementieren. Diese wird vor dem Checkin ausgeführt und liefert mögliche Verletzungen der Policy zurück. Nur wenn keine Verletzungen gemeldet werden, wird der Checkin ausgeführt. Da wir hier den Checkin Comment prüfen wollen, brauchen wir Zugriff auf das Changeset. Dazu brauchen wir zuerst ein Feld das den Checkin enthält:

private IPendingCheckin currentPendingCheckin;

6.)      Nun überschreiben wir die Initialize-Methode und setzen hier unser currentPendingCheckin:

public override void Initialize(IPendingCheckin pendingCheckin)

{

    base.Initialize(pendingCheckin);

    currentPendingCheckin = pendingCheckin;

}

7.)      Anschließend implementieren wir unsere Validierungslogik in der Evaluate-Methode:

public override PolicyFailure[] Evaluate()

{

    var failures = new List<PolicyFailure>();

    if (currentPendingCheckin.PendingChanges.Comment.Length < 10)

    {

        failures.Add(new PolicyFailure("Checkin Comment is too short, at least 10 letters are required", this));

    }

    return failures.ToArray();

}

8.)      Dann folgt noch ein wichtiger Schritt, wir müssen die Klasse serialisierbar machen

[Serializable]

public class CheckinCommentLengthPolicy : PolicyBase

9.)      Nun kompilieren wir die Solution und kopieren die DLL in einen lokalen Ordner. Anschließend tragen wir in der Registry unter „HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Checkin Policies“ einen neuen String Value ein dem wir den Pfad zu unserer Assembly übergeben. Der angegebene Pfad in der Registry ist dabei für x64 Systeme angegeben. Bei c86 Systemen lautet der passende Pfad „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Checkin Policies“.

10.)   Nun starten wir Visual Studio neu und aktivieren die neue Checkin Policy. Dazu klicken wir im Team-Explorer mit der rechten Maustaste auf das Team-Projekt dann unter Team Project Settings / Source Control und dort wechseln wir dann auf den Reiter „Check-in Policy“. Über den Button Add können wir unsere Policy auswählen und hinzufügen.

11.)   Nun können wir einen Eincheckvorgang vornehmen und wir werden sehen, wenn wir einen leere checkin Comment angeben oder einen zu kurzen, erhalten wir eine Meldung.

Konfigurierbarkeit der Policy hinzufügen

Nun wollen wir die Anzahl der Mindestzeichen noch konfigurierbar machen. Dazu erweitern wir unsere Policy.

1.)   Zunächst fügen wir einen Winforms-Dialog hinzu der für die Eingabe des Wertes dient.

2.)   Im Code definieren wir ein public field über das wir die Anzahl übergeben bzw. auslesen können.

public partial class CheckinCommentLengthConfigDialog : Form

{

    public int MinimumCommentLength;

    public CheckinCommentLengthConfigDialog()

    {

        InitializeComponent();

    }

    private void btnOK_Click(object sender, EventArgs e)

    {

        MinimumCommentLength = (int)this.numericUpDown1.Value;

    }

    private void CheckinCommentLengthConfigDialog_Load(object sender, EventArgs e)

    {

        this.numericUpDown1.Value = MinimumCommentLength;

    }

}

3.)   Im Code unserer Policy fügen wir ein private field hinzu in dem wir den Wert speichern können und verwenden diesen in unserer Evaluate Methode. Zusätzlich geben wir im Property CanEdit den Wert true zurück. Und wir implementieren die Edit-Methode so, dass hier unser Formular aufgerufen wird:

public override bool Edit(IPolicyEditArgs policyEditArgs)

{

    using (CheckinCommentLengthConfigDialog dialog = new CheckinCommentLengthConfigDialog())

    {

        dialog.MinimumCommentLength = minimumCommentLength;

        if (dialog.ShowDialog() == DialogResult.OK)

        {

            minimumCommentLength = dialog.MinimumCommentLength;

            return true;

        }

        return false;

    }

}

public override bool CanEdit

{

    get

    {

        return true;

    }

}

4.)   Nach dem Kompilieren können wir dann die DLL an den Ort kopieren den wir in der Registry eingetragen haben (bei mir c:\temp). Damit diese Date überschrieben werden kann, müssen wir Visual Studio beenden. Nun können wir für unsere Policy den Edit-Dialog aufrufen:

Verbessertes Deployment der Policy

Nun wollen wir das Deployment unserer Policy nov vereinfachen. Aktuell wäre es so, dass auf jedem Rechner auf dem die Policy geprüft werden soll die DLL kopiert und der entsprechende Registry-Eintrag vorgenommen werden muss. Das ist natürlich nicht besonders elegant. Wir müssen die Policy zwar auf jedem Rechner installieren, da sonst die Policy immer als verletzt gilt, aber die Installation können wir durch den Einsatz von VSIX deutlich einfacher machen.

1.)   Zunächst müssen wir das Visual Studio SDK herunterladen und installieren. Der Download für die SP1-Version befindet sich unter http://www.microsoft.com/downloads/en/details.aspx?FamilyID=21307C23-F0FF-4EF2-A0A4-DCA54DDB1E21

2.)   Dann fügen wir ein neues Projekt zu unserer Solution hinzu und wählen die Vorlage VSIX Project

3.)   Im Manifest des VSIX Projektes tragen wir nun die entsprechenden Werte ein und fügen unser Policy-Projekt als MEF Component im Bereich Content hinzu.

4.)   Damit unser Eintrag in der Registry noch hinzugefügt wird, fügen wir noch eine Text-Datei mit dem Namen „Policies.pkgdef“ hinzu und schreiben dort folgenden Inhalt rein:

[$RootKey$\TeamFoundation\SourceControl\Checkin Policies]

"artisoCheckinPolicies"="$PackageFolder$\artisoCheckinPolicies.dll"

5.)   Wichtig ist noch, dass wir bei der pkgdef-Datei in den Eigenschaften „Include in VSIX“ auf True stellen.

6.)   Nun kompilieren wir unsere Solution. Wenn alles fehlerfrei erstellt wird, bereinigen wir zunächst unsere manuellen Einstellungen, d.h. wir entfernen zunächst die Policy auf unserem Team-Projekt. Anschließen löschen wir die DLL und die Registry-Einträge die wir im ersten Teil angelegt haben. Dazu müssen wir zuvor Visual Studio wieder beenden. Nach dem Entfernen sollte die Policy in der Liste der verfügbaren Checkin Policies nicht mehr erscheinen. Aus dem Output unseres Setup-Projektes können wir nun die vsix-Datei starten und die Policy installieren.

7.)   Danach sollte sich die Policy genauso aktivieren lassen wie zuvor.

Zwei Felder auf den Workitems im Team Foundation Server sind Area und Iteration. Das besondere an diesen Feldern ist, dass sie hierarchische Inhalte abbilden. Als Standard-Wert haben diese Felder den jeweiligen Root-Knoten der gleich heißt wie das zugehörige Teamprojekt.

Um zu verhindern, dass Workitems nicht einer spezifischen Area oder Iteration zugeordnet sind und damit von entsprechenden Queries nicht mehr erfasst werden, wäre es ideal, wenn man erzwingen könnte, dass eine spezifische Area oder Iteration ausgewählt sein muss.

Leider schlagen die naheliegenden Lösungsansätze fehl. Wenn man auf dem IterationPath oder der IterationID eine REQUIRED-Rule definiert, dann greift diese nicht, da die Iteration ja nicht leer ist. Wenn man versucht mit deiner PROHIBITETED-Rule den Rootknoten zum ungültigen Wert zu erklären, dann funktioniert das leider auch nicht. Dieser Versuch wird quitiert mit der Meldung

---------------------------
Error
---------------------------
Error importing work item type definition:

TF26062: Rule '<REQUIRED />' is not supported for the field 'System.IterationPath'.
---------------------------
OK  
---------------------------

Deshalb müssen wir hier ein wenig in die Trickkiste greifen. Dazu legen wir zunächst ein neues String-Feld an

      <FIELD refname="artiso.Iteration" name="Iteration" type="String">
        <WHEN field="System.IterationPath" value="Training">
          <COPY from="value" value="Empty" />
        </WHEN>
        <WHENNOT field="System.IterationPath" value="Training">
          <COPY from="value" value="Valid" />
        </WHENNOT>
        <PROHIBITEDVALUES>
          <LISTITEM value="Empty" />
        </PROHIBITEDVALUES>
      </FIELD>

Wenn das Feld IterationPath den Inhalt “Training” (Root-Knoten) hat, dann wird in dieses Feld “Empty” geschrieben, ansonsten “Valid”. Zusätzlich wird “Empty” als unzulässiger Wert definiert. Dieses Feld fügen wir nicht in’s Layout ein, sondern lassen es unsichtbar. Dadurch haben wir eine Validierung ob im Iterations-Feld ein andeer Wert als der Root-Wert eingetragen ist. Einzige unschönheit dabei ist, dass die Meldung nicht eindeutig zu dem Feld zugeordnet ist. Aber der gleiche Ansatz funktioniert für auch für Areas.

Das Lab Management des Team Foundation Servers eignet sich besonders gut um darin Coded UI Tests automatisiert im Rahmen eines Builds auszuführen. Der Build setzt die VM dabei auf einen Snapshot zurück, deployed die Applikation dann in die VM und führt dann die CUIT aus. Wie das Ganze funktioniert habe ich in einem Webcast beschrieben (http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=1032476976).

Dabei kann allerdings nun ein Problem auftreten. Der Test meldet bei der Ausführung:

“Automation engine is unable to playback the test because it is not able to interact with the desktop.  This could happen if the computer running the test is locked or it’s remote session window is minimized.”

Das Problem besteht darin, dass der CUIT eine interaktive Desktop Session benötigt um darin ausgeführt werden zu können. Als ich mich mit dem Environment Viewer auf die Environment verbunden habe, konnte ich feststellen, dass die VM beim Anmeldebildschirm stand. Das hatte ich nicht erwartet das die VM mit einem Autologon versehen war und ich den Snapshot auch im angemeldeten Zustand erstellt habe. ich hätte also erwartet, dass die VM nach einem Restore des Snapshots auch wieder angemeldet ist und der Test problemlos laufen kann.

Um die Ursache des Problems zu erläutern müssen wir etwas tiefer einsteigen. Der Environmen Viewer hat 2 Betriebs-Modi. Einmal Host-based und einmal Guest-based. Der aktuelle Modus wird rechts unten im Environment Viewr angezeigt

Host-based ist dabei die Verbindungsart bei der der Environment Viewer über den Hyper-V Host auf die VM zugreift. Dieser Modus erlaubt es auch mit der VM zu interagieren wenn diese noch gar nicht komplett hochgefahren ist, z.B. um aus dem Boot-Menü einen Eintrag zu wählen.

Guest-based ist eine normale RDP (Remote Desktop Protocol) Verbindung. Dafür muss die VM bereits hochgefahren sein. Guest-based Verbindungen sind etwas performanter und erlauben auch zusätzliche Features wie z.B. den Austausch von daten über die Zwischenablage.

Host-based wird dann verwendet wenn:

1.) Der client der den Environment Viewer ausführt als Betriebssystem mindestens Windows XP SP3, Windows Visua SP1, Windows 7 oder Windows Server 2008 ausführt und
2.) Der Benutzer der den Environment Viewer ausführt auch der Ownder der Environment ist

Weitere Informationen zu den verschiedenen Connection Types finden sich unter http://msdn.microsoft.com/en-us/library/ee518907.aspx.

Zurück zu dem obenen beschriebenen Problem. Der Build funktioniert nur dann, wenn der Snapshot auf den der Build zurücksetzt im Host-based Modus erstellt wurde. Andernfalls bekommt man auch in der Build Definition bei der Auswahl des Snapshots einen entsprechenden Hinweis.

Zu beachten ist allerdings, dass dieser Hinweis nur an dieser Stelle kommt, d.h. wenn man den Wizard des Lab BuildProcessTemplates anzeigt oder bei der Ausführung bekommt man keinen Hinweis mehr. Problem bei mir war, dass ich den Snapshot initial im Host-based Modus erstellt hatte und damit den Build angelegt habe. Anschließend habe ich den Snapshot aber gelöscht und neu angelegt und nun war ich im Guest-based Modus.

Problem-Lösung:

Wie lösen wir nun also dieses Problem? Es gibt zwei Möglichkeiten:

1.) Wir erstellen die Snapshots immer im Host-based Modus. Dazu müssen wir im Environment Viewer mit dem Benutzer angemeldet sein der auch der Owner der Environment ist. Wie man den Owner einer Environment ändert ist hier beschrieben: http://blogs.msdn.com/b/lab_management/archive/2010/11/08/enabling-host-based-connection-for-virtual-environments.aspx

2.) Wir verwenden einen Snapshot der im nicht gebooteten Zustand der VM erstellt wird. Der Build startet die VM dann automatisch und die VM nutzt einen Autologon um sich anzumelden. Damit kann der CUIT nun auch ausgeführt werden.

Es gibt häufiger die Situation, dass man die Url des Team Project Portals eines TeamProjects per API ermitteln möchte um beispielsweise im zugehörigen Portal Dokumente zu generieren oder abzulegen etc. Hier kann man natürlich versuchen sich die Url aus Server-URL, Project Collection Name und Project Name zusammenzubauen, also http://<servername>/sites/<ProjectCollection>/<TeamProject>. Problem ist, dass die Url frei konfiguriert werden kann und von diesem Default-Wert abweichen kann.

Mein Szenario ist, dass ich ausgehend von einem Work Item die Url des Projekt Portals ermitteln möchte um für das Work Item ein entsprechendes Dokument anzulegen. Das Projekt zum Work Item lässt sich einfach ermitteln mit myWorkItem.Project aber auf dem Projekt sucht man vergeblich nach einer Eigenschaft für das Portal. Der Zugriff darauf istt leider ein wenig komplizierter. Die einzige Möglichkeit die Prortal Url zu ermitteln geht über den TFS Catalog. Der Code sieht dann so aus:

Wir ermitteln zunächst den CatalogNode für die Project Collection unseres Work Items. Davon ausgehend ermitteln wir dann den Knoten für das Projekt mit Hilfe des Projektnamens den wir von dem Work Item lesen. Vom Projekt aus können wir nun den Project Portal Knoten ermitteln der die Url beinhaltet.

Es gibt verschiedene Situationen in denen man nachträglich Reports oder SharePoint Dokumente nachträglich für ein bestehendes Team Project einrichten möchte, z.B. nach einer Migration von einer älteren TFS Version oder wenn das Projekt ohne Reports oder SharePoint Portal angelegt wurde. Dafür gibt es bei den Team Foundation Server Power Tools die Befehle

• tfpt addprojectportal   Add or move portal for an existing team project
• tfpt addprojectreports  Add or overwrite reports for an existing team project

Mit dieser Methode hatte ich aber bereits mehrfach Probleme und die Einstellungen sind auch nicht so feingranular möglich. Deshalb möchte ich hier eine andere Methode beschreiben. Hierzu legt man zunächst eine XML-Datei an. Für die SharePoint-Dokumente sieht die XML-Datei folgendermaßen aus:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="ProjectCreationSettingsFileSchema.xsd">
  <TFSName>http://vs2010:8080/tfs/sandbox</TFSName>
  <LogFolder>c:\Temp\</LogFolder>
  <ProjectName>VS2010_Demos</ProjectName>
  <AddFeaturesToExistingProject>true</AddFeaturesToExistingProject>
  <ProjectSiteEnabled>true</ProjectSiteEnabled>
  <ProjectSiteWebApplication>VS2010</ProjectSiteWebApplication>
  <ProjectSitePath>/sites/sandbox/vs2010_demos/</ProjectSitePath>
  <ProjectSiteTitle>VS2010 Demos</ProjectSiteTitle>
  <ProjectSiteDescription>Demo</ProjectSiteDescription>
  <ProcessTemplateName>MSF for Agile Software Development v5.0</ProcessTemplateName>
</Project>

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="ProjectCreationSettingsFileSchema.xsd">
  <TFSName>http://vs2010:8080/tfs/sandbox</TFSName>
  <LogFolder>c:\temp</LogFolder>
  <ProjectName>VS2010_Demos</ProjectName>
  <AddFeaturesToExistingProject>true</AddFeaturesToExistingProject>
  <ProjectReportsEnabled>true</ProjectReportsEnabled>
  <ProjectReportsForceUpload>true</ProjectReportsForceUpload>
  <ProjectSiteEnabled>false</ProjectSiteEnabled>
  <ProcessTemplateName>MSF for Agile Software Development v5.0</ProcessTemplateName>
</Project>

Die Parameter sollten weitgehend selbsterklärend sein, eine weitere Beschreibung finden sich hier. Diese XML-Dateien können nun ausgeführt werden indem im Command-Window innerhalb von Visual Studio der Befehl

File.BatchNewTeamProject <XML-Datei>

Der Import wird damit angestoßen. Zu beachten ist, dass der Vorgang eine Weile dauern kann. Den Erfolg des Imports kann man in der Log-Datei im angegebenen Ordner überprüfen.

Inzwischen hat es sich sicher herumgesprochen, dass das SP1 für Visual Studio und den TFS verfügbar ist. Allerdings bekomme ich einige Fragen zu Installation, was muss wo installiert werden. Deshalb möchte ich hier auf einen Blog Post von Brian Harry verweisen der die Details beschreibt.

Und dann möchte ich noch auf einen Punkt aufmerksam machen der vielleicht etwas untergegangen ist. Ab sofort steht den Besitzer einer Visual Studio 2010 Ultimate mit MSDN Subscription der Load Test Virtual User Pack für eine unbegrenzte Anzahl virtueller User zur Verfügung. Damit sind nun Load Tests ohne zusätzliche Lizenzkosten möglich. Und Load Tests sind nicht nur für Stress Tests sinnvoll sondern können auch Concurrency-Probleme aufdecken und eignen sich auch sehr gut um Performance-Tests auch für kleinere Anwendungen. Weitere Infos zur Lizenzänderung gibt es hier: http://www.microsoft.com/visualstudio/en-us/products/2010-editions/load-test-virtual-user-pack

Bei verschiedenen Diagrammtypen, z.B. stacked Areas möchte man das Diagramm am Ende gerade abschneiden und nicht zunächst noch einen 0-Wert anzeigen.

Also statt der Schräge am Ende des Diagramms (zum 23.02 liegen keine Werte vor)

hätte man das lieber sauber abgeschnitten um zu signalisieren, dass die letzten gültigen Werte vom 22.02 sind.

Dies kann man mit Reporting Services Diagrammen relativ einfach erreichen. Zunächst ist wichtig, dass für die Werte ab 23.02 nicht 0 sondern Null bzw. Nothing (für Expressions) als Ergebnis zurückgegeben wird. Dies kann man im Query Designer kontrollieren

Dann muss man in den Properties der Serie noch in den EmptyPoint Einstellungen die Farbe auf “No Color” stellen, d.h. dass leere Datenpunkte nicht gezeichnet werden.

Und schon hat man das gewünschte Ergebnis.

Allen Clark hat auf der MSDN Code Gallery Schema Files für die TFS Work Item Type Definition veröffentlicht. Damit bekommt man nun IntelliSense Support und Validierung beim Bearbeiten der XML-Dateien. War kann man über den Process Template Editor der TFS Power Tools ohne direkte XML-Bearbeitung die Work Item Type Definitions über einen grafischen Editor anpassen, jedoch gibt es eine ganze Reihe von Situationen wo das Bearbeiten im XML schneller geht oder einfach nicht zu vermeiden ist. Mit den Schema-Files wird dies nun deutlich angenehmer.

Link zur Code Gallery: http://code.msdn.microsoft.com/TFSchemas

Das MSF for Agile Template kommt mit einer vorgefertigten Excel-Datei für ein Interations- bzw. Sprint-Backlog. Diese liegt im SharePoint unter Shared Documents\Iteration 1\Iteration Backlog.xlsm.

Beim Öffnen der Datei kam es bei mir alledings zu Fehlern:

---------------------------
Microsoft Excel
---------------------------
TF80076: The data in the work item is not valid or you do not have permissions to modify the data. Please correct the problem and retry.
---------------------------
OK  
---------------------------

und

---------------------------
Microsoft Excel
---------------------------
TF208103: The initialization of the workbook to connect to Team Foundation Server was not successful. The workbook will close. You can try to connect again by re-opening the workbook.

If repeated attempts fail to initialize the workbook and you need to work with the data in the workbook, then you should disable the Team Foundation add-in. For new or other workbooks with lists bound to Team Foundation Server, you will need to re-enable the Team Foundation add-in.
---------------------------
OK  
---------------------------

Das Problem liegt darin, dass ich bei mir die Iterationen umbennant habe und das Dokument damit nun nicht mehr zurecht kommt. Es gibt aber einen relativ einfachen Workaround dafür:

1. Zunächst muss man dafür sorgen, dass es wieder einer Iteration “\Iteration 1” gibt. Diese kann man entweder temporär anlegen oder eine bestehende umbenennen.
2. Jetzt lässt sich die Datei ohne Fehler öffnen
3. Dann wechselt man auf das Sheet “Settings”
4. Hier wählt man im Bereich Area & Iteration eine gültige Iteration aus, z.B. \ oder eine der anderen gültigen Iterationen.
   Achtung: In der Liste werden nur Iterationen erlaubt die in dem Sheet “Iteration Backlog” in der Spalte “Iteration Path” vorkommen. Evtl. muss zuvor die Query “Team Queries\Iteration 1\Iteration Backlog” angepasst und hier die entsprechende Iteration als Filter eingestellt werden. Dann kann mit dem Refresh-Button auf dem team Tab im Excel die Liste aktualisiert werden.
   
5. Danach speichert man die Excel-Datei
6. Nun kann die temporär angelegte Iteration gelöscht werden oder die Iteration wieder umbenannt werden. Das Excel-Dokument lässt sich nun ohne Fehler öffnen.

Mit dem Team Foundation Build ist es einfach, Tests im Rahmen von automatisierten Builds auszuführen. Standardmäßig werden die Tests jedoch auf dem Buildrechner selbst ausgeführt. Das ist in verschiedenen Szenarien jedoch nicht erwünscht, sondern man möchte die Tests in einer Referenzumgebung ausführen die der Zielumgebung, in der die Anwendung ausgeführt werden soll, möglichst nahe kommt. Vor allem für GUI-Tests ist dieses Szenario wichtig.

Mit Visual Studio 2010 gibt es dafür LabManagement um virtualisierte Testumgebungen bereitzustellen und über ein vorbereitetes Build Template Tests darin auszuführen. Jedoch lässt sich diese Funktion auch ohne LabManagement erreichen, z.B. wenn ein anderes Virtualisierungssystem als Hyper-V oder rein physikalische Testumgebungen eingesetzt werden sollen. Im Folgenden soll beschrieben werden, wie dieses Szenario einzurichten ist.

Hierzu muss zunächst ein Testcontroller eingerichtet werden. Dieser kann beispielsweise auf dem TFS Server installiert werden. Auf der Testmaschine muss anschließend ein Testagent installiert und auf den Testcontroller registriert werden. Weitere Hinweise zur Installation und Konfiguration von Testcontrollern und –agents finden sie unter http://msdn.microsoft.com/de-de/library/dd648127.aspx. Es sollte beachtet werden, dass der Test Agent als interaktiver Prozess konfiguriert sein muss, wenn UI-Tests auf der Testmaschine ausgeführt werden sollen. Und der Testagent muss auf dem Testcontroller registriert  sein.

Der Testcontroller darf nicht für ein Teamprojekt registriert sein.

Anschließend können wir einen Build für das gewünschte Projekt einrichten. Der Build soll in unserem Szenario auf einem separaten Buildcomputer ausgeführt werden. Um das Deployment des Buildergebnisses auf die Testmaschine zu bewerkstelligen, passen wir das Buildtemplate ein wenig an. Dazu legen wir zunächst 2 neue Arguments an. Anschließend Platzieren wir unterhalb der „If BuildSettings.HasProjectToBuild“ Activity eine If-Condition auf der wir auf das Argument DeployForTest prüfen. Im Then-Zweig fügen wir dann eine CopyDirectory-Activity ein für die wir als Source die Droplocation und als Destination das Argument DeployForTestTarget einstellen. Damit wird unser Buildergebnis in dan Verzeichnis kopiert das wir in unserer Build Definition einstellen können.

Das BuildTemplate können wir nun unter einem neuen Namen speichern und einchecken. Auf dieser Basis erstellen wir nun mal einen ersten Build. In den Process Einstellungen definieren wir nun, dass das Deployment auf die Testmaschine ausgeführt werden soll und wir geben den UNC-Pfad an wohin die Dateien deployed werden sollen.

Nach dem Ausführen des Builds können wir prüfen, ob die Dateien korrekt auf die Testmaschine deployed wurden. Die Tests die wir in unserem Projekt haben werden allerdings immer noch auf unserer Buildmaschine ausgeführt. Um das zu ändern, müssen wir die Testsettings anpassen. Unter Test / Edit Test Settings  wählen wir zunächst Local aus um diese Einstellung anzupassen.

Hier müssen wir Remote Execution einstelle und den entsprechenden Build Controller auswählen. Diese Einstellungen können wir dann unter einem neuen Namen abspeichern und einchecken.

Anschließend wählen wir diese Test Settings in unserem Build aus.

Damit werden unsere Tests die wir in der Solution definiert haben nun auf unserer Testmaschine ausgeführt. Dies können sowohl Unit-Tests als auch Coded UI Tests sein. Als erweitertes Szenario können z.B. im Rahmen des Build Setups erstellt werden die dann über die CopyDirectory Activity auf die Testmaschine kopiert werden. Dann kann mit Hilfe eines Coded UI Tests das Setup ausgeführt und anschließend die Funktionen der Anwendung getestet werden.

Ein wichtiger Punkt ist noch, dass wir aktuell nicht kontrollieren können, auf welchem Testcomputer die Tests ausgeführt werden, wenn wir auf dem Testcontroller mehrere Agents registriert haben. Das wollen wir nun noch ändern. Dazu wählen wir unter Test / Manage Test Controllers unseren Testcontroller und den entsprechenden Agent aus.

Über Properties können wir dem Agent nun Attribute zuordnen, z.B. ein MachineName.

Nun können wir in unseren Testsettings einstellen auf welchem Agent unsere Tests ausgeführt werden sollen. Dazu fügen wir erst eine Rolle hinzu und wählen aus, dass auf dieser Rolle Tests ausgeführt werden können. Nun Geben wir das zuvor definierte Attribut mit dem selben Wert an.

Nun können wir eindeutig steuern, wo die Ausführung der Tests erfolgen soll und wir können beispielsweise mehrere Testcomputer mit verschiedenen Betriebssystemen zur Ausführung der Tests nutzen.

Der einfachste Weg, um Daten aus dem OLAP Cube im TFS Warehause auszuwerten ist über Excel. Wie dies funktioniert, soll im Folgenden kurz beschrieben werden:

Zunächst müssen dem entsprechenden Benutzer Berechtigungen für den OLAP-Cube eingerichtet werden. Dazu verbindet man sich im Management Studio zu den Analysis Services.

Unter dem Cube im Ordner Roles findet sich dann die Rolle TfsWarehouseDataReader

Hier kann man nun unter Memberschip die entsprechenden Benutzer eintragen

In Excel kann man nun eine Verbindung zum Cube herstellen. Dazu ruft man im Data-Tab die Verbindung zu den Analysis Services auf.

Im folgenden Dialog gibt man nun die Verbindungsdaten ein. Soll der Zugriff auf eine bennante Instanz erfolgen, muss diese angegeben werden, z.B. mySQLServer\MyInstance.

Dann wählt man entweder den Cube oder eine Perspektive aus

Die Verbindung kann man nun speichern. Sie steht dann unter Existing Connections für weitere Anwendungen zur Verfügung.

Im nächsten Schritt kann man eine Pivot Table in das bestehende Excel Workbook einfügen.

Im rechten Bereich kann man nun Felder in die Bereiche für Filter, Spalten, Zeilen oder Werte ziehen. Die Felder lassen sich dabei nach verschiedenen Kategorien über die oberste Dropdownlist filtern.

In einem späteren Post werde ich beschreiben, wie man mit Hilfe der Pivot Tables entsprechende Auswertungen auf dem Cube erstellt.

Beim starten einer Environment im Microsoft Lab Management dauert es meist geraume Zeit, bis die Workflow capabilities bereit zur Ausführung sind.

Will man diese Zeit reduzieren, ist ein einfaches Mittel in den VMs das IPv6 Protokoll auf den Netzwerkkarten zu reduzieren. Bei mir hat das die Wartezeit für die Workflow capabilities von 2:44 Min auf 0:40 Min reduziert.

Microsoft schließt eine Sicherheitslücke im ASP.Net durch ein Out-of-Band-Ipdate. Da der TFS komplett auf ASP.Net basiert, ist au der TFS von dieser Sicherheitslücke betroffen und wer auf der sicheren Seite sein möchte sollte den nun verfügbaren Patch installieren.

Weitere Details und die Download-Links gibt es auf TechNet unter http://blogs.technet.com/b/michaelkranawetter/archive/2010/09/28/update-out-of-band-updates-f-252-r-asp-net-l-252-cke-verf-252-gbar.aspx

Wenn das TFS Dashboard zu lange braucht um angezeigt zu werden, dann kann ein Grund dafür das “Recent Builds Webpart” sein. Dieses hat offensichtlich noch einen Bug und liest zu viele Informationen vom TFS. Wird die Anzahl der Builds zu hoch, dann hat das Webpart einen sehr deutlichen Einfluss auf die Performance des Dashboards, insbesondere beim erstmaligen Laden.

Microsoft hat das als Bug identifiziert und verspricht mit dem SP1 Abhilfe zu schaffen. Im Moment hilft leider nur, entweder das WebPart vom Dashboard zu entfernen oder die Build-Historie regelmäßig zu löschen.

Die neueste Version (September) der TFS Power Tools enthalten auch eine neue Backupfunktion mit der nicht nur der TFS sondern auch die Reporting Services und der SharePoint Server gesichert werden können. Aktuell rät Microsoft jedoch vom Einsatz der SharePoint Backup-Funktion ab, da diese gegen das Service Agreement verstößt wie genauere Recherchen zusammen mit dem SharePoint-Team ergeben haben. Aktuell wird mit Hochdruck an einer aktualisierten Version gearbeitet.

Quelle: Brian Harrys Blog Update on backing up TFS with Sharepoint

Der Team Foundation Server bietet ein extrem flexibles und leistungsfähiges Konzept zur Definition von Work Items. Damit lassen sich viele Szenarien über eine reine Konfiguration abbilden. Um die Mächtigkeit zu demonstrieren, hier ein paar Beispiele. Diese Beispiele nutzen den Process Template Editor der Bestandteil der kostenlosen Team Foundation Server 2010 Power Tools ist.

1.) Nur bestimmte Benutzer sollen ein Workitem eines bestimmten Typs anlegen dürfen

Ein verbreitetes Szenario ist, dass nur ein bestimmter Personenkreis Workitems eines bestimmten Typs (in diesem Beispiel der Typ Bug) anlegen dürfen, andere Benutzer sollen diese aber weiter bearbeiten können. Auch wenn die Umsetzung nicht ganz ideal ist lässt sich diese Funktion mit dem TFS relativ einfach erreichen.

Wie im Screenshot zu sehen, ist der Status Active für diesen Benutzer ungültig. Damit kann er das Workitem nicht speichern. Wie gesagt, nicht gerade schön aber wirkungsvoll. Wie erreichen wir nun diese Funktion?

Im Process Template Editor sehen wir im Workflow des Bug-WIT eine Transition von nirgendwo nach Active

Diese Transition wird verwendet wenn ein neues Workitem angelegt wird. Auf dieser Transition können wir nun eine Berechtigung einstellen. Dazu geben wir in das Feld “For” eine TFS Gruppe ein die diese Funktion ausführen darf. Alternativ kann bei “Not” eine Gruppe angeben die diese Transition nicht nutzen darf.

Dieses Feature kann natürlich auch für Transitions zwischen zwei Status genutzt werden, also z.B. um zu steuern wer den Bug schließen darf.

2.) Ein Feld muss gefüllt sein wenn ein anderes einen bestimmten Wert hat

In der Praxis kommt es häufiger vor, dass iin Abhängigkeit eines Wertes ein anderes Feld ausgefüllt sein muss. In unserem Beispiel nehmen wir mal an, dass auf dem Bug die Repro-Stepsausgefüllt sein müssen wenn der Bug die Priorität 1 hat.

Dazu stellen wir auf dem Feld Repro Steps eine WHEN-Regel ein

Und sagen wenn diese Bedingung erfüllt ist, dann soll das Feld ein Pflichtfeld sein

3.) Befüllen einer Auswahlliste in Abhängigkeit eines anderen Feldes

Das dritte Beispiel soll uns die Auswahlliste eines Feldes in Abhängigkeit eines anderen Feldes befüllen. In unserem Beispiel soll das Feld Team in Abhängigkeit der Area befüllt werden.

Dazu definieren wir für das Feld Team das wir zuvor hinzugefügt haben 2 When-Regeln

An dieser Stelle verwenden wir für die Regel nicht das Feld AreaPath da hierarchische Felder in Regeln nicht richtig unterstützt werden. Diese produzieren dann beim Import des WIT den Fehler "TF26204: The account you entered is not recognized". Der Umweg über die AreaID umgeht diese Problem.

Dann stellen wir einfach die AllowedValues für die beiden Fälle ein.

Man sieht also, dass der TFS einiges an Flexibiölität zu beieten hat. Es lohnt sich damit mal etwas zu experimentieren. Generell möchte ich aber vor Überregulierung warnen weil dies in der Praxis meist dazu führt, dass die Anwender behindert werden und somit die Akzeptanz des Tools sinkt.

Das Processtemplate für Scrum gab’s von Microsoft bereits als Beta, nun wurde die endgültige Version auf der Visual Studio Gallery veröffentlicht.

Folgende Elemente enthält das Template:

• Work Item Types
  • Sprint
  • Product Backlog Item
  • Bug
  • Task
  • Impediment
  • Test Case
• Reports
  • Release Burndown
  • Velocity
  • Sprint Burndown
  • Build Success Over Time
  • Build Summary
  • Test Case Readiness
  • Test Plan Progress
• SharePoint Project Portal

Hier noch Screenshots zum Sprint Burndown und Release Burndown Report.

Download

http://visualstudiogallery.msdn.microsoft.com/en-us/59ac03e3-df99-4776-be39-1917cbfc5d8e

Weitere Informationen zum Template
http://blogs.msdn.com/b/aaronbjork/archive/2010/07/19/announcing-microsoft-visual-studio-scrum-1-0.aspx

Endlich ist es soweit und Microsoft stellt ein VM Image für Visual Studio 2010 und TFS 2010 in der RTM Version bereit. Auf diesem Image sind nicht nur die Produkte sowie einige weitere benötigten Tools installiert, sondern es befinden sich darauf auch Demo-Daten (Tailspin Toys) und 9 Hands-On-Labs. Die VM ist für Hyper-V, Virtual PC 2007 SP1 verfügbar. Die Trial-Versionen auf der VM laufen bis zum 15. Dezember 2010.

Weitere Infos und Hinweise zum Download finden sich hier: http://blogs.msdn.com/b/briankel/archive/2010/06/25/now-available-visual-studio-2010-rtm-virtual-machine-with-sample-data-and-hands-on-labs.aspx

Im Team Foundation Server lassen sich die Work Items sehr einfach anpassen, neue Work Item Types lassen sich erzeugen und damit ein individuelles Process Template erzeugen. Das ganze geht sehr einfach und intuitive wenn mann den Process Template Editor aus den Team Foundation Server Power Tools verwendet (http://visualstudiogallery.msdn.microsoft.com/en-us/3e8c9b68-6e39-4577-b9b7-78489b5cb1da)

Wer mal auf den Geschmack gekommen ist, das Process Template im TFS anzupassen, wird durch ausprobieren und rumspielen schnell vor der Frage stehen, wie kann ich nun in einem bestehenden Projekt einen Work Item Type wieder löschen den ich nicht mehr brauche?

Hier hilft das Kommandozeilentool witadmin weiter das sich dirckt über die Visual Studio Eingabeaufforderung ausführen lässt.

witadmin destroywitd /collection:http://<Servername>:8080/tfs/<Team Project Collection> /p:<Team Projekt Name> /n:<Name des Work Item Types>

löscht den angegebenen Work Item Type.

Vorsicht,
mit diesem Kommando werden aber auch alle Work Items gelöscht, die diesen Typ verwenden, diese können ja vom System nach löschen der WITD nicht mehr verwaltet werden.

Wenn man also den WIT bestehender Work Items verändern möchte, dann sollte man diesen umbenennen und anschließend so anpassen dass er den neuen Anforderungen entspricht. Zum Umbenennen eines WIT hilft ebenfalls witadmin

witadmin renamewitd /collection:http://<Servername>:8080/tfs/<Team Project Collection> /p:<Team Projekt Name> /n:<Alter Name des Work Item Types> /new:<Neuer Name des Work Item Types>

In diesem Monat möchte ich die Leser meines Blogs auch auf das US-Meeting der Visual Studio User Group aufmerksam machen, da dieses Treffen dieses mal zu einer auch für Europa günstiger Zeit stattfindet (Donnerstag 17. Juni 18:00 Uhr).

Das Thema ist Scrum, TFS und Microsoft. Aaron Bjork wird das neue Scrum Template von Microsoft vorstellen das er maßgeblich verantwortlich ist. Also Informationen aus erster Hand die man nicht verpassen sollte. Für Mitglieder gibt es ein Recording des Meetings im Nachgang auch zum Download.

Das neue “Team Foundation Server Scrum v1.0 Beta” Template kann man sich hier herunterladen: http://visualstudiogallery.msdn.microsoft.com/en-us/59ac03e3-df99-4776-be39-1917cbfc5d8e
Nähere Informationen zum Meeting gibt es hier: http://www.vsalmug.com/Meetings/Announcements/June-2010/June-17,-2010--Scrum,-TFS-and-Microsoft.aspx

Kurzbeschreibung: Dieser Artikel beschreibt, wie Parameter an Reports über die URL übergeben werden können um so über Links oder im SharePoint Dashboard Reports bereits mit voreingestellten Parametern aufzurufen und so z.B. den Burndown eines spezifischen Sprints zu erhalten ohne die Parameter jedesmal von Hand einstellen zu müssen.

Im Team Foundation Server werden sie SQl Server Reporting Services (SSRS) genutzt um Reports zu generieren. Diese Reports geben schnell Auskunft über den aktuellen Status eines Projektes. Ein gutes Beispiel für einen solchen Report ist ein Burndown-Chart:

Solche Reports können sehr einfach aus dem SharePoint Portal oder aus dem TeamExplorer aufgerufen werden.

Nachteil an dieser Methode ist, dass bei jedem Aufruf die entsprechenden Parameter eingestellt werden müssen oder das Report Template immer an den aktuellen Sprint angepasst werden muss. Glücklicherweise unterstützen die SSRS die Übergabe von Parametern in der URL, so dass man sich sehr einfach Links generieren kann die den Report bereits vorkonfigurieren. Hierzu ruft man folgende URL auf:

http://<Reportserver URL oder IP>/ReportServer/Pages/ReportViewer.aspx?%2fTfsReports%2f<Project Collection Name>%2f<Tem Project Name>%2f<Ordner>%2f<Report Name>&rs%3aCommand=Render

In meinem Fall sieht das so aus:

http://myReportServer/ReportServer/Pages/ReportViewer.aspx?%2fTfsReports%2fartisoProjects%2fReportingDemo%2fProject+Management%2fBurndown+and+Burn+Rate&rs%3aCommand=Render

Damit können wir zunächst mal den Report direkt aufrufen. Nun können wir noch ein paar Parameter übergeben. Dazu müssen wir wissen wie die Parameter heißen. Dies kann man am einfachsten rausfinden indem man den Report über das SSRS Frontend aufruft und zwar über

http://<Reportserver URL oder IP>/Reports

und dann zu dem entsprechenden Report navigiert.  Die Seite die man nun erhält sieht ungefähr so aus:

Unter Eigenschaften / Parameter werden nun alle Parameter mit ihrem Namen angezeigt:

Wir wollen nun z.B. das Start- und Enddatum in unserer URL setzen. Dazu ergänzen wir die URL von oben einfach:

http://myReportServer/ReportServer/Pages/ReportViewer.aspx?%2fTfsReports%2fartisoProjects%2fReportingDemo%2fProject+Management%2fBurndown+and+Burn+Rate&rs%3aCommand=Render&StartDateParam=28.05.2010&EndDateParam=10.06.2010

Damit wird bereits das Start- und Endedatum korrekt gesetzt. Nun wollen wir noch die Iteration setzen. Hier ist die Geschichte nicht ganz so trivial, da der TFS recht kryptische Angaben zum Iteration-Pfad erwartet. Das liegt daran, dass das Warehouse Daten aus mehreren Project Collections enthält und vor allem bei einem Rebuild die IDs unverändert bleiben sollen. Diesen Parameter kann man auf verschiedene Arten ermitteln, der mit dem geringsten Vorbereitungsaufwand soll hier kurz beschrieben werden.

Dazu ruft man zunächst das SQL Server Management Studio auf und verbindet sich zu den Analysis Services. Hier erstellt man nun eine neue MDX-Query.

Dann wählt man im Feld “Cube” den Eintrag “Work Item” aus und geht im Baum unter Work Item \ Work Item.Iteration Hierarchy \ Iteration<n> wobei n die Hierarchieebene ist auf der sich die gesuchte Iteration befindet.

Die gewünschte Iteration zieht man nun per Drag & Drop auf die rechte Seite des Fensters und bekommt dort die ID der Iteration.

Diese muss jetzt noch URL-Encodiert werden. Dazu kann man beispielsweise den URLEncoder (http://code.msdn.microsoft.com/URLEncoder/Release/ProjectReleases.aspx?ReleaseId=3629) verwenden.

Damit sieht die IterationID nun so aus:
%5BWork%20Item%5D%2E%5BIteration%20Hierarchy%5D%2E%5BIteration1%5D%2E%26%5B%2D6991474436272448184%5D%26%5B%2D8595730757606272101%5D

Diese können wir nun als Parameter in unsere URL einfügen:
http://myReportServer/ReportServer/Pages/ReportViewer.aspx?%2fTfsReports%2fartisoProjects%2fReportingDemo%2fProject+Management%2fBurndown+and+Burn+Rate&rs%3aCommand=Render&StartDateParam=28.05.2010&EndDateParam=10.06.2010&IterationParam=%5BWork%20Item%5D%2E%5BIteration%20Hierarchy%5D%2E%5BIteration1%5D%2E%26%5B%2D6991474436272448184%5D%26%5B%2D8595730757606272101%5D

Damit bekommen wir alle Parameter wie gewünscht befüllt.

Über zusätzliche Parameter können wir nun das Parameterfeld und den Toolbar auch noch ausblenden. Dazu fügen wir noch die Kommandos &rc:Parameters=false&rc:toolbar=false an unsere URL an. És gibt noch eine ganze Reihe weiterer Commands, über die z.B. auch das Ausgabeformat gesteuert wreden kann. Eine genauerer Beschreibung der Commands findet sich hier: http://technet.microsoft.com/en-us/library/ms152835.aspx.

Damit können wir nun den Report schon über einen einfachen Link aufrufen. Um den Report in unser SharePoint Dashboard einzubauen sind jetzt nur noch wenige Schritte erforderlich. Dazu fügen wir in unser Dashboard zunächst ein Page Viewer Web Part ein.

In der Tool Pane können wir nun die URL für den Report angeben.

Damit lassen sich nun schöne Dashboards im SharePoint aufbauen die alle Reports bereits voreingestellt enthalten. Für einen neuen Sprint nutzt man dann die Funktion “Copy Dashboard” und passt die Parameter in den URLs entsprechend an.

Weitere Hinweise:

Manche Parameter lassen auch eine Mehrfachselektion zu. Diese können ebenfalls in der URL übergeben werden indem einfach der selbe Parameter mit unterschiedlichen Werten angegeben wird.

Weitere Links:

URL Parameter für SSRS: http://technet.microsoft.com/en-us/library/ms153586.aspx
Viewer Commands: http://technet.microsoft.com/en-us/library/ms152835.aspx
Parameter Prefixes: http://technet.microsoft.com/en-us/library/ms153579.aspx

Bei der weltweiten Usergroup Team System User Group Virtual Edition hat sich in den letzten Tagen einiges geändert, z.B. der Name. Wie das Produkt das im Zentrum unserer Aktivitäten steht, wurde die Gruppe in Visual Stuido ALM User Group umbenannt. Gleichzeitig haben wir eine neue Website online geschaltet. Sie finden uns jetzt unter http://www.vsalmug.com/default.aspx

In diesem Zuge werden wir zukünftig die Benachrichtigungen für unsere Meetings nicht mehr per E-Mail zustellen, sondern sie können sich Neuigkeiten unseren Blog mit den Ankündigungen per RSS abrufen (http://www.vsalmug.com/CMSPages/BlogRss.aspx?aliaspath=/Meetings/Announcements).

Zusätzlich ahben wir auf LinkedIn eine Gruppe eingerichtet über die sich die Mitglieder besser untereinander vernetzen können: http://www.linkedin.com/groups?home=&gid=2860483&trk=anet_ug_hm

Abschließend möchte ich auf unseren nächsten Vortrag noch hinweisen. Am Donnerstag, 06.05.2010 ab 19:00 wird Martin Woodward vorstellen wie die Integration mit nicht Microsoft-Plattformen über den Team Explorer Everywhere (vormals Teamprise) gelingt.

Team Explorer Everywhere 2010

Meeting Date: Thursday, May 6th, 2010
Time: 10:00AM PT (UTC-0700)
[Add to Calendar]
[Join Meeting]

Did you know that Team Foundation Server can be used for software development by your entire organization - not just the team using Microsoft platforms and technologies? In this session Martin Woodward will show you how you can get your Java, Mac, Linux, and Eclipse developers on board using Team Explorer Everywhere 2010. This session shows you how you can standardize on Team Foundation Server for the Application Lifecycle Management of your entire enterprise. See how to manage work items, version control, and build automation across technology and platform boundaries in your company and understand the features and functionality available to the people in your organization.

Speaker:  Martin Woodward

Martin Woodward is the Program Manager for the Microsoft Visual Studio Team Foundation Server Cross-Platform Tools Team and co-author of the book "Professional Application Lifecycle Management with Visual Studio 2010". Before joining Microsoft, Martin was voted Team System MVP of the Year and has spoken about Team Foundation Server at events internationally. Not only does Martin bring a unique insight into the inner workings of the product he has experience from over a half-decade of real world use at companies big and small that he is always happy to share. When not working or speaking, Martin can be found at his blog http://www.woodwardweb.com.

So langsam reift bei den letzten Source Safe Moikanern die Erkenntniss, dass es nun langsam Zeit wird sich nach einer anderen Quellcodeverwaltung umzusehen und eigentlich liegt da inzwischen nichts näher als der Team Foundation Server 2010 der nicht nur eine erstklassige Versionsverwaltung mit bringt sondern der acuh eine Vielzahl weiterer ALM-Funktionen beinhaltet und vor allem inzwischen in der MSDN Subscription kostenloas enthalten ist.

Wer wissen will, wie er schnell und einfach von Source Safe auf TFS migriert, findet alle notwendigen Infos hier : http://msdn.microsoft.com/en-us/library/ms253060.aspx

In der TFS Adminconsole oder im TFS Configuration Wizard können die Reporting Services für den TFS konfiguriert werden.

Man gibt hier den Server und ggf. die Instanz der Reporting Services an und klickt auf “Populate URLs”, dann werden die entsprechenden URLs automatisch ausgefüllt – normalerweise zumindest. Ich hatte die Situation, dass der User mit dem ich den TFS installiert habe auf dem Server auf dem die Reporting Services liefen kein Administrator war. Normalerweise ist das der einfachste Weg, den TFS Account auf dem Reporting Server als lokalen Administrator einzutragen, das ist aber nicht in allen Fällen erwünscht. Dann bekommt man die Fehlermeldung

TF255050: A connection cannot be made to the Report Server WMI provider. Verify the following:
1. You have entered the correct name for the server, including the instance name.
2. The Windows Management Instrumentation service is running on vs2010rcdemo.
3. The service is not blocked by Windows Firewall.
4. You have the required permissions to connect.

Details:
Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Eine damit verwandte Fehlermeldung ist

TF255186: The following SQL Server Reporting Services Instance could not be found: MSSQLSERVER. The server name is: vs2010rcdemo.

In beiden Fälle fehlen dem User WMI-Berechtigungen auf dem Reporting Server. Im ersten Fall der Remote-Zugriff auf die WMI generell, im zweiten Fall auf den Remote-Zugriff für die Reporting Services in der WMI. Um die gewünschte Operation ausführen zu können muss dem User zunächst Remote-Zugriff auf WMI gegeben werden:

1. Auf dem Reporting Server dcomcnfg.exe starten
2. Im linken Bereich Console Root\Component Services\Computers\My Computer öffnen
3. Aus dem Kontextmenü von “My Computer” den Eintrag “Properties” öffnen
   
4. Im Bereich “Launch and Activation Permissions” auf “Edit Limits” klicken
5. Den Benutzer mit “Add hinzufügen und ihm “Remote Launch” und “Remote Activation” vergeben
   

Anschließend kann der Remote-Zugriff per WMI auf die Reporting Services konfiguriert werden.

1. Auf dem Reporting Server wmimgmt.msc starten
2. Im linken Bereich auf WMI Control (Local) aus dem Kontext-Menü “Properties” auswählen
3. Auf den Reiter Security wechseln und im Baum Root\Microsoft\SqlServer\ReportServer auswählen
   
4. Auf den Button “Security” klicken und den gewünschten benutzer mit “Add” einfügen
5. Dem Benutzer “Enable Account” und “Remote Enable” als Rechte vergeben
   
6. Auf “Advanced” clicken, den Benutzer auswählen und dann auf “Edit” klicken
7. Bei “Apply to” “This namespace and subnamespaces” wählen
   

Mit diesen Einstellungen sollte nun das “Populate URLs” in der TFS Administration Console funktionieren.

Beim Deployment einer Environment auf meinen Host bekam ich den Fehler TF259115:

Speicher war eigentlich genug frei auf meinem Host und so war ich zunächst erstaunt, warum er das nicht deployen wollte. Des Rätsels Lösung liegt darin, dass die Placement Policy standardmäßig auf “Conservative” eingestellt ist. Das bedeutet, dass der Host beim Deployment den Speicherbedarf aller VMs auf dem Host ermittelt, unabhängig davon ob diese gestartet sind oder nicht. Im Betrieb könnten ja dann alle gleichzeitig gestartet werden was dann zu Problemen führt. D.h. im Idealfall hat man immer soviel Ressourcen, dass alle Environments die deployed sind gleichzeitig laufen können, momentan nicht benötigte Environments werden in der Library abgelegt.

Da ich aber auf meinem Demo-Notebook nicht soviel Speicher habe und dabei nie alle Environments gleichzeitig laufen sollen, wollte ich diese Limitierung umgehen. Dies kann man erreichen, indem man die Placement Policy auf Aggresive stellt. Dies erreicht man am besten durch einen TFSConfig-Aufruf:

TfsConfig Lab /hostgroup /CollectionName:labcollection /Edit /Name:"All Hosts"
/LabEnvironmentPlacementPolicy:Aggressive

Logging sent to file C:\ProgramData\Microsoft\Team Foundation\Server Configuration\Logs\CFG_SET_URL_0413_225508.log
Command: lab
TfsConfig - Team Foundation Server Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.
Are you sure you want to update the settings for this host group ? (Yes/No) y
The requested changes were successfully applied.

Die TFSConfig findet befindet sich im Pfad C:\Program Files\Microsoft Team Foundation Server 2010\Tools

Weitere Infos unter http://msdn.microsoft.com/en-us/library/dd547199(VS.100).aspx

Team Foundation Server 2010 bietet nun eine verbesserte Integration mit SharePoint. Für die einzelnen Team-Projekte wird die Verbindung zu einer SharePoint Site typischerweise beim Anlegen des Projektes einrichten, alternativ kann man das auch im Nachhinein konfigurieren. Dazu einfach im TeamExplorer auf dem Team Projekt rechte Maustaste und dann unter “Team Project Setting” “Portal Settings” auswählen.

Hier wählt man dann unter “Configure URL” eine der konfigurierten Web Applications aus.

Bekommt mann beim Bestätigen des Fensters folgen Meldung, dann hat der aktuelle Benutzer nicht ausreichen Berechtigungen auf die Site / SiteCollection:

Server was unable to process request. ---> Failed to activate feature 'TeamFoundationWeb' (ID: 310284e3-35d9-4b5d-99b5-c42147379877) at scope 'http://sarmoss02/sites/TFS2008/BI_KaBIS'.

Diese Berechtigungen müssen im SharePoint eingetragen werden.

Für den Release Candidate für VS / TFS 2010 gibt es acuh die passenden Power-Tools die viele nützliche Funktionen hinzufügen.

Kostenloaser Download: http://visualstudiogallery.msdn.microsoft.com/en-us/a4f8a47e-1f6b-49d6-8f6e-34f705a2001b

Mit dem TFS 2010 ist es nun möglich, denn Application-Tier über einen NLB-Cluster zu betreiben. Damit kann man Ausfallsicherheit und Load-Balancing für den App-Tier erreichen. Mit einem SQL-Cluster als Data-Tier skaliert der TFS nun sehr schön, sowohl in Punkte Performance als auch in Bezug auf die Ausfallsicherheit.

Nun liegt es natürlich nahe, die Reporting Services ebenfalls über den NLB zu betreiben, was an sich auch kein Problem ist. Man muss nur ein paar Einstellungen vornehmen. So hats bei mir funktioniert:

1.) Das Scale-out Deployment für die Reporting-Services auf beiden Servern aktivieren (setzt SSRS Enterprise voraus)

2.) Die Web Service URL auf die IP-Adresse des NLB einstellen

3.) In der TFS Admin Console die Reporting Services über den NLB registrieren. Das hat bei mir nur über die IP-Adresse funktioniert, nicht über den Namen. Da muss ich bei Gelegenheit mal danach schauen.

4.) In der Datei C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\rsreportserver.config unter <Service> folgendes Tag einfügen:

<Hostname>sartfsnlb01</Hostname>

5.) In der Web.config unter C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\ und unter C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportManager\ im Abschnitt <system.web> folgenden Tag einfügen:

<machineKey validationKey="627BF72BB33AA8D28CA2C3E80920BA4DF0B726F97EEFBB0F4818350D63E6AFA380811F13ED1F086E386284654DB3DAF676707464EEB73EBF79858F477D8E4F5C"
decryptionKey="F40B6E5A02B29A181D2D213B5ED8F50B73CFCFD0CC56E137" validation="SHA1" />

Achtung die Parameterwerte dürfen nuicht umgebrochen werden. Einen eigenen Key kann man sich einfach unter http://aspnetresources.com/tools/keycreator.aspx generieren lassen.

6.) Reporting Srevices neu starten.

7.) Nun werden bei einem Ausfall eines App-Tiers alle Reporting-Anfragen über den anderen App-Tier abgewickelt, der Anwender merkt davon nichts außer dass es beim ersten Zugriff nach dem Ausfall ein wenig länger dauert.

Christian zeigt in einem schönenn Blog-Beitrag wie einfach sich der TFS Basic installieren lässt (sogar auf einem Client-Betriebssystem) und wie schnell und einfach damit der Einstieg in die Versionsverwaltung und das Workitem-Tracking gelingt. Da kann nun wirklich jeder diese Features nutzen, auch Solo-Entwickler.

http://blogs.msdn.com/cbinder/archive/2009/10/19/vs2010-beta2-f-r-einsteiger-tfs-auf-win7-installieren-und-version-control-plus-bug-tracking-nutzen.aspx

Mit Team Foundation Server 2010 wird der TFS nun auch für kleinere Teams noch interessanter als bisher. Es gibt eine Reihe von Vorteilen gegenüber der aktuellen Version:

• Preis
  Es gibt im Moment noch keine abschließenden Informationen über das Pricing, aber voraussichtlich wird der Preis zukünftig wohl kaum noch ein Argument sien, den TFS nicht zu nutzen.
• Systemanforderungen
  Die Anforderungen an das System sind deutlich geringer als bei TFS 2008. So kann der TFS nun auf einem Domänen-Controller und sogar auf Client-Betriebssystemen installiert werden. Zudem können nun einige Komponenten wie SharePoint und Reporting optional installiert werden.
• Installation
  Der Installationsvorgang wurde deutlich vereinfacht.

Damit kommt Microsoft dem Slogen “ALM for the masses” einen großen Schritt näher.

Weitere Details gibt es auf dem Blog von Brian Harry:
http://blogs.msdn.com/bharry/archive/2009/10/01/tfs-2010-for-sourcesafe-users.aspx

Mit dem Work Item Type Designer (WIT Designer) können Work Item Type Definitionen einfach und bequem angepasst werden. Der WIT Designer ist Bestandteil der TFS Power Tools.

Mit dem WIT Designer kann man auch die Workflows auf den Work Item Types grafisch bearbeiten. Dazu kann man aus der Toolbox einfach neue States und Transistions auf das Workflow-Diagramm ziehen … zumindest wenn die Toolbox Elemente enthält. Sollte die Toolbox einmal leer sein, dann gibt es eine nicht ganz elegante aber wirksame Methode, man löscht einfach alle toolbox*.tdb Dateien und zwar au dem Ordner

C:\Users\<USERNAME>\AppData\Local\Microsoft\VisualStudio\8.0.

Danach erscheinen die Elemente ganz normal.

Beim Installieren eines Team Foundation Server 2010 Beta 1 habe ich einen Fehler TF254038 bekommen. Beim Anlegen einer SharePoint Web Application auf dem TFS hat der Wizard behauptet ich hätte die SharePoint Extensions nicht installiert.

Ich habe für den TFS und den SharePoint Server zwei getrennte Maschinen. Das Problem lag letztendlich darin, dass die Firewall auf der SharePoint Maschine den Zugriff auf die SharePoint Central Administration (Port 17012) geblockt hat. Nachdem ich den freigegeben habe, lief die Installation problemlos durch.

Im Juni werden wir beim EMEA-Meeting der Team System User Group Virtual Edition Ed Blankenship als Sprecher haben. Ed ist MVP für Team System und Release Manager bei Infragistics, dem führenden Hersteller von UI-Komponenten. Er wird in seinem Vortrag über die Erfahrungen bei der Einführung von VSTS bei Infragistics berichten. Dabei werden die verschiedenen Bereiche wie Versionsverwaltung, Build Management, Work Item tracking, das Management globaler Teams, automatisiertes Testen und vieles mehr aus einer Anwendersicht beleuchtet. Ein wirklich sehenswerter Erfahrungsbericht aus der Praxis.

Weitere Informationen unter www.tsug-ve.com.

Eigentlich versuche ich meinen Blog weitgehend werbefrei zu halten. Diesesmal möchte ich aber doch kurz auf die Seite www.alm-tools.de hinweisen, die mein Arbeitgeber artiso betreibt. Hier haben wir vor Kurzem eine Reihe neuer Tools rund um das Thema TFS und ALM (Application Lifecycle Management) veröffentlich, zum Teil kostenlos. Zudem gibt es hier inzwischen auch ein kleines Archiv mit Videos rund um das Thema das wir kontinuierlich ausbauen.

Mein Kollege Mark Bulmahn hat in einem Screencast ein Problem näher untersucht, das beim Merge in der TFS Source Countrol auftreten kann. Dabei geht es vor allem darum, dass Verschiebe-Operationen im Visual Studio Solution Explorer in der Source Control nicht als Verschiebe-Operation sondern als Delete und Add ausgeführt wird. Das führt dann zu Problemen bei einem späteren Merge.In dem Screencast sieht man, wie dieses Problem vermieden und auch wieder repariert werden kann.

Wenn schon mit Pre-Releases arbeiten, dann richtig habe ich mir gedacht und versucht den Team Foundation Server 2010 Beta 1 auf dem Windows 2008 Server R2 RC zu installieren. Nach einer kurzen Recherche im Internet bin ich auf diesen Blog-Post gestoßen. Mit den Informationen dort ist es mir tatsächlich gelungen, den TFS 2010 Beta1 und VSTS 2010 Beta1 auf dem Win2008R2 RC zu installieren. Damit komme ich nun auch auf meiner Demo-Maschine in den Genuss der Desctop-Experience von Win2008R2

Im Mai haben wir bei der TSUG-VE Ian Ceicis als Sprecher zum Thema Projekt Management mit TFS 2010. Er wird in seinem Vortrag die Neuerungen rund um das Workitem-Tracking in TFS 2010 vorstellen.

Want to get the skinny on the latest enhancements coming in TFS 2010, come see demos of the updated MSF Agile template, the new Agile workbooks, the new Excel reports, and the Microsoft Project client improvements such as Hierarchical work items, rollups, and project summary tasks. This session will be packed with demos from  Beta 1 and will be a great way to start getting familiar with the new tools coming in 2010. Bring your hardest questions, join the conversation, and walk away with the ability to see how your next project will run smoothly if you start using TFS 2010.

This month's meeting is being presented by Ian Ceicys.  Ian is a member of Microsoft's Global ALM Practice and an active member of the VSTS Rangers.

 

Das Treffen findet am Donnerstag, 21.05.2009 um 19:00 statt.

Weitere Infos unter http://www.tsug-ve.com

    &  

Mit der Version 3 des Design-Tools für WPF und SilverLight, Expression Blend bekommt nun endlich die Unterstützung für den Team Foundation Server um die Source-Dateien in der Versionsverwaltung abzulegen. Hierzu muss ein entsprechendes Hotfix installiert werden. Dann hat man im Project-View zusätzliche Icons die den Auscheck-Status der Dateien anzeigt und im Kontext-Menü befinden sich entsprechende Kommandos für die Versionsverwaltung.

Hinweis: Damit das beim ersten Start auch wirklich funktioniert, muss man im Visual Studio den Team Explorer wenigstens einmal gestartet haben und dort den Server registrieren. Sonst bekommt man die Meldung "Unable to determine workspace" im Expression Blend.

Beim Checkin ist auch die sehr nützliche Funktion zur Verknüpfung von Workitems beim Checkin verfügbar.

Damit kann Expression Blend nun endlich in den Entwicklungs-Prozess von Software-Anwendungen integriert werden und steht nicht nur als separates Design-Tool bereit.

Auf einer neuen TFS-Instanz hatte ich eben ein seltsames Phänomen. Ich konnte das erste Team-Projekt problemlos anlegen. Dazu verwendete ich einen Team_Explorer mit einer Visual Studio Shell Installation auf dem Server. Als ich allerdings das zweite Projekt anlegen wollte, kam eine Fehlermeldung, dass mir die Berechtigungen auf den Reporting Services fehlen. Seltsam nur, dass es beim ersten Projekt geklappt hat und dazwischen nichts geändert wurde. Mit einem kleinen Trick konnte ich dann doch ein zweites Projekt anlegen, nämlich indem ich alle Projekte aus dem Team-Explorer entfernt habe. Dann konnte ich wieder genau ein neues anlegen.

Die eigentliche Lösung für das Problem brachte aber die Installation des SP1 auf dem Server. Dabei ist zu beachten, dass das SP1 für den Team-Explorer nicht Bestandteil des Team Foundation Server SP1 ist, sondern des Visual Studio SP1. Also das Visual Studio SP1 installiert und danach lief es wunderbar.

Grade erst wurden die EMEA-Meetings der Team System User Group Virtual Edition ins Leben gerufen, schon können wir mit einem Highlight aufwarten. Für unser April-Meeting konnten wir Brian Harry als Sprecher gewinnen. Brian wird über die Internal Adoption von VSTS sprechen. Brian ist Technical Fellow und Manager der Product Unit für den team Foundation Server.

Also gleich als Mitglied registrieren und am 16. April dabei sein!

Weitere Informationen zum Meeting gibt’s unter www.tsug-ve.com.

Der Tatsache, dass Testen eine wichtige Bedeutung in der Software-Entwicklung hat, trägt Microsoft ja bereits seit einiger Zeit Rechnung indem eine spezielle Edition des Visual Studio für Tester generiert wurde. Diese Edition besitzt umfangreiche Funktionenzu verschiedenen Test-Methoden. Das Ranger-Team hat nun einen Quick Reference Guide veröffentlicht der auf 83 Seiten diese Funktionen beschreibt und verschiedene Best Practices anbietet. Hierbei sind die Erfahrungen eingeflossen, die Service Labs, ein großes Test-Center, bei der Adaption von Team Test gemacht hat. Das Dokument enthält viele wertvolle Hinweise, wie VSTT in der Praxis eingesetzt und individuell erweitert werden kann.

Definitiv lesenswert für jeden, der etwas mehr über dieses Toolset erfahren möchte.

Download VSTT 2008 Quick Reference Guide

Die Integration von Visual Studio 2005 / 2008 mit dem TFS ist ideal gelöst. Jedoch gibt es auch noch andere Entwicklungs-Plattformen die keine direkte Integration mit dem Team-Explorer erlauben wie z.B. ältere Visual Studio Versionen und leider auch immer noch das SQl Server Management Studio. Diese IDEs überstützen doch recht häufig den sog. MSSCCI-Standard und es gibt bereits seit längerer Zeit einen entsprechenden MSSCCI-Provider für den TFS 2008. Dieser hatte bisher immer noch den nachteil, dass er reine Sourcecontrol Features unterstützt hat und z.B. das Verknüpfen von Workitems beim Checkin nicht möglich war. In der neuesten Version ist dies nun auch möglich und somit ist auch bei IDEs die den Team Explorer nicht integrieren ein komfortables Arbeiten mit dem TFS möglich. Ich habe hier mal ein Beispiel für das SSMS 2008.

Zunächst muss der TFS MSSCCI-Provider unter Optionen eingestellt werden.

Legt man nun ein Datenbankprojekt an, dann kann man das in gewohnter Art und Weise mit der Source Control verbinden und man erhält Fenster “Pending Checkins”.

Führt man hier nun den Checkin aus, kommt der aus dem Team-Explorer bekannte Dialog

Hier können nun z.B. Checkin-Kommentare angegeben oder Workitems verknüpft werden.

Sogar die Checkin-Plicies funktionieren hier wie gewohnt.

Damit ist ein komfortables und problemloses Arbeiten auch mit solchen Umgebungen möglich, die den Team-Explorer nicht direkt integrieren. Und damit wieder ein Grund mehr, nun endlich auf den TFS zu setzen und SourceSafe und Konsorten endlich in Rente zu schicken.

Mit diesem Sidebar-Gadget kann man sich den Status seiner Build schnell und einfach anzeigen lassen.

Jim Lamb : Team Build Monitor – Vista Sidebar Gadget

Am 16.03.09 geht ein neuer Webcast von mir online mit dem Thema "Team Build mit Custom Build Tasks erweitern". Ich möchte hier schon mal die entsprechenden Infos veröffentlichen.

In TeamBuild lassen sich eigene Build-Task integrieren. Diese können sehr einfach erstellt werden. Hierzu wird eine Klasse erstellt und diese von Task abgeleitet. Im folgenden Beispiel wird ein Build-Task erstellt, der im Rahmen des Builds die Version der Anwendung setzt. Und zwar soll hier die Build-Nummer in der Versionsnummer der Assembly abgebildet werden. Dies bietet Vorteile, wenn zu einer bestimmten Anwendungsversion der entsprechende Build identifiziert werden soll.

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Text;

   4: using Microsoft.Build.Utilities;

   5: using Microsoft.Build.Framework;

   6:  

   7: namespace Artiso.BuildTasks

   8: {

   9:     /// <summary>

  10:     /// Creates a AssemblyVersion out of a BuildNumber

  11:     /// </summary>

  12:     /// <remarks>

  13:     /// AssemblyVersion.Minjor and AssemblyVersion.Minor will be defined fiexed in

  14:     /// the Build-Script. If the BuildNumber is Dev_Versioning_20090305.4 we use 

  15:     /// two digit year and month for AssemblyBuildNumber and day and 3 digit BuildRevision

  16:     /// for AssemblyRevision. BuildRevisio 

  17:     /// </remarks>

  18:     /// <example>

  19:     /// Dev_Versioning_20090305.4 => xx.yy.0903.05004

  20:     /// </example>

  21:     public class ExtractRevision : Task

  22:     {

  23:         #region [rgn] Fields(3)

  24:         private string buildRevision;

  25:         private string buildVersion;

  26:         private string buildNumber;

  27:         #endregion

  28:  

  29:         #region [rgn] Properties(3)

  30:         /// <summary>

  31:         /// Input Build Number

  32:         /// </summary>

  33:         [Required]

  34:         public string BuildNumber

  35:         {

  36:             set { buildNumber = value; }

  37:         }

  38:  

  39:         /// <summary>

  40:         /// Returns the sortened date of the build

  41:         /// </summary>

  42:         [Output]

  43:         public string BuildVersion

  44:         {

  45:             get { return buildVersion; }

  46:         }

  47:  

  48:         /// <summary>

  49:         /// Returns the Build Revision (number of build at this day

  50:         /// </summary>

  51:         [Output]

  52:         public string BuildRevision

  53:         {

  54:             get { return buildRevision; }

  55:         }

  56:         #endregion

  57:  

  58:         #region [rgn] Methods(1)

  59:         public override bool Execute()

  60:         {

  61:             buildVersion = "0";

  62:             buildRevision = "0";

  63:  

  64:             if (buildNumber != null && buildNumber.Contains("."))

  65:             {

  66:                 string[] buildNumberParts = buildNumber.Substring(buildNumber.LastIndexOf('_')+1).Split('.');

  67:  

  68:                 // Dev_Versioning_20090305.4 -> 0903.02005

  69:                 // use year (2 digits) and mont for buildversion

  70:                 buildVersion = buildNumberParts[0].Substring(2, 4);

  71:  

  72:                 // use day and number of build in this day for build revision

  73:                 buildRevision = buildNumberParts[0].Substring(6) + buildNumberParts[1].PadLeft(3, '0');

  74:             }

  75:             return true;

  76:         }

  77:         #endregion

  78:     }

  79: }

Das Property BuildNumber wird als Input-Parameter verwendet und mit dem Attribut [Required] versehen. Darüber kann die BuildNumber in unseren Task übergeben werden. Durch das Attribut [Output] werden die beiden Properties BuildVersion und BuildRevision als Rückgabewerte definiert. Beim Ausführen des Builds wird die Methode Execute aufgerufen. Hier werden nun aus der Build-Number die entsprechenden Informationen extrahiert und diese dann in BuildVersion und BuildRevision zurückgeschrieben. Dies ist natürlich nur ein einfaches Beispiel, aber mit diesen Grundlagen können nun beliebige Build-Tasks definiert werden. Im nächsten Schritt schauen wir uns an, wie wir diesen Custom Build Task nun in unseren Build-Prozess einbinden. Hierzu kopieren wir zunächst die Assembly in einen entsprechenden Ordner. Hier bietet sich an unter c:\Program Files\MSBuild einen entsprechenden Ordner anzulegen und dort die Assemblies abzulegen.

Nun muss das Build-Script entsprechend angepasst werden. Diese liegt in der Quellcode-Verwaltung und muss zum Bearbeiten zuerst aus- und danach wieder eingechecked werden. Um diesen Vorgang zu vereinfachen empfehle ich die TFS Sidekicks (http://www.attrice.info/downloads/index.htm) die direkt im Kontextmenü des TeamExplorers entsprechende Kommandos einfügt. Das nun ausgecheckte PROJ-File kann nun bearbeitet werden.

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <!-- DO NOT EDIT the project element - the ToolsVersion specified here does not prevent the solutions 

   3:      and projects in the SolutionToBuild item group from targeting other versions of the .NET framework. 

   4:      -->

   5: <Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

   6:  

   7:   <!-- Do not edit this -->

   8:   <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />

   9:   <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>

  10:  

  11:   <UsingTask AssemblyFile="$(MSBuildExtensionsPath)\ArtisoBuildTasks\ArtisoBuildTasks.dll"

  12:     TaskName="ExtractRevision"/>

  13:  

  14:   <PropertyGroup>

  15:     <!-- Assembly version properties. Adjust here Major and Minor Version-->

  16:     <AssemblyMajorVersion>1</AssemblyMajorVersion>

  17:     <AssemblyMinorVersion>3</AssemblyMinorVersion>

  18:     <AssemblyBuildNumber>1</AssemblyBuildNumber>

  19:     <AssemblyRevision>1</AssemblyRevision>

  20:   </PropertyGroup>

  21:  

   1: ...

   2: <Target Name="AfterGet">

   3:    <ItemGroup>

   4:      <AssemblyInfoFiles Include="$(SolutionRoot)\**\assemblyinfo.cs" />

   5:    </ItemGroup>

   6:  

   7:    <Message Text="Get Revision Number from BuildNumber &quot;$(BuildNumber)&quot;." />

   8:    <ExtractRevision BuildNumber="$(BuildNumber)">

   9:      <Output TaskParameter="BuildRevision" 

  10:              PropertyName="AssemblyRevision" />

  11:      <Output TaskParameter="BuildVersion" 

  12:              PropertyName="AssemblyBuildNumber" />

  13:    </ExtractRevision>

  14:  

  15:    <!-- Update all the assembly info files with generated version info -->

  16:    <Message Text="Modifying AssemblyInfo files under &quot;$(SolutionRoot)&quot;." />

  17:    <Attrib Files="@(AssemblyInfoFiles)" Normal="true" />

  18:    <FileUpdate Files="@(AssemblyInfoFiles)"

  19:                Regex="AssemblyVersion\(".*"\)\]" 

  20:                ReplacementText="AssemblyVersion("$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision)")]" />

  21:    <FileUpdate Files="@(AssemblyInfoFiles)"

  22:                Regex="AssemblyFileVersion\(".*"\)\]" 

  23:                ReplacementText="AssemblyFileVersion("$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision)")]" />

  24:    <Message Text="AssemblyInfo files updated to version &quot;$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision)&quot;" />

  25:  </Target>

  26:  

  27: </Project>

   1: <Target Name="AfterCompile">

   2:   <CreateItem Include="..\Binaries\Release\**\*.*" Exclude="..\Binaries\Release\**\*.pdb;..\Binaries\Release\**\*codeanalysis*">

   3:     <Output ItemName="ZipFiles" TaskParameter="Include"/>

   4:   </CreateItem>

   5:  

   6:   <Message Text="Zipping Buildresult to \\tfs\deploy\BuildDemo\BuildDemo_$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision).zip" />

   7:  

   8:   <Zip ZipFileName="\\tfs\deploy\BuildDemo\BuildDemo_$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision).zip" 

   9:        Files="@(ZipFiles)"

  10:        WorkingDirectory="..\Binaries\Release\"/>

  11:  

  12:   <Mail SmtpServer="tfs"

  13:           To="tschissler@tfs"

  14:           From="build@tfs"

  15:           Subject="BuildDemo v$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision) released"

  16:           Body="A new version of the BuildDemo was released. Please find the newest files attached to this mail. You can also download them from the download folder."

  17:           Attachments="\\tfs\deploy\BuildDemo\BuildDemo_$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision).zip"/>

  18: </Target>

Hier sammeln zunächst alle Dateien aus dem Build-Drop-Verzeichnis exklusive der PDB- und Codeanalyse-Dateien In Zeilen 8-10 werden diese Dateien in ein ZIP-File verpackt dem wir im datei-Name die Version mitgeben. Anschließend versenden wir eine e-Mail der wir dieses ZIP-File als Attachment anhängen.

Als zweite Variante wollen wir im Rahmen des Builds ein Click-Once Paket erstellen. Die Herausforderung bei der Erstellung des ClickOnce-Paketes ist dass dort die Deployment-Url hinterlegt werden muss. Vor allem wenn verschiedene Pakete für unterschiedliche Kunden erstellt werden sollen, ist dies nur durch eine Automatisierung im Rahmen des Builds sinnvoll handelbar. Hierzu ersetzen wir den AfterCompile-Target durch folgendes Script:

   1: <Target Name="AfterCompile">

   2:    <!-- Publish using ClickOnce -->

   3:    <Message Text="modify Publish directory for $(SolutionRoot)" />

   4:    <!-- Update directory where to publish the project -->

   5:    <ItemGroup>

   6:      <ProjectFiles Include="$(SolutionRoot)\Source\Dev\BuildDemo\BuildDemo.csproj" />

   7:    </ItemGroup>

   8:    <PropertyGroup>

   9:      <PublishDir>\\tfs\Deploy\BuildDemo\ClickOnce\</PublishDir>

  10:      <InstallUrl>\\tfs\Deploy\BuildDemo\ClickOnce\</InstallUrl>

  11:    </PropertyGroup>

  12:    <Attrib Files="@(ProjectFiles)" Normal="true" />

  13:    <FileUpdate Files="@(ProjectFiles)"

  14:      Regex="<PublishUrl>.*</PublishUrl>"

  15:        ReplacementText="<PublishUrl>$(PublishDir)</PublishUrl>" />

  16:    <FileUpdate Files="@(ProjectFiles)"

  17:        Regex="<InstallUrl>.*</InstallUrl>"

  18:        ReplacementText="<InstallUrl>$(InstallURL)</InstallUrl>" />

  19:  

  20:    <MSBuild Projects="@(ProjectFiles)"

  21:    Properties="PublishDir=$(PublishDir);ApplicationVersion=$(AssemblyMajorVersion).$(AssemblyMinorVersion).$(AssemblyBuildNumber).$(AssemblyRevision)"

  22:            Targets="Publish" />

  23:  

  24:  </Target>

In den Zeilen 5 bis 7 lesen wir das csproj-File der Anwendung in eine ItemGroup. Anschließend definieren wir zwei Properties für PublishDir und InstallUrl. Diese werden dann über eine Ersetzung in die csproj-Datei eingefügt. Anschließend wird ein MSBuild-Task gestartet der das ClickOnce-Paket erstellt und an der angegebenen PublishDir und mit der Versionsnummer veröffentlicht.

Das Ganze wird in dem genannten Webcast Live demonstriert. Über Feedback würde ich mich sehr freuen.

Details zur Veranstaltung: Team Build mit Custom Build Tasks erweitern [1032405249] - Microsoft Deutschland GmbH

Hier hatte ich beschrieben, wie man die Test-Results aus Visual Studio nach Excel übertragen kann. Heute möchte ich ein Tool vorstellen, das es erlaubt, TRX-Files nach HTML zu konvertieren.

Zunächst speichert man das Test-Result in ein TRX-File. Dies geht über den Button "Export Test Run Results".

Anschließend kann man mit dem Tool trx2html das HTML-File erstellen. trx2html ist ein Open-Source Projekt von CodePlex. Es wird als Commandozeilen-Tool ausgeführt und als Parameter wird einfach das TRX-File angegeben. Als Ergebnis wird nun ein HTML-File erstellt das die Testergebnis entsprechend dokumentiert und auch einige Drill-Down-Funktionen bietet:

Durch einen Klick auf das rote Kreis-Icon neben einem der Test kann z.B. ein Stack-Trace eingeblendet werden.

trx2html - Home

Die Team System User Grroup - VE ist eine virtuelle Usergroup die zwei mal im Monat ein Treffen hat in deren Rahmen Vorträge rund um das Thema Team System gehalten werden. Die Treffen finden virtuell in Second Life und über Live Meeting statt. Für Europäer ist das jeweils zweite Treffen zeitlich günstig am Samstag Nachmittag. 

Team System User Group - Virtual Edition

Auf MSDN gibt es einen neuen Bereich zu Team System. Die Seite ist in einer ersten Iteration veröffentlicht und wird nun kontinuierlich mit weiterem Content ergänzt. Hier sind die Inhalte wesentlich übersichtlicher aufbereitet als auf den alten Seiten. Wer also mit Team System arbeitet oder das vorhat, einfach mal vorbeischauen. Feedback zu der Seite ist sehr willkommen und kann hier abgegeben werden.

Team System Home auf MSDN

Der Team Foundation Server verwendet in den Versionen bis 2008 eine XML-Datei um den Build-Prozess zu steuern. Diese Datei wird Build Project File genannt und wird in der Versionsverwaltung abgelegt um vom Buildcomputer genutzt werden zu können. Jeder der diese Datei aber schon manuell bearbeitet hat, kennt das umständliche Vorgehen umd die Date erst aus der Quellcode-Verwaltung auszuchecken, und nach dem Bearbeiten wieder einzuchecken. Einfacher geht das mit den TFS Sidekicks, die direkt im Context-Menü des Team-Explorers eine Checkout und Checkin-Funktion für das Project-File anbietet.

Darüber hinaus bieten die TFS Sidekicks noch weitere sehr nützliche Funktionen, auf jeden Fall ist das Tool einen näheren Blick wert.

Attrice Corporation - Team Foundation Sidekicks

Today I had my second talk on the TechEd in Barcelona. It was about closing tool gaps in development processes and using the TFS API. Thanks to all attendees joined my session. We had some very interesting discussion at the end, and I got a lot of positive feedback like “This was what I was looking for”. For all here comes the promised downloads for the slides and demos. Feel free to use them in either way.

And here the link to download WorkitemManager. At www.alm-tools.com you can download the Open version which is free and also the source code. And if you are interested in one of the tools I showed, please just send me an e-Mail to tschissler (at) artiso (.) com.

Mit ein wenig Verspätung wurden die TFS Power Tools October 2008 nun released. Dafür wurden aber noch ein paar wichtige Bugs gefixed. Damit stehen nun die größten Power-Tools zur verfügung, die jemals veröffentlicht wurden. Über die Features habe ich bereits hier gebloggt.

ich denke damit werden ein paar wichtige Lücken geschlossen und durch die Explorer Integration wird TFS für weitere Szenarien interessant.

Download details: Team Foundation Power Tools

Der artiso Workitem Manager ist ein Tool mit dem sich Workitems hierarchisch organisieren lassen. Diese hierarchische Organisation bietet verschiedene Vorteile. Neben einer besseren Strukturierung und einer erhöhten Übersichtlichkeit vor allem auch eine visuelle Traceability. Damit ist gemein, dass durch die Hierarchie sichtbar wird welche Tests und Implementierungsaufgaben einem Feature zugeordnet sind. Die ist z.B. sehr hilfreich, wenn sich das Feature ändert zu erkennen, welche Workitems auf mögliche Auswirkungen überprüft werden können. Wie hierarchische Workitems in Projekten hilfreich eingesetzt werden, habe ich zusammen mit Christian Binder in diesem MSDN-Webcast erörtert.

Leider bringt der TFS in der Version 2008 diese Hierarchie nicht von Haus aus mit. Deshalb hat artiso den Workitem Manager entwickelt. Diesen gibt es nun auch als Open-Version. Die Open-Version ist kostenlos und wird auch als Source-Code bereitgestellt. Wie sich der Workitem Manager Open zur Vollversion unterscheidet kann man der unten stehenden Funktionsmatrix entnehmen. Weiter unten gibt's noch eine Screenshot.

Den Donload für das Setup und den Source-Code findet man unter http://www.alm-tools.de. Gerne freue ich mich über euer Feedback zu dem Tool.

Auf Channel 9 gibt es eine ganze Reihe von Videos zu Visual Studio 2010 (Codename Rosario).

Monday, September 29th:
- Announcing Visual Studio Team System 2010

Architecture Day (Tuesday, September 30th):
- Cameron Skinner: Visual Studio Team System 2010 - Architecture
- "Top-down" design with Visual Studio Team System 2010
- "Bottom-up" Design with Visual Studio Team System 2010 Architect
- ARCast.TV - Peter Provost on what’s coming for Architects in Visual Studio Team System

Business Alignment (Wednesday, October 1st):
- Achieving Business Alignment with Visual Studio Team System 2010
- Agile Planning Templates in Visual Studio Team System 2010
- Enterprise Project Management with Visual Studio Team System 2010
- Requirements Management and Traceability with Visual Studio Team System 2010

Software Quality (Thursday, October 2nd):
- Better Software Quality with Visual Studio Team System 2010
- Manual Testing with Visual Studio Team System 2010
- Historical Debugger and Test Impact Analysis in Visual Studio Team System 2010

Team Foundation Server (Friday, October 3rd):
- Brian Harry: Team Foundation Server 2010
- Branching and Merging Visualization with Team Foundation Server 2010
- Enterprise Team Foundation Server Management with Mario Rodriguez
- Team Foundation Server 2010 Setup and Administration
- An early look at Team Foundation Build 2010 with Jim Lamb
- A first look at Visual Studio Team System Web Access 2010
- Update on Team Foundation Server Migration and Synchronization

Visual Studio Team System 2010 Week on Channel 9! | VisualStudio | Channel 9

Christian Binder hat eine sehr Übersichtliche Darstellung über die verschiedenen VSTS-Sessions auf dem Technical Summit in Berlin zusammengestellt. Die Map stellt nicht nur die dort live vorgestellten Sessions zusammen, soondern auch bereits bestehende und in Kürze erscheinende Webcasts zu dem Thema. Die Map zeigt auch, dass wir versucht haben unsere Inhalte auf dem Technical Summit so aufeinander abzustimmen, dass sowohl EInsteiger als auch fortgeschrittene Anwender sich ein möglichst komplettes Bild von VSTS machen kann. Die WebCast sind thematisch entsprechend eingeordnet und können als Vorbereitung bzw. zur Vertiefung zu den Live-Sessions genutzt werden.

Danke Christian, endlich mal eine übersichtliche Darstellung der verschiendenen Inhalte! 

Was bedeutet was?

Christian Binder's Weblog : Alle Visual Studio Teamsystem Session auf dem Technical Summit 2008 im Überblick

Die Integration des TFS mit Visual Studio ist eine richtig schöne Sache. Eine Stelle an der die Vorteile dieser Integration schön sichtbar werden ist die Erzeugung einen Workitems direkt aus einem Test-Result heraus. Wenn also z.B. ein Test fehlgeschlagen ist, kann daraus direkt ein Bug-Workitem erzeugt werden. Der Clou dabei ist, dass das Test-Result automatisch auf dem TFS veröffentlicht und als Attachment an das Workitem angehängt wird. Damit hat der Entwickler der den Bug beheben soll Zugriff auf den durchgeführten Test und die Results. Dies funktioniert mit allen Testarten sofern der Entwickler mit seiner Visual Studio Edition die entsprechenden Testarten ausführen kann. Somit kann der Entwickler z.B. bei einem Unit-Test diesen verwenden um den Testcase einfach zu debuggen. Und bei manuellen Tests stellt die Testspezifikation die Beschreibung der Repro-Steps dar. Auf jeden Fall ein Zeitgewinn. Man kann aber beispielsweise damit auch Aufgaben definieren, dass ein bestimmter Test noch mit zusätzlichen Test-Cases angereichert werden soll etc.

Dazu geht man einfach mit der rechten Maustaste auf den entsprechenden Eintrag im Testresults-Fenster und wählt aus dem Kontext-Menü den entsprechenden Workitemtyp aus.

Wird statt der Liste der Workitems "No Active Team Project" angezeigt, dann gibt es hier eine einfache Lösung, die aber nicht ganz intuitiv ist.

1.) Sicherstellen dass im Team-Explorer das gewünschte Projekt angezeigt wird in dem man das neue Workitem anlegen möchte.

2.) Dieses Team-Projekt aktiv markieren (das Projekt wird fett dargestellt)

Nun werden die WorkitemTypen die im ProcessTemplate dieses Projektes definiert sind zur Auswahl angezeigt. Das Projekt selbst muss nicht unbedingt in der Quellcode-Verwaltung des TFS abgelegt sein.

Seit ein paar Tagen ist ein neuer Web-Cast online in dem ich zusammen mit Christian Binder zusammen erörtere welche Vorteile die hierarchische Organisation von Workitems bietet. Ohne schon zuviel vom Inhalt verraten zu wolle, es geht um Requirementmanagement, Traceability, Impace-Analyse und einiges mehr. Im Webcast wird ein kostenloses Tool vorgestellt mit dem bereits mit TFS 2008 hierarchische Workitems realisiert werden können.

Die nächste Version der TFS Power-Tools werden ein paar richtig coole Features enthalten sein.

Z.B. ein neuer Knoten "Team Members" im Team Explorer über den man mit allen Team-Mitglieder kommunizieren kann und worüber man auch z.B. schnell die Pending Changes oder die Shelfsets einzelner Mitglieder findet etc.

Zusätzlich lassen sich damit Komponenten wie z.B. Checkin-Policies oder Workitem-Controls einfach distributieren.

Und von vielen heiß ersehnt, es gibt jetzt eine Windows Explorer Integration zur Quellcode-verwaltung.

Darüber hinaus ist noch der Power-Shell Support Bestandteil der neuen Power-Tools

Weitere Details unter Brian Harrys Blog

bharry's WebLog : Preview of the next TFS Power Tools release

Ab dem 01.10.2008 werden Besitzer einer Visual Studio 2008 Team System Development Edition auch eine Visual Studio 2008 Team System Database Edition erhalten und umgekehrt. In Visual Studio 2010 werden diese beiden Produkte wohl zu einem verschmolzen.

Weitere Informationen unter Visual Studio 2010 and .NET Framework 4.0 Overview im Kapitel "Better Together – Visual Studio Team System Development Edition and Database Edition"

Wenn vom Team Explorer die Versionen 2005 und 2008 auf einem Rechner installiert werden, kann es bei der Office-Integration zu Problemen kommen die mit dem Fehler TF80076 quittiert werden. Wie man dieses beheben kann beschreibt dieser Artikel.

TFS Excel integration fails with error TF80076 - after installing 2008 Team Explorer

Eine neue User-Group die sich speziell mit Team System beschäftigt wurde vor kurzem gegründet. Dabei handelt es sich um eine virtuelle usergroup, das heißt die Treffen finden in Second Life und über Office Live Meeting statt. Ich bin schon mal gespannt auf das nächste Treffen.

Team System User Group - Virtual Edition

In inzwischen über 47 Videos werden in dieser Serie HowTos rund um das Thema Visual Studio Team System präsentiert. Kurz und verständlich bekommt man hier viele BestPractices und Tips.

"How Do I?" Videos for Team System

Es ist wohl noch eine weile hin, bis wir Rosario wirklich nutzen dürfen. Brian Harry hat aber schon mal vorab veröffentlicht, welche Systemvoraussetzungen und Abhängigkeiten Rosario haben wird. So werden wohl unter anderem auch SQL 2005 und Office 2003 nicht mehr unterstützt. Dies gibt jetzt bereits die Möglichkeit, rechtzeitig zu planen und sich auf die Anforderungen ggf. entsprechend vorzubereiten.

bharry's WebLog : Charting a course for TFS "Rosario"

Der Team Foundation Server bietet die flexible Möglichkeit ProcessTemplates individuell anzupassen. Diese ProcessTemplates enthalten die Definition der Workitemtypes (welche gibt es und welche Felder haben diese), die Workflows (was passiert wenn ich bei einem bestimmten Workitem eine bestimmte Aktion auslöse), und vieles mehr wie Standarddokumente etc.

Dieses ProcessTemplate kann man nicht nur im Vorfeld definieren, sondern auch für laufende Projekte noch anpassen, was in der Praxis eine enorme Hilfe ist. Wie's genau geht beschreibt Christian Binder in einem zweiteiligen Blog-Beitrag.

Teil 1
Teil 2

Richard Hundhausen hat eine Liste mit Tools und nützlichen Helferlein rund um Team Foundation Server veröffentlicht. 

Team System Widgets

Seit kurzem ist der TFS Administration Guide zum Download bereitgestellt. Der Guid beschreibt viele Aspekte der Administration des TFS über Berechtigungsverwaltung, Anpassung von Workitemtypen und Process-Templates Backup und vieles mehr.

Download details: Administration Guide for Team Foundation Server

Bin gerade auf ein Post von Martin Woodward gestossen. Das zeigt doch mal wieder, wie kreativ wir Entwickler sind (oder sollte ich eher sagen dass wir das Kind in uns ausleben).

Martin Woodward: Brian the Build Bunny

Die TFS Power-Tools sind jetzt öffentlich verfügbar. Das Paket bringt einige Verbesserungen, die das Arbeiten mit dem TFS noch komfortabler machen. Die wichtigste Neuerung seht ihr hier, eine ausführlichere Beschreibung bei Brian Harry.

Neue Oberfläche um TFS Alerts zu aboniieren, die auch flexible Filterkriterien erlaubt.

bharry's WebLog : July '08 Power Tools are available!

Download July 08 TFS PowerTools

Über die API mit der man selber Anwendungen für den Team Foundation Server schreiben kann, habe ich ja schon mehrfach berichtet. Nun soll das SDK verbessert werden, was offen gestanden, auch mal Zeit wird. Brian Harry hat ein erstes Sample bereits vorab veröffentlicht, das zeigt, wie man mit der API auf die Version Control zugreift.

bharry's WebLog : Working on TFS SDK improvements

Um TFS-Workitems massenhaft zu bearbeiten, z.B. um mehrere Workitems einem neuem Bearbeiter zuzuweisen, gibt es verschiedene Möglichkeiten. Die bekannteste davon ist sicher die Bearbeitung in Excel. Richard Hundhausen beschreibt noch einige weitere in einem Video

http://msdn.microsoft.com/en-us/vsts2008/cc563930.aspx

Jeder kenn die Situation. Wenn man einen Fehler oder eine Änderung beschreiben will, tipp man sich einen Wolf. Viel schneller geht es mit einem Screenshot. Wer allerdings, z.B. beim Testen zig Screenshots an Workitems im Team Foundation Server anhängen möchte, der ist auch schnell genervt. Immer der gleiche Prozess. Schreenshot aufnehmen - In das Bildverarbeitungsprogramm wechseln - Screenshot einfügen - Screenshot speichern - Neues Workitem anlegen udn Felder ausfüllen - Attach File aufrufen - Datei mit Screenshot suchen - Fertig!

Glücklich derjenige, der den artiso Workitem Manger nutzt. Da geht das Ganze viel einfacher.

1.) Das Tray Icon Symbol mit der rechten Maustaste anklicken und auswählen ob man ein neues Workitem anlegen möchte oder an das gerade geöffnete den Screenshot anhängen möchte.

2.) Geünschten Bildbereich auswählen und Screenshot aufnehmen (Klick auf den Button im Zentrum des Fensters oder Enter drücken)

3.) Schon ist das Workitem inkl. Attachment angelegt.

Wer das Ganze mal testen möchte, kann sich hier eine Demo-Version des Workitem Managers herunterladen.

Die Workitems aus dem Team Foundation Server können direkt nach Excel geladen, dort bearbeitet und wieder auf den TFS gepublished werden. Das hierzu erforderliche Add-In wird bei der Installation des Team Explorers automatisch mitinstalliert und funktioniert sehr gut. Ein wenig nervig ist allerdings, wenn man zu einem Workitem weitere Informationen sehen oder eintragen möchte und die entsprechende Spalte nicht angezeigt wird. Dann muss man die Spalte erst zur Anzeige auswählen und die Liste aktualisieren. Darüber hinaus wird die Darstellung in Excel schnell unübersichtlich, wenn man viele Felder anzeigen lässt.

Wäre es nicht schön, wenn man auch in Excel den gewohnten Detail-Dialog zu einem Workitem hätte? Genau diese Funktion bietet das kostenfreie Tool Ekobit TeamCompanion for Excel. Das Workitem kann editiert und gespeichert werden. Die selbe Funktion gibt es übrigens auch für MS Project.

TeamCompanion for Excel

TeamCompanion for Project

Auf MSDN ist nun ein Artikel erschienen den ich zusammen mit Christian Binder für das dot.net Magazin geschrieben habe. Der Artikel beschreibt, wie man mit Hilfe der TFS-API eine hierarchische Organisation von Workitems selbst erstellt. Der Artikel ist auf MSDN frei zum Download.

http://download.microsoft.com/download/4/7/a/47aca5b1-ad88-4248-949b-d0333d238516/DM_0608_Schissler_Binder.pdf

In der Versionsverwaltung des Team Foundation Servers spielt Branching eine wichtige Rolle. Dabei kann man ausgehend von einem bestehenden Branch eine "Kopie" erzeugen, dort Änderungen machen und diese dann in den Ursprungsbranch zurückmergen. Leider unterstützt die UI (Sorce Control Explorer im Visual Studio) nur das mergen in den Ursprungsbrachn aus dem heraus dieser Branch abgezweigt wurde. Merging in andere Branches bezeichnet man als "Baseless Merges". Wie das geht beschreibt der TFS-Guide in einem HowTo.

patterns & practices: Team Development with Visual Studio Team Foundation Server - Home

Ein Dokument auf das ich immer verweise, wenn es um die Installation des Team Foundation Servers geht ist der TFS2008 Installation Guide. Deshalb hier mal der Link für alle, die einen TFS aufsetzen wollen. Leider funktioniert das mit CD rein und Setup aufrufen nicht. Aber wenn man die Installationsanweisung befolgt, geht's meisten problemlos. Ansonsten einfach mich anmailen, ich versuche dann gerne weiterzuhelfen.

Download details: Team Foundation Installation Guide

Für die Sorce Analysis, eine statische Codeanalyse gibt es jetzt von Eugene Zakhareyev eine Checkin Policy mit der beim Einchecken in die Teamfoundation Server Source control die Erfüllung der definierten Richtlinien abgeprüft werden kann.

Danke an Mark für den Tipp.

Team Foundation Server observations bucket: Source Analysis For C# Checkin Policy

Es gibt eine ganz Reihe von Whitepapers, die verschiedene Practices aus dem Bereich ALM und deren Umsetzung mit VSTS beschreiben.

• Communicate and Collaborate
• Drive Predictability
• Ensure Quality Early and Often
• Integrate Work Frequently
• Making Real-Time Decisions
• Managing Team Workflow
• Using Familiar Tools

Visual Studio Team System 2008 Capabilities White Papers

Microsoft ist ja ein Meister darin, das Thema Lizenzierung zu einer WIssenschaft zu machen und inzwischen gibt es wohl Leute, die ihr Geld damit verdienen, Firmen durch den Lizenz-Dschungel von MS zu führen. Für alle, die Fragen bezgl. der Lizenzierung von Visual Studio Team System 2008 haben, sei dieses Dokument empfohlen. Fragen dazu aber bitte nicht an mich

Download details: Visual Studio Team System Licensing

Alex beschreibt in seinem Artiekel eine sehr elegante Möglichkeit, wie man vermeiden kann, dass bei Continous Integration Checkins durch den Build einen erneuten Build auslösen.

Team Foundation Server 2008 mit AssemblyVersion Task - rekursive Builds vermeiden

Die Videos zu den Sessions vom Launch-Event in Frankfurt im Februar sind jetzt für alle frei verfügbar.

Ich hatte ja die Möglichkeit, am Ende einer Session von Christian Binder kurz vorzustellen, wie wir den TFS in unserem Entwicklungsprozess nutzen.

Das Video kann man hier abrufen. Mein Einsatz beginnt dann ab der Minute 54. Mein Video, das ich in dem Vortrag nutze, kann hier heruntergeladen werden.
War echt ne coole Sache vor mehr als 500 Leuten zu reden.

Visual Studio 2008 Team System 2008 - {Überblick}

Beim Checkin in den TFS können beim Checkin Workitems verknüpft werden. Hier können standardäßig zwei verschiedene Chck-In Actions ausgewählt werden. Associate verknüpft den Checkin nur mit dem Workitem währen Resolve das Workitem auf geschlossen setzt. Vor allem wenn man Workuiems mit größerem Umfang plant, kann es vorkommen, dass man als Default-Einstellung Associate haben möchte statt Resolve. Leider funktioniert das nicht so. Einen Workaround stellt Martin Woodward vor. Mit seiner Methode wird Resolved einfach aus den Check-In Actions entfernt und damit Associate automatisch als Default-Wert verwendet. Der Nachteil bei dieser Lösung: Man muss die Workitems außerhalb des Checkin-Prozesses auf Resolved setzen. Das ist nicht besonders schön, aber momentan leider die einzige Möglichkeit das Standard-Verhalten zu ändern.

Martin Woodward: TFS Top Tip #3: Removing the Resolve Check-In Action from a Work Item

Auch wenn das unter dem Gesichtspunkt Traceability äußerst problematisch ist, gibt es im TFS 2008 die Möglichkeit Workitems zu löschen - ein Feature das oftmals gefordert wurde. Dazu benötigt man die TFS Powertools. Danach kann man mit folgendem Befehl ein Workitem löschen:

tfpt destroywi /server:sartfsx01 /workitemID:8719

In Kürze wird wohl das SP1 zum Team Foundation Server als Beta veröffentlich. Brian Harry beschreibt schon mal ein paar Fetures auf di wir uns freuen dürfen.

bharry's WebLog : Team Foundation Server 2008 SP1 Preview

Mit dem Team Foundation Server Power Tools March 2008 gibt es ein cooles Features, Workitem Templates. Haben Sie sich nicht schon mal geärgert, dass Sie beim Anlegen eines Bugs immer den Namen des gleichen Entwicklers eingeben müssen oder dass sie immer die aktuelle Iteration auswählen müssen? Genau hier helfen Workitem-Templates weiter. Und das geht so:

Nach der Installation der Power Tools gibt es im Team Explorer eine neuen Knoten "Work Item Templates". Hier können neue Templates angelegt werden.

Für jeden Workitem-Typ können beliebig viele Templates angelegt werden. Hier können nun die gewünschten Felder vorbelegt werden.

Auf Basis dieses Templates kann nun ein neues Workitem erstellt werden (Rechter Mausklick auf das Template) oder auf ein bestehendes Template angewandt werden.

Weitere Informationen finden sich in der

Zusammen mit meinem Kollegen Mark werde ich am 22.04.08 bei der UG München den Vortrag zum Thema Qualitätsmanagement mit VSTS nachholen.

Thema des Vortrags:

Dass Qualitätsmanagement heute ein fester Bestandteil eines modernen Entwicklungsprozesses sein sollte, ist inzwischen - zumindest in der Theorie – keine Frage mehr. Die Wirklichkeit ist aber leider immer noch sehr häufig eine andere. Woran liegt das? Terminstress, sich ändernde Anforderungen im Projektverlauf und in vielen Fällen ein erheblicher bürokratischer Overhead bei der Ausführung von QM vereitelt erfolgreich, die definierten Maßnahmen auch zu leben.
Die Test-Tools von Visual Studio hat wohl schon fast jeder einmal gesehen, evtl. auch genutzt. Entscheidend beim Einsatz dieser Tools ist aber die Integration in den Gesamtprozess. So besteht ein erfolgreiches QM nicht nur aus Tests, sondern auch Requirementmanagement, Releasemanagement, Testability und andere Aspekte spielen hierbei eine wichtige Rolle. Die Kunst besteht darin, diese verschiedenen Aspekte über den Gesamtprozess miteinander zu verbinden. Wie dieses Ziel mit VSTS und TFS erreicht werden kann, zeigt der Vortrag.
Die ideale Zielgruppe für diesen Vortrag sind: Entwickler, Qualitätsmanager, Testexperten und IT-Entscheider mit der Bereitschaft, sich auch das ein oder andere Prozessdetail live anzusehen.

Weitere Details finden sich hier

Mit der Versionsverwaltung im Team Foundation Server kann man ja bekannter maßen nicht nur Code verwalten, sondern auch andere Dateien wie z.B. SQL-Skripte, Dokumentationen etc. Hierzu ist es sinnvoll, entsprechende Ordner anzulegen. Doch das will manchmal nicht recht gelingen. Will man unterhalb dem Root eines Projektes einen neuen Ordner anlegen, kann es vorkommen, dass der Button dazu disabled ist.

Der Grund dafür ist einfach (wenn man's weiß). Ein Blick in den Workspace verdeutlicht das Problem.

Hier sieht man, dass im Workspace ein Mapping für den Unterordner "Benutzerverwaltung" eingerichtet ist. Da die Versionsverwaltung alle Operationen, also auch das Anlegen eines neuen Ordners aber auf dem lokalen Pfad ausführen muss, tritt hier ein Problem auf. Die Anwendung weiß nicht, wo sie den Ordner lokal anlegen soll. Abhilfe schafft hier, wenn man das Mapping auf der Projkektebene einstellt, also so:

Alternativ kann man natürlich auch ein separates Mapping für den Root-Ordner des Projektes einrichten. Jetzt kann der Ordner lokal einem gültigen Pfad zugeordnet werden und der Button ist auch wieder enabled.

Es gibt eine aktualisierte Dokumentation für die API zum Team Build hier zum Download:

http://download.microsoft.com/download/5/f/8/5f872c2e-4221-410b-b86e-4c3cd831b0c4/Team Foundation Build Managed Reference.chm

Achtung die Datei muss auf der lokalen Platte gespeichert und dann über rechte Maustaste / Properties mit Hilfe des Unblock-Buttons entsperrt werden bevor sie korrekt angezeigt wird.

Wer sich nicht vom Ende der Trail-Laufzeit seines TFS überraschen lassen möchte, kann ein kleines Tool verwenden. Damit kann man sich anzeigen lassen, wie lange der TFS noch laufen wird. Außerdem kann man wenn die Laufzeit nicht mehr als 10 Tage beträgt, diese auch noch einmalig um 30 Tage verlängern kann. Für eine zweiter Verlängerung braucht man eine neue Trail ID, die man bei Microsoft anfordern muss. Das Tool gibt es auch für TFS 2005 wobei ich mir kaum vorstellen kann, das heute noch jemand den TFS 2005 evaluiert.

TFSVersionDetection.zip

Weitere Informationen bei Brian Harry

Nachdem wir immer mehr Anfragen bezgl. unseres artsio WorkitemManager und x64 Systemen erhalten haben, haben wir hier in den letzten Tagen mal versucht, die TFS API unter Vista x64 zum Laufen zu bekommen und ich möchte das hier auch mal posten. Das Problem stellt sich in der Entwicklungsumgebung folgendermaßen dar. Direkt nach dem Start der Anwendung bekommt man folgenden Fehler:

Die Assembly ist natürlich da. Die Lösung dafür ist sehr einfach. Man muss dem Projekt lediglich sagen, dass es eine x86 Anwendung ist. Dann wird es unter x64 als x86 Anwendung ausgeführt und kann damit auch die TFS API verwenden. Dazu muss man lediglich in den Eigenschaften des Projektes als Plattform explizit x86 auswählen.

Nach unseren bisherigen Tests scheint damit die API auch auf x64 Systemen problemlos zu funktionieren.

Die Tatasache, dass sich Visual Studio Team System inzwischen zu einem Produkt mit einer enormen Funktionsvielfalt entwickelt hat, wird schon alleine dadurch dokumentiert, dass es vom 22.04 bis 24.04 eine Konferenz gibt, die sich nur mit diesem Produkt beschäftigt. Die Vorträge decken dabei einen großen Bereich von Projektmanagement über Qualitätsmanagement bis hin zu Best Practices und Erfahrungsberichte ab. Ich selbst werde auch mit einem Vortrag zum Thema hierarchische Workitems vertreten sein.

Wer schon mal einen Blick in die Zukunft werfen möchte, dem sei der Vortrag von Christian Binder zum Thema Rosario ans Herz gelegt.

Würde mich freuen, den einen oder anderen Leser meines Blogs auf der TeamConf persönlich kennen zu lernen. Wer auch dort ist, kann mir einfach einen Kommentar hinterlassen.

Leider ist die TFS SDK Dokumentation im VS2008 SDK "verschwunden". Diese kann nun endlich wieder heruntergeladen werden.

http://msdn2.microsoft.com/en-us/library/bb130146.aspx. 

In diesem White Paper werden verschiedene Konzepte für das Requirement Management mit Visual Studio und einigen 3rd Party Tools beschrieben. Leider fehlt bei den 3rd Party Tools unser artiso WorkitemManager

http://www.microsoft.com/downloads/details.aspx?FamilyId=EEF7BB41-C686-4C9F-990B-F78ACE01C191&displaylang=en#filelist

Die Frage "Wie lösche ich ein Team Projekt von meinem Team Foundation Server?" taucht immer wieder auf. Deshalb hier ein paar Infos dazu:

1.) Im Sourcecontrolexplorer kann man nur Dateien aus der Quellcodeverwaltung löschen
2.) Auch mit dem Commandozeilentool tf delete werden nur Quellcode-Dateien gelöscht.
3.) Zum Löschen eines kompletten Team-Projekts verwendet man das Commandozeilentool
       TfsDeleteProject /server:myteamserver “My Project“

Beim Betrieb des TFS gibt es hin und wieder Probleme mit dem lokalen Cahce. Vor allem wenn man mit mehreren Servern arbeitet, kommt es da immer wieder mal zu Problemen. Diese lassen sich durch Löschen des Caches lösen.Für mich selbst zur Erinnerung hier nochmals die Pfade:

Um SQL-Projekte aus dem Management-Studio mit der Versionsverwaltung des Team Foundation Server zu verwalten gibt es einen recht einfachen Weg. Zunächst muss der MSSCCI-Provider installiert werden. Dann geht man im Management-Studio unter Tools / Options auf Source_Control und prüft, ob der richtige Provider eingestellt ist.

Dann kann man seine Management-Studio Projekte einfach in die Quellcode-Verwaltung einfügen, wie man das aus Visual Studio gewohnt ist. Also einfach rechte Maustaste auf die Solution und Add Solution to Source Control.

Nach der Auswahl des Servers und erfolgter Anmeldung wählt man den Ordner in der Versionsverwaltung aus.

Und schon kann man seine SQL-Scripts in der Versionsverwaltung auschecken, einchecken etc.

Ich bin gerade von der BASTA! Spring zurückgekehrt. Ich hatte dort 2 Vorträge.

Der absolute Oberknüller war mein erster Vortrag:

Beginn: 17:30 Uhr
Thema: Qualitätsmanagement mit VSTS

ich hatte mich eigentlich schon darauf eingestellt, in einer kleinen überschaubaren Runde das Thema mit zwei Leuten zu diskutieren, die sich eigentlich nur verlaufen haben oder in den anderen Sessions keinen Platz mehr bekommen haben. Aber was soll ich sagen. Die Bude war voll! Den Vortrag haben sich ca. 50 Leute angehört und keiner ist vorzeitig gegangen oder eingeschlafen (glaube ich mal). Ich habe dann in dem Vortrag versucht, das Tooling aus dem VSTS, das bereits einige Speaker vor mir vorgestellt haben, in einen Prozess einzubinden, damit am Ende möglichst viel Qualität rauskommen. Danke für das große Interesse.

Hier noch meine Folien zu dem Vortrag:

Die zweite Session war zum Thema Programmierung mit dem TFS SDK.

Zu diesem Vortrag gibt es die Folien, das Demo  und auch noch das Video, das ich ganz am Anfang gezeigt habe.

Das TFS DataWarehouse wird standardmäßig jede Stunde aktualisiert. Das kann oft zu lange sein, gerade wenn man Reports neu anlegt. Will man nicht bis zur nächsten automatischen Aktualisierung warten, kann man das auch manuell anstarten. Hierzu ruft man die folgende URL auf dem TFS Application Tier auf:

http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx?op=Run

Dann einfach auf Invoke klicken uns schon startet der Aktualisierungs-Prozess

Das Veröffentlichen von Test Results auf dem TFS-Server ist eine schöne Sache, die vor allem die Kommunikation zwischen Tester und Entwickler erleichtert Aber damit gibt es immer wieder Probleme. Ich hatte gerade so einen Fall und möchte den hier kurz beschreiben, vielleicht kann jemand anderer sich damit Zeit sparen.

Nach dem Publish erhielt ich immer die Meldung "The test result share \\notebook_thomas\builds\WVBuild_20080226.3\TestResults\41577b87-2935-473c-bf03-423c777cd030 is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. Failed to upload test run results to the drop location '\\notebook_thomas\builds'. Ask your server administrator to make the drop location available."

Das Problem liegt, wie sich aus der Fehlermeldung vermuten lässt, in den Berechtigungen. Ich hatte als Szenario den Build-Agent auf dem selben Rechner eingerichtet, auf dem ich auch entwickle. Wichtig sind hier zwei Dinge:

1. Es müssen die Berechtigungen auf dem Verzeichnis und auf dem Build Share eingerichtet sein.
2. Es müssen Berechtigungen für den lokalen User eingerichtet sein.

Bei mir war Punkt 2 das Problem. Ich hatte für den lokalen Benutzer, mit dem ich im Visual Studio arbeite, keine Berechtigungen auf dem Share, deshalb diese Meldung. Nachdem ich diese Berechtigung eingetragen habe, funktionierte es ohne Probleme.

In den letzten Tagen wurde ich häufiger gefragt, welche Edition von Visual Studio man benötigt, um mit dem Team Foundation Server zu arbeiten. Viele sind irrtümlicherweise der Meinung, dass der TFS nur mit dem VSTS zusammenarbeitet, aber das stimmt glücklicherweise nicht. Bereits ab der Standard-Edition wird der Team-Explorer in Visual Studio integriert und man hat Zugriff auf die Quellcode-Verwaltung und Workitems, wie man das auch aus dem VSTS zusammen mit dem TFS gewohnt ist. Da der Team-Explorer sich ja auch als Standalone installieren lässt, wäre theoretisch auch ein Arbeiten mit der Express-Edition möglich, aber das ist natürlich nicht mehr sehr komfortabel.

Ich würde aber auf jeden Fall dei Professional-Edition von Visual Studio 2008 empfehlen, da diese nun auch Unit-Tests unterstützt und für einen normalen Entwickler damit eigentlich ausreichend sein sollte.

Brian Harry beschreibt in diesem Beitrag verschiedene Upgrade-Szenarien, so z.B. auch wie eine Workgroup-Edition auf eine Full Version upgegraded (furchtbar diese Entwickler, können einfach kein Deutsch, hat jemand dafür eine Übersetzung?) werden kann.

Danke an Lars für den Link

bharry's WebLog : How do I upgrade to TFS 2008?

Wir nutzen in unserem Entwicklungsprozess seit einiger Zeit den Team Foundation Server. Für das Requirement Management setzen wir Workitems ein. In der aktuellen Version des Team Foundation Servers fehlte uns dabei bisher allerdings die Möglichkeit, Workitems hierarchisch zu organisieren. Glücklicherweise verfügt der Team Foundation Server über ein leistungsfähiges API (siehe auch meinen MSDN-Webcast zu diesem Thema). Auf Basis dieser API haben wir ein Tool, den artiso Workitem Manager, entwickelt, mit dem wir nun Workitems so strukturieren können, wie wir das in unseren Projekten brauchen. Neben der hierarchischen Struktur können auch Iterationen in Baumstrukturen abgebildet werden.

Ebenfalls Bestandteil des artiso Workitem Manger ist ein Word-AddIn mit der Spezifikationsdokumente auf Funktionsebene verwaltet werden können. Damit lassen sich verschiedene Probleme mit Spezifikationsdokumente als monolithische Worddokumente lösen.

Den artiso Workitem Manager kann als Beta-Version kostenlos heruntergeladen werden. Die frei verfügbare Version ist auf 50 Workitems begrenzt.

Weitere Informationen finden sich hier.

Gemeinsam mit Christian Binder von Microsoft habe ich einen Webcast zum Thema Team Foundation Server SDK aufgenommen.

Thema des Webcasts:

Leider unterstützt der Team Foundation Server 2008 keine hierarchischen Workitems. Dies lässt sich mit Hilfe des TFS SDKs jedoch einfach selbst erweitern. Der Webcast vermittelt zunächst die Grundlagen zur Programmierung mit dem SDK. Im zweiten Teil wird dann gezeigt, wie das SDK genutzt werden kann, um einen hierarchischen Workitem-Manager zu erstellen.

Diese hierarchische Organisation der Workitems bietet bei der kompletten Projektorganisation enorme Vorteile. So lassen sich damit komplette Funktionsbäume aufbauen. Ich werde in Kürze hier noch verschiedene Vorgehensweisen bloggen, die auf hierarchischen Workitems basieren. Vorab hier schon ein paar begleitende Informationen zum Webcast.

Der Webcast kann hier heruntergeladen werden.

Das fertige Projekt aus dem Webcast kann hier als Solution heruntergeladen werden

Und hier habe ich noch ein Dokument, das den Aufbau der Anwendung Schritt für Schritt erläutert.

Danke noch an Chris, hat echt Spass gemacht.

Des TFS SDK enthält ein Control um Workitems in Winforms zu bearbeiten. Dieses Control löst damit das Problem, wie die hochflexible Struktur von Workitems in einer eigenen Anwendung dargestellt und bearbeitet werden kann. Mit dem neuen TFS SDK 2008 gibt es allerdings ein kleines Problem beim Einsatz des Controls. Wird das Control in eine Winform eingebaut, kommt es zu einer NullReferenceException.

Object reference not set to an instance of an object.

Dieses Problem konnte ich bei mir umgehen, indem ich nicht die DLL aus dem SDK sondern aus dem TeamExplorer. Ich habe die beiden DLLS, die ich hier ausgetauscht habe hier zum Download bereitgestellt.

Über die TFS-API kann der Namen eines TFS-Servers einfach abgefragt werden. Dazu kann folgender Code verwendet werden:

private TeamFoundationServer tfs;
NetworkCredential account = new NetworkCredential(user, password);
tfs = new TeamFoundationServer(server, account);
string ServerName = tfs.Name;

Dabei habe ich allerdings folgendes Problem festgestellt: Der Servername ist nicht konsistent. Ist der Server im Team-Explorer noch nicht geristriert, enthält der Servername auch den Port. Nachdem der Server im Team-Explorer dann registriert wurde, wird nur noch der Server-Name zurückgegeben. Das sollte man auf jeden Fall berücksichtigen, wenn man mit dem Name-Property vom tfs arbeitet.

Eine schöne Liste mit Tools und Erweiterungen zum Team Foundation Server und Visual Studio Team System findet sich unter http://widgets.accentient.com/

TFS-Widgets

Aus dem Fenster mit Fehlermeldungen und Wahrnungen im Visual Studio heraus kann man direkt Workitems auf dem Team Foundation Server anlegen. Dazu einfach die entsprechende Zeile mit der rechten Maustaste anklicken und im Kontextmenü "Create Work Item" wählen.

Es werden automatisch Informationen in den Titel und den Verlauf übernommen, wobei meiner Meinung nach die Details eher in das Beschreibungs-Feld gehören als in den Verlauf.

Der Visual Studio 2008 Team Explorer kann unabhängig vom Team Foundation Server mit folgendem Link heruntergeladen werden.

Download details: Visual Studio Team System 2008 Team Explorer

Im TFS 2008 hat Microsoft endlich die Lizenzbedingungen angepasst. Für folgende Aktionen wird nun keine CAL mehr benötigt:

• Anlegen eines Workitems
• Anzeigen der Workitems, die ein Benutzer selbst angelegt hat
• Bearbeiten der Workitems außer Änderung des Status des Workitems

Damit ist es nun endlich möglich, Kunden etc. in das Projekt besser einzubinden, ohne dafür Unsummen für CALs auszugeben.

adamga's WebLog : TFS for Defect Tracking! Licensing Change!!!

Der Team Foundation Server ist ein sehr flexibles Werkzeug. Es lässt sich an verschiedene Prozessmodelle anpassen. Die die beiden folgenden Links verweisen zu entsprechenden Kapiteln in der MSDN-Hilfe die beschreiben wie Workitem Typen und Prozessvorlagen angepasst werden können.

Customizing Work Item Types
Customizing Process Templates

Der Team Foundation Server Guide liegt nun in der finalen Version vor. Dieses Dokument beschreibt viele gängige Szenarien in Zusammenhang mit dem TFS und bietet empfohlene Lösungen an. 

patterns & practices: Team Development with Visual Studio Team Foundation Server - View Release

Wenn man eine Datei löscht, die in der Quellcode-Verwaltung eingecheckt war, kann man diese leicht aus der Quellcode-Verwaltung wiederherstellen. Dazu muss man aber zuerst eine kleine Einstellung vornehmen. Unter Tools / Options / Source Control / Visual Studio Team Foundation Server kann man die Option "Show deleted items in the Source Control Explorer" aktivieren.

Dann werden im Source Control Explorer gelöschte Elemente angezeugt, die man einfach "undeleten" kann.

Die Arbeitsbereiche des Team Foundation Server stellen eine Verknüpfung eines lokalen Verzeichnisses mit einem Pfad in der Quellcode-Verwaltung her. Aus verständlichen Gründen kann ein und das selbe Verzeichnis nicht mehrfach zugeordnet werden. Dies gilt insbesondere für den Fall, dass zwei verschiedene Benutzer auf dem gleichen Rechner das selbe Verzeichnis zuordnen wollen, auch wenn es sich auf den gleichen Pfad in der Quellcode-Verwaltung bezieht. Das ganze macht Sinn. Aber was tun, wenn z.B. der Benutzer A nicht mehr existiert und nun Benutzer B seine Projekte übernehmen soll? Der Rat lautet hier, von Benutzer A alle Arbeitsbereiche löschen, bevor der Benutzer gelöscht wird. Der Rat hilft aber wenig, wenn der Benutzer bereits gelöscht wurde und man dann erst die Probleme feststellt. Oder wenn, wie in meinem Fall, durch einen Umzug auf einen anderen Server der Benutzer neu angelegt wurde und zwar den gleichen Namen hat, aber eine andere SID. Die Anpassung der SIDs in der TFS-Datenbank scheint hier nicht richtig funktioniert zu haben.

Den lokalen Workspace zu löschen ist kein Problem, aber das hilft leider in diesem Fall nicht. Die Arbeitsbereiche sind auch zusätzlich noch auf dem Server gespeichert und dort muss man diesen nun löschen, damit man den mit dem neuen Benutzer neu einrichten kann.

Zunächst der Befehl, mit dem man die Workspaces vom Server anzeigen kann:

tf workspaces /owner:* /server:<TFS-Servername> /format:detailed

Um einen Workspace zu löschen kann nun folgender Befehl verwendet werden:

tf workspace /delete <Workspace-Name>;<Benutzername>  /server:<TFS-Servername>

Es gibt auch noch den Befehl /updateUserName, der hat in meinem Fall aber leider nicht funktioniert.

Visual Studio 2008 TFS (ehemals Orcas TFS) wird WSS 3.0 von Haus aus unterstützen.  Möchte man die WSS 3.0 auch mit einem Visual Studio 2005 TFS einsetzen, dann hilft diese Anleitung:

TN1501: Configuring Windows SharePoint Services 3.0 on the Visual Studio 2005 Team Foundation Server Application Tier

Wenn der Team-Explorer behauptet, einen nicht mehr zu kennen und mit folgender Meldung behauptet, man stellt keine bekannte Identität dar,

dann kann dieses Problem behoben werden, indem man den Cache des Team-Explorers löscht. Dieser liegt unter Vista im Ordner C:\Users\Thomas\AppData\Local\Microsoft\Team Foundation\1.0\Cache. Hier einfach alle Unterordner löschen und schon klappts wieder mit dem TFS.

Auf Codeplex gibt es einen Guidance zu Visual Studio 2005 Team System, der verschiedene Vorgehensweisen mit VSTS beschreibt. Themen sind u.a:

• How To: Structure Your Windows Applications for Team Foundation Server
• How To: Structure Your Source Control Folders in Team Foundation Server 
• How To: Structure Your ASP.NET Applications for Team Foundation Server
• Explained - Structuring Your Solutions and Projects in Source Control with Team Foundation Server
• Explained: Branching in Team Foundation Server
• How to automate common version control tasks
• How to plan your branching structure
• How to use branching to support a release
• How to use branching to maintain a previous release
• How to use branching to stabilize your development and build process
• How to use branching to stabilize feature development
• How to use branching to stabilize development across teams
• How to use branching to isolate external dependencies
• How to use TFS to perform continuous integration builds
• How to choose one team project vs multiple team projects
• How to organize your source tree
• How to define workspace mappings
• How to use workspaces to isolate code changes on your machine

und vieles anderes mehr!

Link to patterns & practices: Visual Studio 2005 Team System Guidance

Möchte man die Process Guidance des Team Foundation Server in Papierform verfügbar machen, kann folgendes Tool sehr hilfreich sein. Damit kann die Process Guidance als ein einzelnes HTML-Dokument konvertiert werden.

http://staff.southworks.net/blogs/mariano/archive/2006/01/28/206.aspx  

Die Workitems von Team System lassen sich ja einfach in Excel abfragen und bearbeiten. Jedoch war ich mit den angeboteten Spalten nicht zufrieden. Man kann zwar über einen entsprechenden Button noch beliebige weitere Spalten abrufen, das aber jedesmal zu tun war dann doch ein wenig nervig. Nach einigem Suchen habe ich dann die Lösung gefunden. Man muss sich einfach eine eigene Query anlegen und dort die gewünschten Spalten definieren. Wenn man nun über diese Query die Workitems in Excel abfragt, kommen genau die Spalten, die in der Query definiert sind.

Team Foundation Sidekicks ist eine Sammlung von Tools, die verschiedene Aufgaben bei Nutzung und Verwaltung von Team Foundation Server erleichtern. Unter anderem wird eine vereinfachte Verwaltung von Labels angeboten:

Link to Team Foundation Sidekicks

Dieser Artikel beschreibt wie man über ein Add-In Funktionen für den Team Build und die Quellcode-Verwaltung programmieren kann.

Link to Attrice Corporation Team Foundation Sidekicks

Mit diesem Tool kann man WorkItems von einem Team Projekt in ein anderes verschieben.

Link to Team Foundation Server Work Item Utility: Home

Lars Keller berichtet über das Tool IEeee, das es ermöglicht, direkt aus dem IE einen Fehlerbericht mit detailierten Informationen als WorkItem im Team System Server anzulegen. Das Tool dürfte vor allem für Tester sehr interesant sein.

Link to IEeee: Home

Scrum for Team System ist ein kostenloses add-in für Visual Studio Team System, das agile Entwicklungsmethoden nach Scrum unterstützt. 

Link to Scrum for Team System

WorkItems für den Team Foundation Server lassen sich einfach per Code erstellen.

Es gibt einen Connector, der den Team Foundation Server mit einem MS-Project Server verbindet.

Link to bharry's WebLog : New TFS - Project Server Connector available

Für Team System lassen sich auch eigene Check-In Policies erstellen. Der folgende Artikel zeigt an einem Beispiel, wie das geht. 

Link to Team System : Adding a new check-in policy

Mit ein paar kleinen Tricks kann man auch offline mit dem TSSC arbeiten.

http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/03/2984.aspx

Wird eine Datei aus der TeamSystem SourceControl ausgecheckt, wird von dieser datei nicht automatisch die letzte Version gehohlt wie man das von VSS gewohnt ist. Der Grund dafür ist, dass dadurch evtl. ein inkonsistenter Zustand der Anwendung entstehen könnte, da die ausgecheckte Datei in einer neueren Version vorliegt, die nicht mit den restlichen dateien des Projekts kompatibel ist.

Weitere Ausführungen unter: http://blogs.vertigosoftware.com/teamsystem/archive/2006/05/15/2755.aspx

Um die Work Items aller Team-Projekte eines Team-Servers anzeigen zu können, kann man einfach eine entsprechende Query anlegen. Hierzu einfach im Team-Explorer auf Work Items mit der rechten Maustaste klicken und dann "Add Query" auswählen. Die Query is dann schon mit einem Filter nach einem Projekt vorbelegt. Diesen einfach löschen, dann erscheinen alle Work Items.

Teil 1 : http://www.theserverside.net/tt/articles/showarticle.tss?id=UnitTest
Teil 2 : http://www.theserverside.net/tt/articles/showarticle.tss?id=UnitTest2
Teil 3 : http://www.theserverside.net/tt/articles/showarticle.tss?id=UnitTest3

Unter http://www.microsoft.com/germany/msdn/webcasts/serien/MSDNWCS-0605-01.mspx gibt es eine Webcast-Serie zu Visual Studio Team System

Mit dem Team Foundation Server Administration Tool können im Team Foundation Server benutzer und Berechtigungen verwaltet werden.

http://www.codeplex.com/Wiki/View.aspx?ProjectName=TFSAdmin

Unter folgender Adresse gibt es eine große Anzahl von Artikeln, Webcasts etc zum Thema Team System

http://www.microsoft.com/germany/msdn/vstudio/teamsystem/expand/default.mspx

Unter der folgenden Adresse gibt es zahlreiche nützliche Links rund um das Thema Team System Server

http://www.dotnet-online.de/web/teamsystem/default.aspx

http://thesource.ofallevil.com/germany/msdn/webcasts/library.aspx?id=118771504

Projekte aus Visual Source Safe 2005 können mit Hilfe eines Konverters nach Team Foundation Server migriert werden. Dabei bleibt die Historie komplett erhalten. Eine Migration von Visual Source Safe 6.0 nach VSS 2005 kann über Backup / Restore erfolgen.

http://msdn2.microsoft.com/en-us/library/ms253060.aspx