Archive for the ‘VS2008’ Category

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.

h1

Visual Studio AddOns, AddIns, Plugins – Links

November 10, 2008

Das nackte Visual Studio 2005 und 2008 ist schon ganz nett, aber wenn man dann noch das ein oder andere Plugin installiert wird es ein super Tool. Die meisten der Plugins sind sowohl für Visual Studio 2005 als auch 2008 verfügbar. Die meisten davon verwende ich oder habe ich zumindest schon ausprobiert. Die Reihenfolge gibt keine Aussage über die Wertigkeit oder häufigkeit der Verwendung (wobei Ghostdoc und ReSharper schon zu meinen Lieblingen zählen;) Die Liste ist mit Sicherheit nicht vollständig, aber das ändert sich sowieso ab und zu, wie man auch an dem Inhalt eines früheren Artikels von mir sieht.

h1

TFS – Verwenden von Areas und Iterations

Oktober 29, 2008

 

Die Einstellung für Iterations und Areas findet man zum Beispiel im Team System Web Access nach Auswahl des entsprechenden Team Projektes unter Settings > Team Project

image

Iterations bieten sich an für die Verwendung von geplanten Releases. So kann man Scenarien, Tasks, Bugs usw. schön einem Release zuordnen. Sie können auch als „Sprint“ verwendet werden.

image

Areas können verwendete werden um die Aufgaben (Scenarien, Tasks, Bugs, usw.) einem bestimmten Teil des Projektes zuzuordnen. So kann man zum Beispiel Areas für die einzelnen Schichten einer Applikation (Frontend, Backend, Datenbank, …) oder auch für Bereiche die mit Code nix zu tun haben (Konzepte) verwenden.

image

Die Areas und Iterations lassen sich nun sehr komfortabel in entsprechende Queries einbauen. Damit lassen sich die Aufgaben (Scenarien, Tasks, Bugs, usw.) entsprechend Releases und Bereichen zuordnen und der Überblick bleibt auch bei größeren Projekten vorhanden.

image

Die angelegten Queries lassen sich dann auch für den Entwickler beim CheckIn im Visual Studio auswählen.

image

h1

Basta 2008 Spring

März 3, 2008

 

Ich durfte mal wieder dabei sein auf der Basta 2008 Spring Edition und habe doch einige interessante Vorträge gesehen. Der wohl beste Vortrag der mir im Gedächtnis bleiben wird hatte gar nichts mit .NET zu tun, sondern mit Zeitmanagement und wurde von Torsten Weber mit dem Thema „(Keine) Zeit für Herzrasen!“ gehalten. Die Folien und einen Blogeintrag dazu gibt es hier.

Ansonsten habe ich mir einige Themen des VSTS angeschaut und Informatio-nen dazu gesammelt, wie wir unseren TFS 2005 auf TFS 2008 upgraden und die vielen Möglichkeiten besser einsetzen können. Dazu hat u.a. Christian Binder einiges erzählt, wobei man wieder mal das Release von „Rosario“ nicht erwarten kann. Zum Thema Hierarchische Workitems kann vorerst nur ein 3rd Party Tool von http://www.artiso.com Abhilfe schaffen. Dazu findet sich auch ein Blogeintrag auf Christian Binders blog.

Weitere Folien einiger Vorträge der Basta findet man:

  • bei Thomas Schissler (Qualitätsmanagement mit VSTS, Programmier-ung mit dem TFS SDK)
  • Daniel Walzenbach (ASP.NET Model View Controller, Visualisierung von Geodaten mit Virtual Earth)
h1

.NET 3.5 – Neuerungen bei C#3.0 – Teil 9 von 9

März 1, 2008

Die Überraschung

Bei meinem ursprünglichen ersten Blick auf .NET 3.5 dachte ich ich könnte die neuesten und interessantesten Features in einer 8 teiligen Serie darstellen. Bei der Bearbeitung viel mir allerdings auf, dass es an manchen Stellen sinnvoll war schon Features in anderen Teilen mit zu besprechen. Am Ende hatte ich auf einmal nur noch 7 Teile die zu dem Thema waren. Um die Serie nicht früher abzubrechen habe ich mich noch mal umgeschaut und einige weitere Interessante Themen, die mit der Einführung von .NET 3.5 zu tun haben. Da sind zum Beispiel das neue Visual Studio 2008 – warum soll ich umsteigen, was ist neu, was sind die Killer-Features, wann sollte ich nicht umsteigen. Weiterhin werde ich auch nochmal einen kurzen Schritt zurück gehen und nochmal ein paar grundlegende Worte zu .NET 3.5 im Verhältnis zu .NET 2.0 erzählen – was von den neuen Sprachfeatures geht denn auch mit .NET 2.0? Das Thema VSTO hat mich in Verbindung mit VS 2008 ebenfalls interessiert und wird sicher auch einige andere begeistern.

