• “Welche Prozesstemplates gibt es und wo finde ich eine Dokumentation?”
• “Welche Felder, Stati, Workflows gibt es?”
• “Was kann ich wann ändern?”
• “Wie kann ich ein bestehendes Projekt am Prozesstemplate updaten?”
• “Welche Erweiterungsmöglichkeiten habe ich neben dem Prozesstemplate?”

Dazu habe ich ein paar passende Links gesammelt:

• MSF for CMMI, MSF for Agile software development und Visual Studio Scrum process template liegen im Moment in Version 2013.2 vor. Eine Field-Reference findet sich hier.
• Zum Thema Anpassungsmöglichkeiten des TFS im allgemeinen empfehle ich die folgenden Seiten: hier und hier
• Zum Thema Möglichkeiten die Änderungen nachdem man ein Projekt mit einem bestimmten Template angelegt hat für bestehende Projekte zu übernehmen gibt es hier – eine schöne Gegenüberstellung von Pro und Contra der Varianten.
• Zum Thema TFS 3rd Party Erweiterung war es eigentlich angedacht dieses Tool zu evaluieren.
• Ein Videotraining in der Microsoft Virtual Academy zum Thema Anpassung und Erweiterung von TFS 2013 findet man hier.

Viel Spaß beim Anpassen und gerne nehme ich weitere gute Informationen als Kommentar entgegen.

Ich habe ja schon lange den TFS als ein Nebenschauplatz-Hobby für mich entdeckt und nun endlich auch die passende Zertifizierung (mit 3 Prüfungen) abgeschlossen. Schon letztes Jahr konnte ich zum Glück ohne Vorbereitung die 2 Prüfungen zur Administration und Delivering Continuous Value in kurzem Abstand erfolgreich abschließen. Die dritte zum Thema Software Testing hatte ich immer vor mir her geschoben, da die Vorbereitungszeit nie da war und das Thema Testen nicht mein “tägliches Brot” im TFS darstellt. Jetzt konnte ich mich mit dem Thema etwas intensiver vertraut machen und habe noch kräftig hinzugelernt.

Überraschung für mich war die Gültigkeit, denn die Zertifizierung ist nur 2 Jahre aktiv/gültig.

Vorbereitet habe ich mich unter anderem mit folgenden Informationen:

• 70-496:  Administering Microsoft Visual Studio Team Foundation Server 2012
• 70-497:   Software Testing with Visual Studio 2012
• 70-498: Delivering Continuous Value with Visual Studio 2012 Application Lifecycle Management

1. Limited – Man kann nur seine eigenen WorkItems sehen (keine TFS CAL notwendig)
2. Standard (default) – Standardfunktionen, Agile boards, Backlog&sprint planing, Chart viewing (Nutzer mit TFS CAL)
   
3. Full – Alle verfügbaren Funktionen (Nutzer mit MSDN Subscription)
   

Wer in welchem Access Level einsortiert ist findet man auf seinem TFS unter http://<tfsurl&gt;:8080/_admin/_licenses.  Über den “Export audit log” Link wird ein entsprechendes CSV zur Verfügung gestellt was je Account den letzten Zugriff und die eingerichtete Zugriffsberechtigung enthält.

Weitere Informationen findest du hier.

Fazit: Der “Limited” Zugriff kann zum Beispiel für Kunden ohne Lizenz genutzt werden, die über den TFS Webzugriff nur Bugs, Issues o.a einstellen wollen. Der “normale” Softwareentwickler hat in den meisten Fällen eine MSDN Subscription (Visual Studio Ultimate mit MSDN, Visual Studio Premium mit MSDN oder Visual Studio Test Professional mit MSDN) und damit den vollen Zugriff mit allen Funktionen, die er gar nicht unbedingt alle braucht. Der Projektleiter, Anforderungsmanager, … hat in den wenigsten Fällen eine MSDN Subscription und damit nur den Standard-Zugriff. Es fehlen ihm also genau die Funktionen die er am meisten benötigt, wie Feedback Management, Agile Portfolio Management oder Diagrammerstellung… Nutzt der Mitarbeiter ohne Vollzugriff die anderen Möglichkeiten wie Excel, Project, Reporting Services oder Team Explorer für den Zugriff auf den TFS, reicht ihm nach wie vor die TFS CAL um alle von dem jeweiligen Tool angebotenen Funktionen des TFS zu nutzen. Zum Thema Lizenzen und TFS gibt es ein White Paper und auch einige Blogbeiträge….

Mit einer vorhandenen VS 2013 Solution mit CodedUI Tests (Class Library mit .Net Framework 4.5 konfiguriert) wurden folgende Konstellationen getestet:

