Archive for the ‘VSTS’ Category

h1

Microsoft Process Template (MPT) mit TFS2010

Juni 4, 2010

Microsoft hat auf Codeplex ein Template zur Verfügung gestellt, dass für Visual Studio Team System 2008 (VSTS) eine hierarchische Abbildung von Work Items ermöglicht. Mit TFS 2010 wird die Hierarchie nun aber von Haus aus unterstützt und somit ist mit Sicherheit eine Reimplementierung dieses Templates notwendig. Zur Zeit steht aber weder dieses Template auf Codeplex zur Verfügung noch, dass es Infos zu diesem Template im Zusammenhang mit TFS 2010 existieren.

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)
    image
    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

    image

    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.

h1

Visual Studio 2010, TFS 2010 Linksammlung

Januar 27, 2010

Hier ein paar gesammelte und kategorisierte Links zum Thema TFS 2010, Visual Studio 2010.

Links | Guidance, best practices

Links | Entwicklung

Links | Infrastruktur

Links | Installation

Links | Blogs

h1

TFS 2010 Beta 2 Installation – Advanced Scenario

Dezember 2, 2009

Vor ein paar Tagen hatte ich ja schon kurz vom TFS 2010 Beta 2 berichtet. Jetzt kann ich auch ein paar Details berichten.

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.

h1

Neues von der 2010er Welle – TFS2010, SharePoint 2010

Oktober 19, 2009

Heute ist nun nach langem Warten endlich die Beta 2 (mit “Go live” Lizenz) des Microsoft Team Foundation Servers 2010 veröffentlicht worden. Auch das Lizenzmodell und die Bezeichnungen der Visual Studio 2010 Versionen haben sich geändert. Sie heißen jetzt:

  • 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;)

h1

Team Foundation Server – Prozess Template anpassen

Juli 27, 2009

Wer sich schon immer gefragt hat wie man das Prozess Template anpassen kann kommt auf keinen Fall am “Process Template Manager” des TFS vorbei.

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.

processtemplatemanager 
Process Template Manager starten

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

processtemplatemanager1
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.

processtemplatemanager2
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, …

processtemplatemanager3 
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.

h1

TFS Team Build: Testen von Webservices mit UnitTests auf dem Client und Team Build Server

Februar 26, 2009

Damit ein UnitTest, den wir gegen einen WebService (z.B. TOService) ausführen auch auf dem Team-Build Server läuft sind folgende Schritte notwendig:

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

image

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.

image 

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:

image

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:

 image

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?

image

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

h1

UnitTests, automatische Tests mit TFS 2008

Januar 23, 2009

Fast immer benötigt man für das Ausführen von UnitTests eine Umgebung wie im wirklichen Leben. Es sind also auch z.B. Konfigurationsfiles an einem bestimmten Ort (wie z.B. in einem Unterordner “config”) notwendig. Die Visual Studio UnitTests werden aber in einem eigenen Ordner ausgeführt und genau dort braucht man nun auch diesen Unterordner mit seinen Dateien. Hier gibt es im großen und ganzen zwei Ansätze. Entweder man konfiguriert die Testkonfiguration (siehe 2 Abbildungen):

image
–> öffnen der Testkonfiguration mit Wizard

image
–> 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”.

image

–> “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.