Fange ich mal mit VSTO an. Zusammen mit Visual Studio 2008 wird auch VSTO3.0 mit ausgeliefert. VSTO3.0 geht ab der Visual Studio 2008 Professional Version vollständig in Visual Studio auf und beendet den wirrwarr der bisher vorhandenen VSTO-Versionen. Mit dem neuen Visual Studio 2008 können alle Projektvorlagen für Office 2003 und Office 2007 verwendet werden. Das macht es den Entwicklern natürlich deutlich einfacher. Auf die einzelnen weiteren Neuerungen gegenüber den anderen Versionen will ich hier trotzdem nicht eingehen. Eine will ich trotzdem erwähnen, die Verwendung der Ribbons ist Dank eines Designers  nun deutlich intuitiver.

Was ist denn nun .NET 3.5 im Verhältnis zu .NET 2.0 und welche der beschriebenen Features kann ich denn nun mit .NET 2.0 auch nutzen? Eines ist gegenüber der Erweiterung von .NET 3.0 bei .NET 3.5 gleich geblieben, es wird weiterhin die BCL des .NET 2.0 verwendet. Streng genommen sind wir also immer noch bei .NET 2.0. Mit den Erweiterungen von .NET 3.0 und .NET 3.5 kam es mittels zusätzlicher Assemblies zu einer Funktionserweiterung (WPF, WCF, WF … um nur die bekanntesten von .NET 3.0 zu nennen). Mit .NET 3.5 ist weiterhin ein SP für .NET 2.0 und .NET 3.0 hinzugekommen. Man sollte also aufpassen, wenn man Klassen aus dem Servicepack verwendet, das dieses auch auf der Wirkumgebung vorhanden ist. Mit .NET 3.5 ist zusätzlich ein neuer Compiler hinzugekommen, der die ganzen Spracherweiterungen ermöglicht. Es ist damit kein Problem alle Spracherweiterungen, die keine mit .NET 3.0 oder .NET 3.5 hinzugekommen-en Funktionen verwenden auch mit .NET 2.0 einzusetzen. Der Compiler „trickst“ und wandelt den Code in BCL 2.0 verständlichen Code um. Es muss lediglich der neue Compiler (am besten Visual Studio 2008 verwenden) eingesetzt und das .NET 2.0 als Zielplattform ausgewählt werden. Bei der Verwendung der Extension-Methoden wird der Compiler allerdings die „System.Core.dll“ vermissen, die erst mit .NET 3.5 dabei ist. Da es nur ein Attribut ist das fehlt, kann das im entsprechenden Namespace einfach selbst angelegt werden und die Compilierung sollte funktionieren. Beispiel hier.

namespace System.Runtime.CompilerServices
{
    public class ExtensionAttribute:CustomAttribute
    {
    }
}

Mit der Einführung von Visual Studio 2008 ist das erste Visual Studio verfügbar, dass für mehrere .NET Versionen verwendet werden kann. Ich Denke das ist schnell einleuchtend wenn man bedenkt, dass für .NET 2.0/3.0/3.5 ein und die selbe BCL verwendet wird. Es handelt sich also nicht wie beim Sprung zwischen .NET 1.1 und .NET 2.0 um eine Änderung der BCL. Ich frage mich also, wozu ich noch Visual Studio 2005 verwenden soll, sobald ich Visual Studio 2008 in den Händen habe. Bis heute ist mir noch kein entscheidender Grund eingefallen VS 2005 weiter zu verwenden. Zu bedenken sind nur die Fragen, ob alle Projektvorlagen und VS Erweiterungen die ich nicht entbehren kann vorhanden sind. Als nächstes sollte man bei der Arbeit im Team darauf achten, dass am besten alle gleichzeitig auf die neue VS 2008 Version umsteigen, damit die neuen Solution-Files von allen verwendet werden können. Es ist sogar möglich den TFS 2005 auch mit VS 2008 und dem zugehörigen Team Explorer weiter zu verwenden.

^ Teil 1: Übersicht aller Neuerungen (Einleitung)

< Teil 8: Was geht mit Silverlight