1. TFS 2012 Update 3/4, TFS Build Controller 2012, Visual Studio 2013.1 Premium, Build Agent als Interaktiver Prozess > Ergebnis: “Failed to initialize the unit test extension ‚urn:CodedUITest‘: A unit test extension is not registered for the following attribute: Microsoft.VisualStudio.TestTools.UITesting.CodedUITestAttribute.”
2. TFS 2013, TFS Build Controller 2012, Visual Studio 2013.1 Premium/Ultimate Testmanager, Build Agent als Interaktiver Prozess > Ergebnis: “Failed to initialize the unit test extension ‚urn:CodedUITest‘: A unit test extension is not registered for the following attribute: Microsoft.VisualStudio.TestTools.UITesting.CodedUITestAttribute.”
3. TFS 2013, TFS Build Controller 2013, VS 2013 Ultimate, Testmanager 2013,  Build Agent als Interaktiver Prozess > Ergebnis: Tests laufen
4. TFS 2013, TFS Build Controller 2013, VS 2013 Premium, Build Agent als Interaktiver Prozess > Ergebnis: Tests laufen

Fazit: CodedUI Tests sollten immer mit der zur TFS-Version passenden Visual Studio Version entwickelt werden. Bei TFS 2012 also Visual Studio 2012 + TFS Build Controller 2012 + Build Agent 2012 mit VS 2012 Premium verwenden. Unsere zur Zeit passende Konstellation ist TFS 2013, TFS Build Controller 2013, Build Agent 2013 (interaktiver Prozess), VS 2013 Premium

Auch wir von der T-Systems Multimedia Solutions GmbH sind mit Vorträgen rund um das Thema ALM vertreten. Sebastian Wagner, Projektleiter und Daniel Kubis, Software Architekt bei der MMS, berichten über Erfahrungen bei der Einführung des TFS 2010 und die Einbindung in die Unternehmensprozesse bei der T-Systems MMS. Daniel Kubis stellt am Technical Day Erfahrungen und Best Practices mit TFS Teambuild und Sebastian Wagner best practices bei der SharePoint Entwicklung mit TFS 2010 vor.

Hier finden Sie die Agenda, das begleitende Workshop-Angebot und das Anmeldungsformular:
www.teamconf.de

Ein Kollege wollte gerne eine Check-In Policy, die ein “Get Latest” vor dem Check-In simuliert, weil sie das Gefühl hatten, dass dank des Gated Check-In Code verloren geht. Das konnte ich nicht glauben und war auch der Meinung, das so eine Check-In Policy völliger Quatsch ist. Beim Check-In wird der Entwickler sowieso gezwungen bei Konflikten einen Merge am Client zu machen. Wenn die Konflikte behoben sind kann er den Check-In vornehmen und der Gated Build würde den Code bei erfolgreichem Build auch in den TFS Server einchecken.

Was ist also der Grund für den Policy Wunsch bzw. der Grund für den “verlorenen” Code? Nehmen wir mal an zwei oder mehr Entwickler ändern genau an den gleichen Codezeilen und versuchen nahezu zeitgleich einzuschecken. Bei jedem Entwickler wird auf seinem Client mit dem Stand der im TFS eingecheckt ist ein Merge vollzogen und kein Konflikt festgestellt. Der Code geht also an den Team-Build und reiht sich in die Schlange der Gated Builds ein. Siehe Abbildung 1.

Abb. 1: Gleichzeitige “Gated Builds” werden in Build-Queue eingereiht.

Wenn der Code erfolgreich gebaut hat, wird der Code des “schnellsten” Entwicklers an den TFS Server übergeben. Der nächste Gated Build kann aus der Queue durch der Build-Controller gestartet werden. Jetzt kann es passieren, dass der Gated Build schon am Anfang fehl schlägt, wenn kein “Auto-Merge” durchgeführt werden kann (weil ja die Entwickler auf der gleichen Codezeile Änderungen vorgenommen hatten). Das erwartete Verhalten ist also, dass folgende Builds aus der Queue immer nur nacheinander und nie zeitgleich ablaufen und dass bei Merge-Konflikten der Build fehlschlägt und der Entwickler erneut Clientseitig Mergen muss um einen weiteren Gated Build anzustoßen.

Jetzt haben wir aber das Phänomen, dass wie in Abbildung 2 zu sehen, die weiteren Gated Builds aus der Queue NICHT wie erwartet nacheinander Loslaufen sondern auf einmal gleichzeitig auf verschiedenen Agents?!

Abb. 2: Fehler? “Gated Builds” werden aus der Build-Queue gleichzeitig gestartet.

Hier liegt vermutlich das Problem. Jeder Build für sich ist auf dem Agent valide und geht erfolgreich durch und wird in den TFS eingecheckt. Wenn aber Änderungen an gleichen Codepassagen vorhanden sind, kann es passieren, dass Code verloren geht?! Wer hat ähnliche Phänomene und kann Tipps geben.

In verschiedenen Foren haben wir ähnliche Probleme entdeckt, aber noch keine Lösung. Wir nutzen nur einen Build-Controller, der wiederum sehr viele Agents verwaltet. Es ist auch schon häufiger aufgetreten dieses Problem.

