Apr 282015
 

In den TFS Schulungen kam häufiger die Frage wie man ermitteln kann welche User einen Local oder Server Workspace verwenden. Seit TFS 2012 kann man pro Team Project Collection bestimmen ob die Benutzer standardmäßig einen Server oder Local Workspace anlegen. (Siehe https://msdn.microsoft.com/en-us/library/bb892960.aspx) Dies hindert jedoch niemanden selbst zu entscheiden welchen Workspace Typ man nutzen will. Jeder kann per Option in Visual Studio über „Manage Workspaces“->“Edit“->“Advanced“ selbst entscheiden welche Variante er bevorzugt.

Möchte man herausfinden welche Benutzer welchen Typ verwenden hilft ein wenig .NET Code:

  1. class Program
  2. {
  3.     static void Main(string[] args)
  4.     {
  5.         var teamProjectPicker = new TeamProjectPicker(TeamProjectPickerMode.NoProject, false);
  6.         teamProjectPicker.ShowDialog();
  7.         var teamProjectCollection = teamProjectPicker.SelectedTeamProjectCollection;
  8.         var versionControlService = teamProjectCollection.GetService<VersionControlServer>();
  9.         var workspaces = versionControlService.QueryWorkspaces(null, null, null);
  10.         foreach (var workspace in workspaces)
  11.             Console.WriteLine(„Workspace: {0}nComputer: {1}nOwner: {2}nLocation: {3}nn“,
  12.                 workspace.Name, workspace.Computer, workspace.OwnerDisplayName, workspace.Location);
  13.         Console.ReadKey();
  14.     }
  15. }

Nach der Verbindung zu einer Team Project Collection, werden von dieser alle Workspaces geholt. Danach erfolgt lediglich die Ausgabe von Workspace Name, Computer Name, Benutzer und eben der Location (Server / Local) auf der Console.

Das Beispiel gibt es auch hier zum Download.

Apr 282015
 

Fehler TF900548

In meiner TFS Schulungsumgebung hatte ich schon paar Mal den Fehler das der Build Prozess anscheinend die Testresults nicht veröffentlichen konnte. Bisher war es an der Stelle ausreichend den Cache Folder auf dem Build Server zu löschen:

Beispiel:
C:\Users\TFSBuild\AppData\Local\Microsoft\Team Foundation\5.0

Wenn der Ordner noch im Zugriff ist kann man kurz den Build Service in der Administration Console stoppen und anschließend wieder starten. Ich gehe davon aus das die Ursache war das ich den TFS auf einen Snapshot zurück gesetzt habe, den Build Server jedoch nicht. Somit waren hier noch alte Daten im Cache.

Sep 222014
 

In den letzten Visual Studio Versionen hat sich das Automerge Verhalten beim „Get Latest“ oder „Unshelve“ im TFS um einiges verbessert. Häufig bekommt man das ganze gar nicht mehr mit wenn Visual Studio die Änderungen automatisch mergen kann. Da hilft nur ein Blick ins Output Window. Dort tauchen entsprechende Meldungen auf das gerade Dateien zusammengeführt wurden. Möchte man lieber aktiv informiert werden auch wenn Visual Studio denkt die Änderungen zusammen zu mergen kann man das entsprechend in den Visual Studio Optionen konfigurieren. An der Option „Attempt to automatically resolve conflicts when they are generated“ müsste dazu der Haken entfernt werden.

Jul 212014
 

Möchte man die Drop Location der Build Server auf einen anderen UNC Pfad umziehen wäre es schön wenn der Link zur Drop Location für die bereits abgeschlossenen Builds auch noch funktioniert. Diesen könnten wir relativ einfach per API ändern. Wenn man sich die Arbeit sparen will geht es noch einfacher mit den Community TFS Build Manager .

Dieser war früher Bestandteil der TFS Build Extensions und ist mittlerweile über die Visual Studio Gallery verfügbar.

Nach Installation ist der TFS Build Manager unter Tools zu erreichen

Wir können Build Definitionen selektieren und den Drop Folder für alle Definitionen bearbeiten sowie ein Search/Replace für die Drop Location der abgeschlossenen Builds ausführen:

Wahrscheinlich bekommt man noch eine Exception das man nicht über das Recht „Update build information“ verfügt. Der Account unter dem die Build Server laufen (TFSBuild) hat dieses Recht. Also entweder den Account nutzen oder sich vorrübergehend das Recht über Webaccess geben:

Danach sollte es möglich sein die Drop Location der alten Builds zu ändern.

Jul 042014
 

Seit längerer Zeit kann man die Testabdeckung im Build Prozess sehr einfach einschalten. Dazu kann man in der Build Definition „Type of run settings“ auf CodeCoverageEnabled einstellen:


Leider bekomme ich mit der Option in TFS 2013 aktuell keine Code Coverage Results:


Erst wenn man die *.runsettings Datei mit ins Projekt aufnimmt und im Build Prozess angibt funktioniert die Ausgabe der Code Coverage wieder. Die *.runsettings Datei ist dabei eine Konfiguration für die Ausführung der Unit Tests. (In Visual Studio 2010 gab es dafür z.B. noch die testsettings). Im Projekt kann man eine Xml Datei anlegen, diese in *.runsettings umbenennen den Inhalt aus der MSDN Dokumentation rein kopieren.

Siehe: http://msdn.microsoft.com/en-us/library/jj635153.aspx

Nebenbei können wir in der Datei auch gleich festlegen dass z.B. die UnitTest dll’s selbst von der Analyse ausgeschlossen werden:


In der Build Definition muss dann „Type of run settings“ auf UserSpecified stehen und der Verweis zum „Run Settings file“ muss angegeben werden:


Dann passt auch die Ausführung wieder.


Falls man immer noch keine Ergebnisse sieht liegt es wahrscheinlich daran, das auf dem Build Server kein Visual Studio Premium / Ultimate installiert ist. Falls man die Solution auf dem Build Server öffnet sollte man dort auch entsprechende Code Coverage Results bekommen.

Ergänzung 22.09.2014: Unter VS 2013.3 und TFS 2013.3 ist mir noch folgender Bug aufgefallen:

Wenn man den „Type of run settings“ direkt in den Einstellungen auf UserSpecified stellt kann es sein das die Einstellung nicht beachtet wird. Geht man hingegen über den Button in den extra Dialog und stellt die Options dort auf „Custom“ wird die Einstellung übernommen und Code Coverage funktioniert. Siehe Screenshots:



Auf Stackoverflow gibt es dazu auch einen entsprechenden Eintrag: http://stackoverflow.com/questions/24016217/tfs-2013-no-code-coverage-results

Jul 032014
 

Nachdem letztens auf einer Maschine bei mir das Register „Team“ in Excel gefehlt hat hier ein kurzer Hinweis. Es lag lediglich daran, dass das COM-Addin vom Team Foundation Server nicht mehr aktiv war.

Also: File -> Options -> Add-Ins -> Manage Com Add-Ins -> Go -> Team Foundation Add-In auswählen und Ok klicken.

Mrz 032014
 

Möchte man in Excel Reports über Workitems erstellen (z.B. in Visual Studio „Create Report in Microsoft Excel“) kann eventuell dieser Fehler auftreten.


In dem Fall lag es daran das auf dem Team Foundation Server (bzw. wenn es keine Single Server Installation ist auf dem SQL Server) in der Firewall der Port 2383 nicht konfiguriert war. Siehe auch „Required Ports“ im TFS Installation Guide

Aug 142013
 

Mittlerweile ist es sehr einfach geworden NUnit Tests im TFS Build mit laufen zu lassen. Dies ist seit TFS/VS 2010 passiert:

NUnit in Team Foundation Server 2010 / Visual Studio 2010

Hier musste das Build Prozess Template angepasst werden damit nicht nur MSTest Unit Tests sondern auch NUnit Tests ausgeführt werden konnten. Zum Beispiel konnte man dafür die TFS Build Extensions von Codeplex verwenden. Unit Tests in Visual Studio 2010 ließen sich nur über zusätzliche Plugins ausführen. (zum Beispiel Resharper)

NUnit in Team Foundation Server 2012 / Visual Studio 2012

Es besteht die Möglichkeit neben MSTest z.B. auch NUnit oder xUnit Tests im Visual Studio auszuführen. Dank des Visual Studio Test Runners und entsprechenden Erweiterungen. Für NUnit kann man den “NUnit Test Adapter” per “Extensions and Updates” hinzufügen. Der Test Explorer in VS2012 kann damit auch MSTest und NUnit Tests in einer gemeinsamen Liste darstellen und ausführen.

Ein wenig Aufwand gab es weiterhin. Man muss auf allen Build Servern den NUnit Test Adapter nachinstallieren. Vier weitere NUnit dll’s in Version Control aufnehmen und diese als “Custom Assemblies” an die Build Controller weiter verteilen.

Dieser Aufwand entfällt jetzt. In einem NUnit Test Projekt kann man per NuGet einfach das Paket “NUnit TestAdapter including NUnit2.6.2 framework” aufnehmen. Dieses enthält neben der nunit.framework.dll auch alle dll’s um die NUnit Tests direkt auszuführen. Die Extension “NUnit Test Adapter“ für Visual Studio kann damit auch entfallen.

 nunittestadapter

Das einzige was jetzt noch zu tun ist: Code einchecken –> Build Server komipliert –> NUnit Tests werden ausgeführt. Es ist keine Anpassung auf den Build Servern notwendig.

Damit funktioniert NUnit auch problemlos auf den Hosted Build Controllern im Team Foundation Service – http://tfs.visualstudio.com

Was will man mehr Smiley

Jul 292013
 

In den TFS Trainings kommt häufiger die Frage wie man neue Workitems per API anlegen kann. Zum Beispiel ist das sinnvoll wenn in jedem Sprint gewisse Aufgaben erneut erledigt werden sollen. Eine Variante ist sicher das Kopieren der Workitems per Excel oder in Visual Studio per Kontextmenü. Um mehr Möglichkeiten zu haben soll in dem Beitrag auf die .NET API eingegangen werden. Am Ende soll ein neues Product Backlog Item im TFS angelegt sein, sowie ein neuer verknüpfter Testcase.

Der Beispielcode sollte mit jeden Teamproject ab Scrum Version 2.0 funktionieren. Für andere Process Teamplates müsste dann z.B. “Product Backlog Item” in “User Story” oder “Requirement” geändert werden. Auch die Felder der Workitems können natürlich abweichen, je nachdem was man füllen möchte.

1. Benötigte Referenzen

Microsoft.TeamFoundation.Client, Microsoft.TeamFoundation.WorkItemTracking.Client

2. Connection zum TFS

Ein Weg sich am TFS anzumelden ist der Standarddialog welcher auch in Visual Studio erscheint. Über den TeamProjectPickerMode wird genau ein TeamProject für die Auswahl zugelassen.

var teamProjectPicker 
    = new TeamProjectPicker(TeamProjectPickerMode.SingleProject, false);
teamProjectPicker.ShowDialog();

var teamProjectCollection = teamProjectPicker.SelectedTeamProjectCollection;
var projectInfo = teamProjectPicker.SelectedProjects.FirstOrDefault();

3. WorkItemStore

Über den WorkItemStore haben wir Zugriff auf alle Workitems und können diese auslesen oder neue anlegen.

var workItemStore = teamProjectCollection.GetService<WorkItemStore>();

4. Product Backlog Item anlegen

Jetzt wird ein neues Workitem angelegt. Im Konstruktor muss der Typ angegeben werden. Hier sollte vorher noch geprüft werden ob es diesen Typ in der WorkItemTypes Collection des Team Projektes überhaupt gibt. Danach werden die Felder Title, Description und Assigned to ausgefüllt. Das Assigned to wird dabei auf den angemeldeten User gesetzt. Das einzige Pflichtfeld ist bekanntlich Title. (sofern man keine Anpassungen gemacht hat)

var teamProject = workItemStore.Projects[projectInfo.Name];

var workItemPBI = new WorkItem(teamProject.WorkItemTypes["Product Backlog Item"])
{
    Title = "Product Backlog Item Demo",
    Description = "Description"
};

workItemPBI.Fields["Assigned to"].Value
    = teamProjectCollection.AuthorizedIdentity.DisplayName;

5. Test Case anlegen und speichern

Analog dazu wird ein Testcase erzeugt und anschließend gespeichert. Durch das Speichern wird die Property Id am Workitem Objekt gefüllt.

var workItemTestCase = new WorkItem(teamProject.WorkItemTypes["Test Case"])
{
    Title = "Test Case Demo",
};

workItemTestCase.Fields["Assigned to"].Value
    = teamProjectCollection.AuthorizedIdentity.DisplayName;

workItemTestCase.Save();

6. Product Backlog Item mit Test Case verlinken und speichern

Es wird eine Verlinkung “Tested By / Tests” zwischen Product Backlog Item und Test Case erzeugt. Dazu wird die Id von dem vorher gespeicherten Test Case benötigt. Anschließend wird auch das Product Backlog Item gespeichert.

var linkTypeEnd = workItemStore.WorkItemLinkTypes.LinkTypeEnds["Tested By"];
workItemPBI.WorkItemLinks.Add(new WorkItemLink(linkTypeEnd, workItemTestCase.Id));
workItemPBI.Save();

7. Ergebnis

Mit einer Workitem Query sind die beiden neuen Workitems und deren Verlinkung sichtbar.

tfsworkitemapi

Möchte man mehrere Workitems auf einmal speichern kann man auch den BatchSave verwenden.

workItemStore.BatchSave(new[] { workItemPBI, workItemTestCase });

Download Sample

Apr 262013
 

Microsoft bietet am 1. Mai ein kostenloses Live Event zur Vorbereitung für die Prüfung 70-498. https://www.microsoftvirtualacademy.com/liveevents/applying-alm-with-visual-studio-2012

Das Event startet zur Entwicklerfreundlichen Zeit 17 Uhr und endet 2 Uhr. Smiley

Weiterhin ist sicher auch dieses Buch empfehlenswert: Professional Scrum Development with Microsoft Visual Studio 2012