Maik Hanns

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

Jul 242013
 

Ich bin gestern bei einer “0815” Fakes Framework Demo auf eine Exception gestoßen. Der Code macht nix besonderes und unterdrückt einfach bei einem MessageBox.Show() Aufruf die Anzeige der MessageBox und simuliert das der Benutzer auf Ok geklickt hat:

fakesdebugging_fakemessagebox

Soweit so gut. Funktioniert auch. Lässt sich nur nicht debuggen:

fakesdebugging_unittestisolationexception

Beim Aufruf ShimContext.Create() erhalte ich eine “UnitTestIsolationException”. Der Fehlertext ist eine große Hilfe, demnach würde ich wohl heute noch mein Visual Studio neu starten.

Am Ende war die Lösung einfach. Leider wurde das Projekt von Visual Studio 2010 auf 2012 migriert und enthielt noch eine *.testsettings Datei. Die Unit Tests wurden also mit diesen Einstellungen ausgeführt.

fakesdebugging_testsettings

Visual Studio kann mit den *.testsettings von 2010 noch umgehen und in manchen Fällen sind diese auch noch notwendig. Zum Beispiel wenn man Tests aus Visual Studio heraus Remote ausführen möchte oder für Web Performance und Last Tests. (siehe http://msdn.microsoft.com/de-de/library/jj635153.aspx)

In VS 2012 wurden bekanntlich die *.runsettings eingeführt. Damit laufen nicht nur MSTest Unit Tests sondern auch NUnit, XUnit usw. Die runsettings sind allerdings etwas unhandlich weil es kein UI zum editieren gibt und man die Einstellungen im XML vornehmen muss.

Nach umschalten auf eine *.runsettings Datei lassen sich die Tests welche MS Fakes enthalten wieder debuggen.

fakesdebugging_runsettings

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
 

Hier mal zwei Beispiele wie man mittels eigenen Behavior den Fensterinhalt einer WPF Anwendung per Strg+Mausrad zoomen kann. Die beiden Behaviors lassen sich per Expression Blend mit der Maus auf die entsprechenden Controls ziehen oder mit ein paar Zeilen Xaml Code einbinden:

ZoomWindowBehavior:

<Window
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity" 
        xmlns:behaviors="clr-namespace:ZoomBehaviors;assembly=ZoomBehaviors"
        x:Class="ZoomTestClient.MainWindow"
        Title="MainWindow" Height="350" Width="525">
    <i:Interaction.Behaviors>
        <behaviors:ZoomWindowBehavior/>
    </i:Interaction.Behaviors>
    ...

ZoomUIElementBehavior:

<Image Source="world.png" VerticalAlignment="Center" HorizontalAlignment="Center" Width="64" Height="64">

<i:Interaction.Behaviors> <behaviors:ZoomUIElementBehavior MaximumScale="4" MinimumScale="0.5"/> </i:Interaction.Behaviors> </Image>

Zusätzlich kann man noch einen MaximumScale und MinimumScale angeben: MinimumScale=”0.5” und MaximumScale=”4” bedeutet dann also einen Zoom von 50%-400%. Genutzt wird dabei das LayoutTransform der Controls. Weiterhin wird noch die System.Windows.Interactivity.dll und die Microsoft.Expression.Interactions.dll aus dem Expression Blend SDK verwendet.

Das komplette Beispiel inkl. der beiden Behaviors gibt es hier: Download

Aug 172012
 

Will man in einem Unit Test 2 Listen z.B. vom Typ List<T> vergleichen muss man sicherstellen das die Klassen in der Liste auch die Equals Methode richtig implementieren. Beispiel: Dieser Code funktioniert nur wenn die Klasse DataItem die Equals Methode überschreibt.

[TestMethod]
public void GetDataList_TestWithEquals()
{
    Class1 c = new Class1();

    var expectedList = new List<DataItem>() {new DataItem { Name = "Test"}};

    CollectionAssert.AreEqual(expectedList, c.GetDataList());
}

Alternativ kann man bei CollectionAssert.AreEqual auch eine Klasse angeben welche das Interface IComparer implementiert:

[TestMethod]
public void GetDataList_TestWithIComparer()
{
    Class1 c = new Class1();

    var expectedList = new List<DataItem>() {new DataItem { Name = "Test"}};

    CollectionAssert.AreEqual(expectedList, c.GetDataList(), new DataItemComparer());
}

Hier das Sample als kleines VS2012 Projekt: Download

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.