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

Apr 262013
 

Wenn man im Team Foundation Server die Code Analysis Policy einschaltet hat man ein Problem mittels der Power Tools über den Windows Explorer einzuchecken. Die dll für die Code Analyse kann nicht außerhalb von Visual Studio / Team Explorer geladen werden.

CodeAnalysisWindowsExplorerError

Mögliche Abhilfe:

  • Policy ausschalten bzw. Code Analyse nur auf dem Build Server ausführen (z.B. über einen Gated Checkin)
  • Policy nicht auf das ganze Team Project anwenden sondern auf Ordner oder bestimmte Dateiendungen beschränken. (z.B. nur Files mit der Endung *.cs) Dies wird durch die Custom Path Policy aus den Power Tools ermöglicht
  • Nicht über den Windows Explorer einchecken Zwinkerndes Smiley

Oder hat noch jemand eine bessere Idee?

Mrz 202013
 

Gerade in einer alten TFS2010 Maschine festgestellt: Die Permissions in SQL Server Reporting Services (SQL Server 2008 R2) und Sharepoint Services 3.0 lassen sich in IE10 nur noch im Kompatibilitätsmodus konfigurieren.

Sharepoint bringt beim hinzufügen von Benutzern und Gruppen “No exact match was found”

sharepoint_permissions_ie10_error

In SSRS lässt sich das Kontextmenü nicht mehr aufklappen:

ssrs_permissions_ie10_error

Aug 172012
 

PsExec von Sysinternals ermöglicht das remote ausführen von Prozessen. Damit lässt sich z.B. auch ein MSI Paket installieren. Hier der Kommandozeilenaufruf:

psexec $ZielRechner -u „$UserName“ -p „$Passwort“ -h cmd /c „msiexec.exe /i “$PfadMSIPaket /quiet /norestart“

Die Variablen müssen entsprechend ersetzt werden, z.B.:

psexec \\win7test -u „user“ -p „password“ -h cmd /c „msiexec.exe /i „\\win8\public\MySetup.msi“ /quiet /norestart“

Damit lässt sich ein das Deployment eines MSI Pakets auch leicht in den Build Prozess vom TFS integrieren.