Fazit: Es würde definitiv keine Check-In Policy helfen, die “Get Latest” vor dem Check-In erzwingt, denn Merge Konflikte muss der Entwickler sowieso manuell lösen und das geht nur gegen den Code der im TFS eingecheckt ist. Würde die Queue im Falle eines Gated Check-In auch wie erwartet arbeiten (also alle Builds sequentiell) würde aus meiner Sicht auch nie Code überschrieben/verloren gehen.

Wie der normale Workflow ist habe ich hier für alle Entscheidungen und Fälle bei einem Gated Check-in zusammengefasst:

• Unmittelbar vor dem Einchecken:

1. "Get Latest", damit verhindert man ggf. Check-in Konflikte.
2. Rebuild Solution, danach ggf. Warnings, Fehler entfernen
3. UnitTests durchführen, evtl. Fehler beseitigen

• Änderungen Einchecken:

1. Kommentar zum Check-in abgeben
2. Mit Work Item verknüpfen (im Idealfall mit einem Task, Bug und diesen auf Resolved stellen)
3. Mit OK wird der verbundene “Gated Check-in” angezeigt. Hier hat der Entwickler zwei Möglichkeiten (Änderungen lokal beibehalten, oder nicht beibehalten):
4. 
5. Abhängig ob man die Änderungen lokal beibehalten oder nicht beibehalten hat, muss man je nach Erfolg des Builds verschiedene Schritte durchführen:

• Nach erfolgreichem Build ("Preserve my Pending Changes"/Änderungen lokal beibehalten angewählt):

1. "Reconcile Workspace" – gleicht lokalen Stand mit dem auf dem Server ab
2. "Undo Pending Changes" – macht Checkout von nicht geänderten Dateien rückgängig
3. Jetzt hat man lokal wieder den letzten Stand aller Sourcen und hat keine Dateien mehr ausgecheckt.

• Nach erfolgreichem Build ("Preserve my Pending Changes"/Änderungen lokal nicht beibehalten abge-wählt):

  1. "Get Latest" – letzten Stand abrufen, da vorher ein Shelve + undo pending changes lokal gemacht wurde

• Nach Fehlerhaftem Build ("Preserve my Pending Changes" angewählt):

1. ggf. “Get Latest Version” oder “Get Specific Version”
   
2. Problem beheben, Fehler fixen, Tests fixen
3. Erneut einchecken und warten

• Nach Fehlerhaftem Build ("Preserve my Pending Changes" abgewählt):

1. Stand "unshelven" um lokal wieder den Fehlerhaften Stand zu haben.
2. Problem beheben, Fehler fixen, Tests fixen
3. Erneut einchecken und warten

Man kann unabhängig ob man die Änderungen bei einem Gated Check-in lokal beibehält oder nicht prinzipiell weiterarbeiten. Vielleicht bietet es sich trotzdem an den Gated Build abzuwarten und solange keine weiteren Änderungen vorzunehmen. Wenn man sich mit den ganzen Workflows vertraut gemacht hat und die Mechanik verstanden hat, wird man feststellen, dass es durchaus möglich ist ganz normal weiterzuarbeiten und sich von der ganzen “Gated Build Problematik” nicht weiter einzuschränken. Es ist also meiner Meinung nach ein “Mythos” dass Gated Check-in eine Blockade oder Bremse bei der Entwicklung darstellt.

Dinge wie “Reconcile” oder “Unshelve” kann man an verschiedenen Stellen machen. Die beste ist eigentlich im “Build Explorer” an einem bestimmten Build mit rechter Maustaste:

Rechte Maustaste an einem fehlgeschlagenen “Gated Build”

Rechte Maustaste an einem erfolgreichen “Gated Build”

Was alles bei einem Gated Check-in Workflow passieren soll (nur Compilieren, oder auch UnitTests usw.) entscheidet letztendlich der Buildmanager. Was man dort alles machen und optimieren kann werde ich in einem weiteren gesonderten Post beschreiben.

Ohne geht gar nicht:

• ReSharper (die einzige kostenpflichtige in der Aufstellung)
• Productivity Power Tools
• PowerCommands for Visual Studio 2010
• Team Foundation Server Power Tools March 2011

Sollte man haben:

• Stylecop (schon mit ReSharper Integration)
• TFS Auto Shelve (nie mehr das Shelven am Abend vergessen!)
• Search Work Items

Kann man mal probieren und ist ganz nett:

• GhostDoc
• Highlight all occurrences of selected word
• Application Architecture Guide Layer Diagrams
• Architecture Layers Patterns
• Inmeta.VisualStudio.TeamExplorer.BuildExplorer

Viel Spaß beim installieren und ausprobieren. Bis auf ReSharper sind alles kostenlose Extensions für Visual Studio 2010.

 
Team Project Settings > Source Control

 
Check-in Policy > Add > Work Item Query Policy

Jetzt noch eine entsprechende Team Query auswählen und fertig. Jetzt können die Entwickler nur noch Work Items auswählen, die durch die Query gefunden werden. Sinnvoll ist dann z.B. “All My Active WorkItems” als Query anzulegen. Es kann aber auch Sinn machen, dass ein Entwickler nur WorkItems aus einem aktuellen Sprint wählen kann. Auch dass kann man ja durch anpassen der Query entsprechend erreichen.

