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.

Dez 042014
 

Auch wenn noch ein paar Monate Zeit waren habe ich heute mal die Rezertifizierung für die Prüfung den MCSD Application Lifecycle Management (Prüfung 70-499) absolviert. Link: https://www.microsoft.com/learning/en-us/exam-70-499.aspx

Ich hatte 43 Fragen zu beantworten und es sind viele ähnliche Fragen aus den Prüfungen 70-496, 70-497 und 70-498 wieder aufgetaucht. Mit fast 20 Fragen war Microsoft Test Manager (MTM) am meisten vertreten (Inhalte von 70-497). Ansonsten gab es wieder Fragen zur Installation, Administration, Version Control, Build Definitionen, Scrum, Process Templates…

Entgegen meiner Erwartungen gab es keine Frage wo ich TFS 2013 Wissen benötigt hätte. Git steht zwar in einem Punkt der Prüfungsinhalte, tauchte aber gar nicht auf. Release Management steht gar nicht erst in den Prüfungsinhalten. In einer Frage wurde sogar TFS Preview erwähnt, was bekanntlich schon lange Visual Studio Online heißt. Und das obwohl die Prüfung im August 2014 veröffentlicht wurde, schade. Highlight war dann die letzte Frage, wo auch nach 10-mal lesen Antwort A und C identisch waren. Zum Glück hat es trotzdem gereicht 😉

Wer also die Prüfungen 70-496, 70-497 und 70-498 geschafft hat sollte mit der Rezertifizierung keine riesigen Probleme haben.

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.

Sep 222014
 

Auch dabei helfen wieder die Team Foundation Server Power Tools. In Visual Studio kann man die History leider nicht nach einem bestimmten Text im Checkin Kommentar durchsuchen.

Per Visual Studio Command Promt lässt sich ein entsprechender Dialog öffnen:

tfpt searchcs

Der Rest ist recht selbsterklärend. Verbindung zu einer Team Project Collection. Pfad in der Quellcodeverwaltung. Danach kann gefiltert werden nach Datum, User, Kommentar oder auch Checkin Notes.

Sep 222014
 

Über den Team Explorer in Visual Studio wird ein Shelveset wieder in den Bereich abgeholt wo das shelve erfolgt ist. Gelegentlich kann es vorkommen, dass man in einem Branch ein Shelveset erstellt, dies aber in einen anderen Branch einchecken will. Wie kann man also ein unshelve in einen anderen Branch ausführen?

Per Visual Studio Command Prompt hilft uns das Command Line Tool tfpt. Falls man dieses nicht hat sollte man sich die Team Foundation Server Power Tools installieren. Wichtig ist das man sich in der Kommandozeile im Workspace in dem Pfad des Branches befindet wo das Shelveset erstellt wurde. Es kann auch zu Fehlermeldungen kommen wenn in dem Workspace noch offene Änderungen enthalten sind.

Danach kann man mit folgendem Befehl ein unshelve ausführen:

tfpt unshelve SHELVESETNAME /migrate /source:“$/TeamProjectName/PfadSourceBranch“ /target:“$/TeamProjectName/PfadTargetBranch“

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