Wo kommt nun diese Check-in Policy her? Jeder Teilnehmer des Team Projektes muss in seinem Visual Studio die folgende Extension installieren: Team Foundation Server Power Tools March 2011

Der Projektadmin kann entsprechende Queries anlegen oder modifizieren und auch die Check-in Policies administrieren.

  2: using System.Linq;

  3: using System.Xml.Linq;

  4: using System.Xml.XPath;

  5: using Microsoft.TeamFoundation.Build.Client;

  6: using Microsoft.TeamFoundation.Client;

  7: 

  8: namespace ConsoleApplication1

  9: {

 10:     class Program

 11:     {

 12:         static void Main(string[] args)

 13:         {

 14:             Console.WriteLine("Collection Url:");

 15:             var MyCollectionUrl = "http://tfs:8080/collection";

 16:             Console.WriteLine("Collection Url: {0}", MyCollectionUrl);

 17:             var tfs = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri(MyCollectionUrl));

 18:             var bs = tfs.GetService<IBuildServer>();

 19:             var bsSpec = bs.CreateBuildDefinitionSpec("*", "*");

 20:             var results = bs.QueryBuildDefinitions(bsSpec);

 21: 

 22:             foreach (var qb in results.Definitions)

 23:             {

 24:                 if (qb.BuildController != null)

 25:                 {

 26:                     var cu = qb.BuildController.Name;

 27:                     var p2 = qb.BuildController.ServiceHost.Name;

 28:                     string tags = "null";

 29:                     if (qb.ProcessParameters != null)

 30:                     {

 31:                         var xmlProcessParameters = XElement.Parse(qb.ProcessParameters);

 32: 

 33:                         var agentsettings =

 34:                             xmlProcessParameters.Nodes().Select(xNode => xNode).Where(

 35:                                 name => name.ToString().Contains("AgentSettings"));

 36:                         if (agentsettings.FirstOrDefault() != null)

 37:                             tags = agentsettings.First().CreateNavigator().GetAttribute("Tags", string.Empty);

 38:                     }

 39: 

 40:                     string def = qb.TeamProject + @"\" + qb.Name;

 41:                     Console.WriteLine("{0}\t{1}\t{2}\tTags: {3} ", cu, p2, def, tags);

 42:                 }

 43:                 else

 44:                 {

 45:                     string def = qb.TeamProject + @"\" + qb.Name;

 46:                     Console.WriteLine("{0}\t{1}\t{2} ", "null", "null", def);

 47:                 }

 48:             }

 49: 

 50:             Console.ReadLine();

 51:         }

 52:     }

 53: }

In der Ausgabe erhält man bei diesem Beispiel eine Ansicht aller Teamprojekte der Projektcollection “collection” auf die man als Ausführer Zugriff besitzt. Welcher Buildcontroller und welche Agent-Tags werden für welche Builddefinition verwendet.

Wir haben dieses Template etwas abgewandelt eingesetzt und standen jetzt aber vor dem Schritt, wie wir dieses weiter unter TFS 2010 supporten, bevor die Projekte auslaufen oder auf neue Templates migriert werden. Die gute Nachricht vorweg, wir haben einen Weg für uns gefunden, den zugehörigen Dienst weiterhin funktionstüchtig zu halten. Dazu hier ein kurzer Abriss zu den notwendigen Schritten:

1. Es bietet sich an die Solution mit Visual Studio 2010 zu öffnen und die verwendeten Referenzen auf den TFS neu zu setzen (von Version 9.0.0.0 auf 10.0.0.0)
   
   Das gilt für das Projekt “MptCodeLibrary” und “Test.UnitTest”
2. Ein Recompile des Codes liefert jetzt einige Warnungen von denen man einige sehr schnell abarbeiten kann. Folgende Änderung sollte man auf jeden Fall durchführen:

      1: TeamFoundationServer tfs 

      2:   = TeamFoundationServerFactory.GetServer(serverName)

   ersetzen durch:

      1: TfsTeamProjectCollection tfs 

      2:   = TfsTeamProjectCollectionFactory.

      3:     GetTeamProjectCollection(new Uri(serverName));

3. In der App.config müssen die WCF Einstellungen an 2 Stellen angepasst werden, weitere Infos findet man auch hier und hier: 

   

   basicHttpBinding zu wsHttpBinding 
   und wsHttpBinding muss  an der entsprechenden Stelle noch konfiguriert werden:

      1: <bindings>

      2:     <webHttpBinding>

      3:     ...

      4:     </webHttpBinding>

      5:   <wsHttpBinding>

      6:     <binding name="noSecurity">

      7:       <security mode="None"/>

      8:     </binding>

      9:   </wsHttpBinding >          

     10: </bindings>

4. Es muss jetzt die URL der Collection zu den Team Projekten in die App.config eingetragen werden.

      1: <teamServerSection>

      2:  <teamservers>

      3:   <teamserver servername="http://tfs:8080/tfs/default" />

      4:  </teamservers>

      5: </teamServerSection>

5. In der TeamFoundationFacade muss in einer Methode die Sid ermittelt und mit übergeben werden (alter Code wurde auskommentiert):

      1: public void SignupForReceivingEvent(string serverName, 

      2:     string receiverPath, string filterExpression)

      3: {

      4: ...

      5:   try

      6:   {

      7:     //eventEndpoint.SubscribeEvent("Sid is ignored", 

      8:     //  "WorkItemChangedEvent", filterExpression, delPreference);

      9:     // get sid from current user

     10:     string sid 

     11:         = System.Security.Principal.WindowsIdentity

     12:         .GetCurrent().User.Value;

     13:     eventEndpoint.SubscribeEvent(sid, "WorkItemChangedEvent", 

     14:         filterExpression, delPreference);

     15:   }

     16: ...

     17: }

6. Jetzt sollte man den Stand erreicht haben, dass wieder Events am Service ankommen, doch leider werden sie noch nicht richtig bearbeitet. Dazu muss eine weitere kleine Anpassung in GlobalListBuilder erfolgen (in diesem Fall wurde nur für eine Collection eine Unterstützung eingebaut!!!):

      1: private string DeriveTfsServerName(

      2:   XContainer workItemChangedEvent)

      3: {

      4:   ...

      5:   Uri artifactMoniker = new Uri(displayUrlElement.First().Value);

      6:   //IEnumerable<TeamServerConfiguration> teamServers 

      7:   //   = from teamServer in mptConfiguration.TeamServers where ...

      8: ...

      9:   //if (teamServers.Count() <= 0)

     10:   //    throw new MptException("Could not determine the TFS...

     11:   return artifactMoniker.Scheme + "://" 

     12:          + artifactMoniker.Authority 

     13:          +"/tfs/defaultCollection";

     14: }

7. Jetzt sollte sowohl der Dienst als auch das TFS Event empfangen und bearbeiten funktionieren.

Ziel ist es nach der Migration des TFS 2008 auf TFS 2010 die Projekte mit dem MPT Template weiter zu unterstützen, aber perspektivisch auf ein neues Template zu migrieren. Dazu wollen wir die Tools von der TfsIntegration Plattform verwenden. Vielleicht kann ich ja dazu in den kommenden Wochen auch noch Erfahrungsberichte veröffentlichen.

Mir ging es darum meinen SmartCard Reader von Cherry (ST-2000U) unter Windows 7 zum Laufen zu bekommen und vor allem den PIN-Modus 2 (PIN Eingabe am Card Reader und nicht auf der Computertastatur) im Zusammenhang mit Starmoney (HBCI) verwenden zu können.

Auf den Seiten von Cherry gibt es zwar einen aktuellen Treiber auch für Windows 7, doch leider hat bei mir immer nur der PIN Modus 1 (PIN auf der Computer Tastatur eingeben) funktioniert.

Um den Kartenleser mit Starmoney zu verwenden öffnet man das Kartenleser Setup und findet dann unter Ct API leider keinen Kartenleser zur Auswahl. Auch das Manuelle einrichten (wie hier beschrieben) hat bei mir nicht funktioniert.

Starmoney 7 Kartenleser Setup

Nach ein bisschen Recherche bin irgendwie auf SCM Microsystems SPR 532 gekommen und habe mir das Packet “SCM Microsystems SPR 532 SmartCard Reader (SPR532 PC/SC CT-API installer)” heruntergeladen und installiert.

Nach einem Neustart tauchte auch im Starmoney Kartenleser Setup unter Ct API der neue Eintrag auf.

Starmoney 7 Kartenleser Setup – Neuer Eintrag unter Ct API

Starmoney 7 Kartenleser Setup – PIN-Modus 2 in den Eigenschaften

In den Eigenschaften war der Test auch mit PIN Modus 2 erfolgreich. Im Starmoney kann mit diesem Standard-Reader wie gewohnt auch unter Windows 7 die HBCI Pin am PIN Pad eingegeben werden.

PIN Abfrage mit Eingabe am PIN Pad 

Vielleicht habe ich nur irgendetwas Falsch gemacht, aber da das gewünschte Ergebnis in dieser Variante erreicht ist bin ich vorerst zufrieden und vielleicht hilft der Post trotzdem dem ein oder anderen mit ähnlichen Problemen und Anforderungen.

Ich bin folgend vorgegangen:

1. Hier habe ich ein HP-TWAIN-DS Paket heruntergeladen.
   Das ist für folgende Scanner unter Windows 95/98/2000/XP/2003/NT:

• Hewlett-Packard ScanJet 7400C
• Hewlett-Packard ScanJet 5p
• Hewlett-Packard ScanJet 6100C
• Hewlett-Packard ScanJet 4p
• Hewlett-Packard ScanJet 3p
• Hewlett-Packard ScanJet IIcx
• Hewlett-Packard ScanJet IIp
• Hewlett-Packard ScanJet IIc
• Hewlett-Packard ScanJet 5100C
• Hewlett-Packard ScanJet 6200C
• Hewlett-Packard ScanJet 5200C
• Hewlett-Packard ScanJet 6300C
• Hewlett-Packard ScanJet 4100C

Das habe ich entpackt und anschließend im Gerätemanager für den Scanner nach einem Treiber auf dem Rechner im entpackten Ordner gesucht.

Wichtig ist dabei, dass man manuell “Auf dem Computer nach einem Treiber” sucht und dort “Aus einer Liste von Gerätetreibern auf dem Computer” wählt und im Anschluss auf “Datenträger” klickt um den Ordner auszuwählen.

Dieser Eintrag hat mich auf diese Idee gebracht. Das ganze sollte auch unter Windows Vista funktionieren denke ich. Auch da hatte ich eine Weile geforscht, den Scanner aber nie richtig zum laufen bekommen (außer mit VueScan). Viel Spaß, vielleicht hilft der Tipp ja noch dem einen oder anderen.

Links | Guidance, best practices

• Visual Studio TFS Branching Guide 2010
• Team Development with Visual Studio Team Foundation Server
• Visual Studio 2010 Quick Reference Guidance
• Visual Studio 2010 Team Foundation Server Requirements Management Guidance
• Microsoft Visual Studio 2010 Test Case Import Utilities
• MSBuild Extension Pack

Links | Entwicklung

• Visual Studio 2010 and .NET Framework 4
• SharePoint 2010 Visual Studio 2010 Extensions project
• Community Kit for SharePoint: Development Tools Edition
• SharePoint Tool Basket 2010

Links | Infrastruktur

• Visual Studio 2010 and Team Foundation Server 2010 VM Factory
• Visual Studio 2010 TFS Upgrade Guide
• TFS Integration Platform
• WIT Synchronizer

Links | Installation

• Visual Studio Team Explorer 2010
• Visual Studio Team System 2008 Service Pack 1 Forward Compatibility Update for Team Foundation Server 2010
• Microsoft Visual Studio Test Elements 2010
• Microsoft Visual Studio 2010 Ultimate
• Visual Studio Power Commands
• Team Foundation Server Power Tools 2010

Links | Blogs

• Brian Harry
• Granth‘s blog
• VSTS Rangers
• Visual Studio Team Test

Ziel war es Application Tier (AT), Data Tier (DT) und Sharepoint voneinander zu trennen. Die Installation erfolgt also auf 3 Maschinen. Alle 3 wurden mit Windows 2008 R2 Enterprise Server ausgestattet. Auf dem DT wurde dann SQL Server 2008 Standard Edition SP1 mit Reporting- und Analysis Services installiert. Das ganze ging relativ schnell und ohne weitere Komplikationen. Jetzt wollte ich den AT installieren, da die SharePoint-Komponente für den TFS 2010 optional ist und somit auch im Nachgang installiert und konfiguriert werden kann.

Der AT ist eigentlich auch ziemlich übersichtlich zu installieren, nur an einer Stelle kann es passieren, dass man ins stocken gerät. Bei den Analysis Services erscheint wahrscheinlich bei den meisten erst mal der Fehler “TF255040: Install SQL Reporting Services or at a minimum SQL Client Connectivity Tools on the application tier to ensure Analysis Services object model is present for warehouse processing.” Meine Lösung zu dem Thema sieht wie folgt aus. Ich habe auf dem AT das SQL Management Studio 2008 installiert und den Installation-Wizard + TFS Admin-Console komplett geschlossen (das ist wichtig!!!). Nach dem neu Öffnen der TFS Admin Console und des Installation-Wizard hat der Test im Analysis Service Bereich nach Eingabe des SQL Servers geklappt und der Installation stand nix mehr im wege.

Beim Sharepoint 2007 (MOSS) auf dem W2k8 R2 Server gab es das nächste Problem (KB article 962935, der aber leider noch nicht live zu sein scheint…). Hier hilft ein Eintrag vom SharePoint Blog. Folgt man der Anleitung für SharePoint 2007 SP2 Slipsteam, dann klappt es mit der Installation auch ohne Fehlermeldung.

Jetzt, da endlich die TFS 2010 Beta 2 PowerTools verfügbar sind kann es auch mit dem Customizing des ProzessTemplates los gehen. Infos dazu kommen sicher bald.

• Express
• Professional
• Premium
• Ultimate

Wir haben uns den Team Foundation Server 2010 Beta 2 und die Visual Studio 2010 Ultimate Beta 2 Edition schon runtergeladen und morgen geht die Evaluation los. Sowohl intern als auch für ein Kundenprojekt haben wir schon auf die Beta 2 gewartet. Da ist in den nächsten Wochen und Monaten sicher noch die ein oder andere News hier zu erwarten.

Bezüglich Sharepoint 2010 gab es heute mit dem Start der Sharepoint-Konferenz 2009 in Las Vegas auch die dazu passenden Neuigkeiten. So ist vor allem auch für die Entwickler mit Visual Studio 2010 + Sharepoint 2010 ein erheblicher Schritt nach vorn unternommen worden.

Weitere englischsprachige Anleitungen zu Visual Studio 2010 (mit Sharepoint 2010, Silverlight, WPF, Parallel Computing, Office Development, Workflow Foundation und vielen mehr) findet ihr hier.

Viel Spaß, ich hoffe und denke den werde ich auch haben;)

Zu finden ist dieser im “Team Explorer” (z.B. Visual Studio 2005/2008 öffnen) und das Team Explorer Fenster anzeigen (View > Team Explorer). Wenn man dort den TFS Server eingetragen hat, kann man den “Process Template Manager” unter “Team Foundation Server Settings” finden.

 
Process Template Manager starten

Im Manager kann man dann komplette Templates Hoch- und Runterladen sowie löschen.

Process Template Manager

Ein Prozess-Template besteht aus einer Reihe Ordner und Dateien (viel XML). Zum Anpassen eines Templates kann man z.B. ein vorhandenes (Standard-Template bei TFS Installation oder z.B. von Codeplex) in einen lokalen Ordner herunterladen und an der gewünschten Stelle mit Visual Studio bearbeiten.

Ordnerstruktur eines TFS Process Templates

Visual Studio unterstützt sowohl bei der Bearbeitung von Feldern, Layouts, Workflows und Workitem Typen. Das ganze kann man beliebig Komplex betreiben und ist sicher Inhalt vieler weiterer Blogeinträge, Artikel, …

 
TFS Process Template im Visaul Studio bearbeiten

Hat man nun seine gewünschten Änderungen vorgenommen lädt man das angepasste Template über den Process Template Manager wieder hoch (Auswahl des Ordners wo die “ProcessTemplate.xml” liegt). Zuvor sollte man die Bezeichnung des Templates anpassen. War der Upload erfolgreich kann man nun ein neues Projekt mit dem gewünschten Template anlegen.

Viel Spaß beim ersten anpassen eines Templates.

1. Im UnitTest eine WebReference zum Webservice einfügen:

2. Im UnitTest folgendes Attribut über der UnitTest-Methode einfügen:

[AspNetDevelopmentServer("TOServiceHost", 
		"%PathToWebRoot%\\Test.TOServiceHost")]

3. In der UnitTest-Methode den WebServiceHelper verwenden:

var sc = new TOService(); 
WebServiceHelper.TryUrlRedirection(sc, 
			TestContext,"TOServiceHost"); 
Assert.NotNull(sc.MyMethodForTest()); 

4. Im Visual Studio unter “Tools” > “Options” > “Test Tools” > “Test Execution” den Pfad eintragen:

Es kann passieren, das auf dem Client der Ordner zum Webservice nicht richtig aufgelöst wird. Dann kann man im VS einstellen, wo der Basisordner (%PathToWebRoot%) liegen soll. Den Ordner, wo der Webservice “Test.TOServiceHost” drin liegt den ihr testen wollt entsprechend einstellen.

5. In der .vsmdi Datei den Test in die Liste eintragen, die im Teambuild ausgeführt wird:

In der VSMDI Datei können dann alle UnitTests der Solution in eine Liste eingefügt werden:

Im Teambuild File wird die Liste aus dem VSMDI File angegeben, womit alle UnitTests dieser Liste auf dem Teambuild Server ausgeführt werden:

<MetaDataFile Include=
   "$(BuildProjectFolderPath)/../../Main/Source/Test/test.vsmdi">
   <TestList>AllTests</TestList>
</MetaDataFile>

In der Liste können jetzt auch Tests aufgeführt werden, die einen WebService aus der Solution aufrufen.

6. SolutionFile ggf. bearbeiten:

Wichtig ist, dass der Webservice bzw. die Webapplikation mit auf dem Server compiliert wird. Das kann z.B. über die Solution Configuration “Debug” sichergestellt werden. Wenn hier ein anderer Typ eingeführt wurde (z.B. “Debug_CodeAnalysis”) kann es passieren, dass die Website auf dem Server nicht unter “_PublishedWebsites” kompiliert/abgelegt wird. Dann funktionieren die UnitTests auf dem Server wieder nicht. Es bietet sich an den Solution-Typ “Debug” und für alle gewünschten Projekte (außer Webprojekte) einen anderen Typ z.B. “Debug_CodeAnalysis” zu verwenden:

7. Teambuild mit Codeanalysis, CodeCoverage und UnitTests:

Jetzt sind wir schon ziemlich weit gekommen und freuen uns das endlich unser Webservice um den es im Projekt zentral geht auch über UnitTests auf dem Team Build Server jeder Zeit (z.B. jede Nacht – Continuous Integration) getestet werden kann. Verwendet man nun alle Features die zum Team Build dazu gehören, wie Code Analysis und Code Coverage, wundert man sich doch recht schnell warum die Coverage Werte sehr niedrig sind. Ein kleine Recherche in den erzeugten Dateien und Reports ergibt, dass alle UnitTests die über den WebService gelaufen sind nicht im CodeCoverage auftauchen ;(… Das ist natürlich schlecht!!! Wenn ich aber die WebService-Methoden nicht über die WebReference sondern direkt teste fehlt mir wieder der HTTP-Context in den Tests.) Was ist hier nun die beste Lösung? Mocking vom HTTPContext und wieder ohne WebReference testen?

WordPress Tags: Team,Build,Webservice,UnitTests,PathToWebRoot,Test

–> öffnen der Testkonfiguration mit Wizard

–> Definieren von Dateien die für die UnitTests notwendig sind unter “Deployment”

Leider bietet der Wizard keine Möglichkeit einen Unterordner/Zielordner mit anzugeben. Dazu muss man das “.testconfig” File im XML-Editor öffnen und selbst am DeploymentItem-Tag herumeditieren. Dort steht einem nun das Attribut “outputDirectory” zur Verfügung.

<Deployment>
  <DeploymentItem filename="log4net.conf.xml" 
    outputDirectory="config" />
  <DeploymentItem filename="myentlib.config" />
</Deployment>

–> .testconfig File im XML-Editor

Der zweite Ansatz ist über ein Attribut im Testcode selbst zu definieren welche Dateien für den Test notwendig sind:

DeploymentItems (DeploymentItemsAttribute bei MSDN)

[TestMethod()]
[DeploymentItem("config\\log4net.conf.xml", "config")]
public void MyTest()
{
    ...
}

–> DeploymentItemAttribut im Code

DeploymentItems und TFS Team Build:

Leider hat man nun das nächste Problem mit den DeploymentItems und UnitTests im Zusammenhang mit Teambuild. Auf dem Teambuild Server können die UnitTests nur ausgeführt werden, wenn Visual Studio installiert ist. Das VS2008 hat hier wohl einen Bug, denn er sucht die für den UnitTest definierten DeploymentItems nicht im Ordner wo die Tests ausgeführt werden, sondern im Ordner wo Visual Studio auf dem Teambuild Server installiert ist (System.Configuration.ConfigurationErrorsException: The configuration folder ‚D:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\config\log4net.conf.xml‘ doesn’t exist).

Geholfen hat jetzt nur ein Workaround im Testcode:

[ClassInitialize()]
public static void MyClassInitialize(
  TestContext testContext)
{
    AppDomain.CurrentDomain.SetData("APPBASE", 
     Environment.CurrentDirectory);
}

–> Bei jedem UnitTest in der Initialisierung einzufügen (Forum post hier)

Team Build – Code Coverage – Partially Succeeded

Manchmal kommt es trotz erfolgreichen Build und auch erfolgreichen durchführen aller UnitTests zu dem Status “Partially Succeeded”.

–> “Partially Succeeded” trotz erfolgreichem Build und no failed UnitTests ?!

Ein bisschen Nachforschung bringt einen dann auf den Pfad, dass es ein paar Warnungen gegeben hat, die man auch Abarbeiten kann. Man lädt sich die Testresults auf den lokalen Rechner (Link unter “Test Run” anklicken) und arbeitet die Warnungen ab. Zum Beispiel will Code Coverage zwingend x86 dlls (siehe auch hier). Weiterhin müssen alle dlls die im Code Coverage eingeschlossen sind auch verfügbar sein. Code Coverage wird übrigens auch in der .testconfig Datei definiert und kann mit dem Wizard (siehe oben im Artikel) eingerichtet werden.

• GhostDoc (Dokumentation von Sourcecode)
• ReSharper (Refactoring, Code Analyse, Produktivität, Qualität)
• Guidance Automation Toolkit für Visual Studio 2008 
• Guidance Automation Extension und ein Update dazu
• Software-Factories
  • Web Service Software Factory Modeling Edition
  • Smart Client Software Factory
  • Web Client Software Factory
  • Mobile Client Software Factory
• Silverlight Tools for Visual Studio 2008 SP1 siehe auch Silverlight Seite
• Silverlight Sidebargadget Projektvorlage mit Erläuterung
• Für Subversion – VisualSVN, TortoiseSVN, AnkhSVN
• Visual Studio Team System Management Model Designer Power Tool
• Visual Studio® 2008 Web Deployment Projects mit Erläuterungen
• Visual Studio 2008 Team Explorer und Visual Studio 2005 Team Explorer
• Visual Studio 2005 Team Foundation Server MSSCCI Provider und Visual Studio 2008 Team Foundation Server MSSCCI Provider
• Visual Studio Team System 2008 Team Foundation Server Power Tools – Oktober 2008 Release und Microsoft Visual Studio 2005 Team Foundation Server Power Tools – September 2007 release
• Enterprise Library 4.1 – Oktober 2008 (Sammlung wiederverwend-barer Codeblocks)
• StyleCop (Source Code Style Analyse)