Vor kurzem wurde von einigen renommierten Softwareentwicklern und –architekten ein Blogpost von Derek Hammer via Twitter verbreitet, in dem Derek feststellt, dass sich der Team Foundation Server zerstörerisch auf unsere Entwicklungskapazitäten auswirkt.

Neben der generalisierten Aussage “TFS Sucks” geht Derek allerdings auch im Einzelnen auf die Standbeine des Microsoft ALM Werkzeuges ein: Version Control, Bug Tracking, Project Management, Build System und Integration.

Während ich einige seiner Kritikpunkt nachvollziehen kann, sehe ich andere wiederum eher kritisch. Mein Feedback auf Twitter, es handele sich hier um gefährliches Halbwissen zog entsprechend die Nachfrage von Ralf Westphal nach sich, ob ich argumentativ den TFS “gebührend zu einem Pfau der technischen Führerschaft und Offenheit” machen könne. Obwohl es nicht meine Absicht war, den Eindruck zu erwecken, es handele sich beim Team Foundation Server um einen Pfau (ganz gleich ob führend oder offen), habe ich natürlich nichts dagegen, dennoch einige Halbwahrheiten näher zu beleuchten.

Version Control

Der größte Kritikpunkt scheint hier der zentralisierte Ansatz der Versionskontrolle zu sein. Bevor aber die eher subjektive Beantwortung der Frage danach, was möglicherweise besser sei gesucht wird (zentralisiert wie TFS oder dezentralisiert wie z.B. Git), macht es Sinn, sich zu überlegen, was denn überhaupt u.a. das Ziel einer Versionskontrolle ist.

1. Die Arbeit am Quellcode muss runter vom lokalen System
2. Der Quellcode muss für andere Entwickler verfügbar und lokalisierbar sein
3. Änderungen am Quellcode müssen einfach nachvollziehbar sein
4. Änderungen müssen einfach zusammengeführt werden können

Dezentrale, oder: Verteilte Versionskontrolle fördert die lokale Arbeit, da keine Verbindung zum Server notwendig ist. Während dieser Ansatz auf der einen Seite natürlich die Arbeit (für den Einzelnen) vereinfacht (da er immer und überall arbeiten kann ohne sich über seine stabile und hoffentlich performante Internetanbindung Gedanken machen zu müssen), frage ich mich auf der anderen Seite wiederum, welche Entwickler das sind, die sich überhaupt darüber Gedanken machen müssen?

Derek erklärt in dem Kontext, die Arbeit im Umfeld des TFS würde vollständig zum Erliegen kommen, wenn das Netzwerk mal für eine Stunde ausfällt. Das ist nicht korrekt, denn der TFS unterstützt die Offline-Arbeit an den Sourcen. Dazu wird bei fehlender Netzwerkverbindung in den Offline-Modus geschaltet und sobald das Netzwerk wieder verfügbar ist, kann der Entwickler wieder Online gehen und bekommt eine automatische Übersicht, die ihm zeigt, ob es an den bearbeiteten Dateien auf dem Server in der Zwischenzeit Änderungen gegeben hat, die er gleich zusammenführen kann. Komfortabler geht es nicht.

Derek kritisiert auch, dass alles im Team Foundation Server gemacht werden müsse. Obwohl er seit mehreren Jahren den TFS nutzt und dennoch mehrmals im Text darauf hinweist, dass er dieses und jenes nicht wirklich kommentieren könne, da er sich damit nicht auskenne, kritisiert er trotzdem einige Punkte, zu denen ihm wohl noch gar nicht aufgefallen ist, dass er nicht weiss, wovon er spricht.

Das letzte Mal, als ich nachgeschaut habe, konnte ich die Quellcodeverwaltung aus

• dem Windows Explorer heraus verwenden (mittels Shell Extension aus den TFS Powertools)
• der Powershell Konsole heraus mittels Cmdlets steuern (ebenfalls mittels TFS Powertools)
• der Kommandozeile heraus  benutzen (via tf.exe)
• dem Team Explorer Everywhere sogar aus Eclipse heraus bedienen und
• natürlich dem regulären Team Exporer heraus nutzen.

Es gibt bestimmt noch mehr. Da Microsoft ein SDK dazu zur Verfügung stellt, würde es mich zumindest nicht wundern.

Derek kritisiert auch, dass das Standard Merge Tool nicht seinen Ansprüchen genügt. Ehrlich gesagt, bin ich häufig ebenfalls nicht zufrieden mit dem Merge Tool. Es scheint genügend Entwickler gegeben zu haben, die das entsprechende Feedback geliefert haben, denn ein Microsoft Vögelchen hat mir gezwitschert, das es mit Visual Studio vNext etwas Besseres geben wird.

Und… wem ist es aufgefallen? Ich habe geschrieben Visual Studio vNext. nicht Team Foundation Server vNext. Compare & Merge finden nämlich auf dem Client statt. Das hat in erster Instanz nichts mit dem Team Foundation Server zu tun.

Vermutlich gibt es deshalb auch so viele alternative Möglichkeiten, Dateien miteinander zu vergleichen und Änderungen zu integrieren. Einige davon integrieren sich ziemlich gut in die UI vom Visual Studio wie z.B. Code Compare, während andere wie z.B. WinMerge extern und somit auch prima über die Explorer Shell arbeiten. Visual Studio macht es nämlich einfach möglich, anzugeben, mit welchem Tool man vergleichen und integrieren möchte. Hat Derek das etwa übersehen?

Diese Art der Kritik, die aus Halbwahrheiten besteht, um falsche Argumente zu untermauern, grenzt an Polemik. Dazu passt auch Dereks Aussage: Einige [Probleme] sind ziemlich erschreckend (wie z.B. verloren gegangene Checkins), ich persönlich bin ihnen aber noch nicht begegnet.”. Erinnerungen an Heise Posts und Reaktionen darauf (Don’t feed the Trolls) drängen sich dabei förmlich auf.

Bug Tracking

Die Überschrift selbst ist eigentlich schon verkehrt. Der Team Foundation Server beinhaltet kein Bug Tracking sondern ein Work Item Tracking. Einer der von Haus aus vorhandenen Work Item Typen nennt sich “Bug”. Man mag es nicht für möglich halten, aber sogar Entwickler finden manchmal Fehler. Darüber hinaus ist sich Microsoft der Tatsache bewusst, dass es viele existierende Lösungen gibt, die sich mit dem Thema Bug Tracking beschäftigen. Sobald ein Entwickler seine Kunden Fehler melden lässt muss daher unterschieden werden zwischen der externen und der internen Kommunikation.

Extern nutzen viele die unterschiedlichsten Lösungen (bis hin zu CRM Systemen, da es sich ja um Kundenkommunikation handelt). Intern wiederum geht es rein um die Kommunikation der Entwickler unter sich. Und der geneigte Leser wird mir zustimmen: Diese Kommunikation sollte i.d.R. nicht unbedingt öffentlich gemacht werden.

Dank der Tatsache, dass das Work Item Tracking genau wie alle anderen Services des Team Foundation Servers über sehr gut dokumentierte Webservices funktioniert, ist es daher meist möglich, externe Systeme anzubinden, um eine Brücke zwischen der Kundenkommunikation und der internen Entwicklerkommunikation (sprich: Status des Work Items) herzustellen.

Aber selbst wenn kein externes System zur Verfügung steht und der Entwickler überlegt, die Boardmittel für Kunden nutzbar zu machen, gibt es die Möglichkeit, Team Foundation Web Access im Work Item Only Modus bereitzustellen. Und wer denkt, ein Kunde wäre nicht in der Lage die vielen Felder auszufüllen, der passe bitte sehr den Work Item Typen einfach an.

Denn auch das scheint bisher noch niemand Derek erzählt zu haben: Work Item Typen, deren Aufbau, die Informationen, die sie aufnehmen und der Workflow dahinter lassen sich mittels Editor anpassen, selbst erstellen und beliebig integrieren. Ich weiß z.B. von der Existenz einer Microsoft CRM Erweiterung und auch einem Outlook Addin für eingehende (Bug-) Emails.

Project Management

Ich muss ehrlich gestehen, dass ich diesen Punkt nicht ganz verstanden habe. Das mag aber auch daran liegen, dass ich selbst die Möglichkeiten des Team Foundation Servers in diesem Kontext bisher eher stiefmütterlich behandelt habe.

Im Wesentlichen erklärt Derek hier, seine Projekt Managerin würde Excel als Tool bevorzugen, da es ihr besser gefalle als der TFS. Darüber hinaus weist er darauf hin, dass sich in der agilen Softwareentwicklung konstant der Entwicklungsprozess ändern würde und diese Tatsache nur unzureichend komfortabel vom TFS untersützt würde.

Gründsätzlich würde ich es anders formulieren. Wem die umfangreichen Möglichkeiten, Projekttemplates (aus meiner Sicht sehr wohl komfortabel) anzupassen und mit Standardmitteln Reports zu entwickeln und über die Analysis Services sowohl via Web als auch über beispielsweise Excel einfach zur Verfügung zu stellen, nicht ausreichen, der ist – wie Derek selbst sagt – ja nicht dazu gezwungen, den TFS zu benutzen.

Er vergisst allerdings auch die Möglichkeit zu erwähnen, zu einem Projekt Kickoff beispielsweise unglaublich komfortabel in der Lage zu sein, Work Items via Excel anzulegen oder basierend auf den erfassten Informationen und der Integration in z.B. Microsoft Project selbiges für eine standardisierte Projektverwaltung nutzen zu können.

Dass es das flexible System des TFS und der Erweiterungsmöglichkeiten erlaubt, beispielsweise auch Word anzubinden, eigene Ribbons zu gestalten und Vorlagen zu entwerfen, die direkt an Daten aus dem TFS gebunden werden können, erwähnt Derek auch mit keinem Wort. Übrigens auch nicht im später folgenden Absatz über Integration.

Build System

“TFS will build every checkin […]”. So fangen auch die meisten Produktwerbungen an. Fliegen macht Spaß, das Waschmittel wäscht weißer als alle anderen und mit diesem Mittel wird magisch jede Kruste in perfekten Glanz verwandelt.

Der Ehrenrettung halber sei erwähnt, dass Derek diese Aussage im folgenden Abschnitt einschränkt, darauf hinweist, dass diese Funktion lediglich eingeschaltet werden kann und dann die wirkliche Kritik äußert: Das Entwickeln eines benutzerdefinierten Build-Steps sei enorm aufwändig.

Was ich dann schon eher lustig finde, ist, dass viele andere Build Systeme sich damit brüsten, dass sie besonders einfach zu handhaben wären. Häufig kommen simple Scripte zum Einsatz. Wozu sollte man auch ein C# Projekt vom Start treten, wenn die Ausgabe lediglich gezippt werden muss.

Mal abgesehen davon, dass es eine schier endlose Zahl bereits fertiger Tasks gibt, die eine große Vielfalt an Themen mittels vorgefertigter Activities abbildet, lassen sich in eine Build Sequenz auch Skripte einbauen. Wozu also die Aufregung? Wer aber tatsächlich selber Activites entwickeln möchte (oder vielleicht sogar muss), der findet im Wissenskollektiv diverse Anlaufstellen, die einem die Basis dafür vermitteln. Hier z.B. die vollständigste und dabei gleichzeitig einfachste Einführung zum Thema Customizing Team Build 2010 von Ewald Hoffman.

Derek ist ebenfalls davon überzeugt, dass das TFS Build System nicht zur Continuous Integration tauge, da es eine Strong Pipeline benötige, was der TFS nicht biete. Was genau er damit meint,… diese Erkenntnis bleibt er dem Leser schuldig.

Dafür vergisst er aber gewohnt wiederkehrend, zu erwähnen, zu was das Build System des TFS noch alles zu gebrauchen ist. Weder scheint er zu wissen, dass es in der Lage ist, Unit Tests zu automatisieren, neue Work Items bei Build Fehlern anzulegen, die Build Ausgabe in virtuelle Testsysteme zu deployen, die Konfiguration des Builds komfortabel in einer konfigurierbaren Oberfläche anzubieten, private Builds zu erstellen, und und und. Und was die Agenten, die er nur im Nebensatz erwähnt, noch alles drauf haben, darauf geht Derek sowieso nicht ein (z.B. Tags).

Integration

Derek kritisiert hier im wesentlichen zwei Punkte.Zum einen, dass der TFS es nicht erlaube ein alternatives Versionierungssystem einzusetzen und zum anderen dass das Build System nicht ausgetauscht werden könne.

Da hat er natürlich vollkommen recht. Diese Praxis unter Produktherstellern ärgert mich auch zunehmend. Ich habe ebenfalls kein Verständnis dafür, dass Word nicht den Editor von Open Office verwenden kann, der Windows Explorer nicht unter Ubuntu verfügbar ist und wieso der integrierte Quellcode Editor im Visual Studio nicht durch VIM ersetzt werden kann entzieht sich auch meiner Kenntnis.

Aber aller Sarkasmus beiseite: Soweit ich weiss gibt es Plugins, um z.B. Hudson und Cruise Control.NET (beides beliebte Build Systeme) in den TFS zu integrieren (oder andersherum…).

Worum es hier aber wirklich geht ist natürlich die TFS Integration Tools. Diese sollen dazu dienen, zwischen veschiedenen Versionskontrollsystemen Daten auszutauschen und zu synchronisieren. Von Haus aus werden neben dem TFS 2010 und 2008 auch Adapter für Rational ClearCase und Rational ClearQuest mitgeliefert sowie ein Adapter für dateibasierte Versionskontrollsysteme. Mich erinnert das ein wenig an ein Strategiepapier von Joel Spolsky (“Let me go back!” Unbedingt lesen!)

Zusammenfassung

Es gibt noch diverse andere Punkte in Dereks Text, die schlicht falsch sind. Der Team Foundation Server zwingt einen nicht, Checkins mit Work Items zu verknüpfen. Aber man kann es sehr wohl optional einschalten (und selbst dann gibt es eine Override Checkbox). Es gibt auch keine strengen Vorlagen, denen man folgen muss. Aber es werden Vorlagen angeboten, die man benutzen kann und/oder beliebig seinen Vorstellungen anpassen. Alle Punkte, von denen Derek implizit in seiner Zusammenfassung behauptet, der TFS biete sie nicht an, sind im Gegenteil genau so entweder in der Basisinstallation vorhanden oder konfigurierbar.

Derek bevorzugt offensichtlich Produkte, die so wenig an Standards mitbringen, dass der Entwickler wirklich alles selbst einrichten, konfigurieren, erstellen, etc. muss und dabei gezwungen wird, im Prinzip zu erlernen, wie er grundsätzlich selbst ein ALM Werkzeug entwickelt. Er schreibt: “[…] the organization can trick itself into thinking that configuration management is a solved problem.”. Ganz klar ist das die Schuld des Team Foundation Servers.

Nein. Natürlich nicht. “This is not only TFS's fault, though.”.

Während ich seinen Punkt durchaus verstehe, fällt mir dabei natürlich der viel zitierte Spruch ein: “Don’t reinvent the wheel!”. Besser noch gefällt mir der Zusatz, den ich zuerst bei einem Kollegen von Joel gelesen habe: “[…] you shouldn't reinvent the wheel. Unless you plan on learning more about wheels, that is.” (Jeff Atwood, 2009).

Daher ist es auf jeden Fall besser, schneller und einfacher, alle Dienste, Anbindungen an Drittsysteme, Basiskonfigurationen (dazu gehören auch Linux Systeme und wie wir wissen, gibt es die ja in jeder Organisation), Versionskontrollen, Build-Systeme und das Projektmanagement aus bunten Puzzleteilen manuell selbst zusammenzubauen. Damit schließt sich der Kreis und Derekt hat eindrucksvoll unter Beweis gestellt, dass der Team Foundation Server in der Tat Entwicklungskapazitäten zerstört.

Q.E.D.

Zumindest, wenn es einem darum geht, etwas über ALM Werkzeuge zu lernen und weniger darum, Software effizient zu entwickeln.

Reaktion, Team Foundation Server, Visual Studio

...kann man ja eigentlich nicht sagen, denn mit der BASTA! Spring 2011 ist die letzte Konferenz schon eine Weile her. Interessant ist nun aber die Teilnahme an der dotnetpro DevCon in Nürnberg dieses Jahr, da TOP TECHNOLOGIES die Gelegenheit hat, das Thema VM Factory dem breiten Publikum dort persönlich vorzustellen.

Bereits in den Ausgaben 4 und 5 der dotnetpro wurden von uns dazu zwei Artikel veröffentlicht, die aufzeigen, wie ein Entwickler mit einfachen Mitteln die Installation eines Team Foundation Server 2010 voll durchautomatisieren kann. Basierend auf Trial Versionen der Produkte, die Microsoft kostenlos anbietet, und in Kombination mit Infrastrukturtools, die Microsoft ebenfalls kostenlos anbietet sogar sehr günstig.

Sobald man einmalig die Arbeit in den Aufbau eines solchen Systems gesteckt hat, geht das Produzieren eines virtualisierten TFS 2010 inkl. aller notwendigen Prerequisites auf Knopfdruck und setzt die eigene Anwesenheit nicht voraus. Kurzum: Man kommt schneller zum Ziel und hat mehr Zeit für das Wesentliche: Denn unter uns gesagt... die IT Infrastruktur ist i.d.R. nicht DAS Know-How Gebiet eines Softwareentwicklers.

Ich hoffe, das Publikum auf der DevCon wird seinen Spaß an dem Vortrag haben und neue Ideen mitnehmen können. In den nächsten Tagen werden wir hier auch die Präsentation selbst veröffentlichen.

Ankündigungen, Team Foundation Server, TOP TECHNOLOGIES devcon

Viele von uns kennen das: Ein Kunde schickt uns eine Email mit Informationen zu einem Fehler, den er in unserer Software gefunden hat. Oder eine Anforderung für eine Software, die es zu entwickeln gilt. Worum auch immer es sich handelt, die Frage, die wir uns jetzt stellen lautet: Wohin mit dieser Email? Während sich aus der Email i.d.R. direkt eine Aufgabe ableitet, betrifft diese allerdings meist die Softwareentwicklung. Die Rückmeldung zum Status der Aufgabe oder das Ergebnis selbst regelt aber wiederum der Kundenkontakt. Wir sprechen also von zwei verschiedenen Welten, die es miteinander zu vereinen gilt: Nach draußen der Kunde, nach drinnen die Softwareentwicklung.

Genau diesen Spagat weiß das Outlook Addin eXtremeEmails der australischen Firma SSW zu meistern. Es setzt auf Outlook auf und nutzt es, um Entwicklungsaufgaben aus einer gewohnten Oberfläche heraus zu verwalten und darüber hinaus - wenn gewünscht - auch mit einem vorhandenen Microsoft Team Foundation Server zu verbinden. Das Addin ist kostenlos und wird begleitet von Einführungsvideos, Assistenten und ausführlicher Dokumentation. Wer sich schon immer gefragt hat, wozu man aus einem Program heraus, in dem sowieso die ganzen Aufgaben eintreffen, immer in andere Programme zur Verwaltung wechseln sollte, der wird hier u.U. eine Lösung finden.

Team Foundation Server outlook

Zu verschiedenen Theman lassen sich im Internet verschiedene Lösungsansätze finden. Was aber, wenn sich ein Thema zusammensetzt aus verschiedenen Puzzleteilen? Dann bleibt einem häufig nichts anderes übrig, als sich Lösungs-Puzzleteile zu verschaffen, die Verzahnung mit einer Feile passend zu schleifen und zu hoffen, dass das Gesamtbild noch dem entspricht, was auf der Spezifikation Verpackung (um der Analogie treu zu bleiben) abgebildet war.

Ziel ist es, eine Solution, die aus mehreren Projekten besteht, mittels Team Build automatisch bauen zu lassen und dabei in der Drop-Location nicht alle Binaries in einem einzigen Verzeichnis zu erhalten sondern in einer vorgegebenen Verzeichnisstruktur, die nach Projekten getrennt eine gewisse Übersichtlichkeit bietet. Neben Konsolen- und Winform-Anwendungen befinden sich darunter auch Web-Anwendungen. Daraus ergeben sich drei Teilprobleme:

1. Bauen mehrerer Projekte innerhalb einer Solution
2. Erhalt einer Verzeichnisstruktur
3. Team Build und Web-Anwendungen

 

Während sich der erste Punkt leicht selbst herausfinden lässt, fängt es bei zweiterem an, kompliziert zu werden. Zum Glück hat Aaron Hallberg dazu eine Beschreibung parat, die aufzeigt, wie eine Verzeichnisstruktur erhalten werden kann. Seit Orcas (Team Foundation Server 2008) gibt es in der Team Build Konfiguration die Eigenschaft CustomizableOutDir, über die gesteuert werden kann, dass das Zielverzeichnis vom Benutzer konfiguriert wird:

 

In dem Moment, in dem diese Eigenschaft gesetzt ist, schleift Team Build die Standardeinstellung nicht mehr in die Eigenschaft OutDir durch. Jetzt muss sie entsprechend selbst in den Projekt-Dateien konfiguriert werden (wobei das jeweilige Projekt natürlich sowohl weiterhin lokal als auch über Team Build gebaut werden können muss):

 

Befindet sich unter den Projekten auch eine Web-Anwendung, dann scheitert Team Build in dem Moment an der Aufgabe, wenn die Web Deployment Projects hinzukommen. Hintergrund ist, dass die WDP die Ausgabe der Web-Anwendung im bin-Verzeichnis erwarten, sie nach dem Team Build Prozess dort aber nicht zu finden sind.

Aaron zeigt in seinem Blog ebenfalls, wie dieses Problem gelöst werden kann, wobei der V1-Ansatz auch mit Orcas funktioniert. Genau wie oben lässt sich dann über die OutputPath Eigenschaft in dem WDP-Projektfile die Verzeichnisstruktur für die Drop Location festlegen.

Team Foundation Server, Visual Studio, Team Build team build, web deployment projects, orcas

Wer neu ist im Umgang mit dem Team Foundation Server, sieht sich häufig mit Fragen konfrontiert wie "Wie funktioniert Branching?", "Warum muss ich regelmäßig mergen?", "Wie baue ich meine Software automatisiert mit Team Build?", "Wie kann ich dafür sorgen, dass die Versionsnummern der Assemblies automatisch inkrementiert werden beim TeamBuild?". Bei der letzten Frage spätestens sollte jedem klar sein: Das bedarf einiges an Experimenten... und das will nicht so recht zu einer produktiven Umgebung passen.

Seit Weihnachten 2008 gibt es dafür eine Lösung. Brian A. Randell hat Ende letzten Jahres einige VPC-Images für Microsoft entwickelt, die eine komplette Team Suite mit allem beinhalteten, was das Entwicklerherz höher schlagen lässt:

Team Foundation Server 2008 SP1

Visual Studio 2008 Team Suite SP1

Team System Web Access 2008 SP1

Team Foundation Power Tools, Oktober 2008 update

Den aktuellsten MSSCCI Provider

Team Explorer 2005 (notwendig, um TFS Reports anzupassen mit dem Visual Studio 2005)

Das Visual Studio 2008 Database Edition GDR

Aktueller Process Explorer, Process Monitor und Background Info

 

In seinem Blogeintrag ist mehr darüber zu lesen.

Wer allerdings derzeit versucht, die Images unter Windows 7 zu nutzen, kann unter Umständen enttäuscht werden. Virtual PC 2007 SP1 wird aus Kompatibilitätsgründen unter Windows 7 nicht unterstützt, und sollte der Prozesser keine Hardware-Virtualisierung unterstützen, wird auch das neue Windows Virtual PC (aktuell Beta) nicht funktionieren. Um herauszufinden, ob der Prozessor VT unterstützt schaut man sich entweder im BIOS um oder man nutzt folgendes Tool von Intel: Intel Processor Identification Utility.

Falls der Prozessor keine VT unterstützt hier ein kleiner Tipp mit historischem Abriss für die Weiterbildung: Microsoft hat die Virtual PC Technologie im Jahr 2003 von der Firma Connectix gekauft und kündigte noch für Ende des Jahres die Veröffentlichung von Virtual PC 2004 an. Connectix hatte bis dahin mit der Firma innotek die Technologie als Lösung entwickelt, um x86 Anwendungen auf Macintosh Systemen mit PowerPC laufen zu lassen. Während Microsoft das Product als Virtual PC weiterentwickelte, arbeitete innotek parallel ebenfalls weiter und brachte es unter dem Namen VirtualBox im Jahr 2007 auf den Markt. Anfang 2008 wurde innotek von Sun Microsystems übernommen. Seitdem gibt es VirtualBox als Sun Produkt und steht genau wie Microsoft Virtual PC kostenfrei zum Download zur Verfügung. Soviel zur Historie.

Langer Rede kurzer Sinn: VirtualBox nutzt ebenfalls das VHD Format für virtuelle Festplatten und es funktioniert problemlos unter Windows 7.

Update: Unter Virtual Box werden u.U. verschiedene neue Geräte erkannt, sobald das Image gestartet wird. Dazu gehört neben dem USB Host auch z.B. der Netzwerkadaper. Um problemlos alle notwendigen Treiber automatisch installieren zu lassen, hilft es, das Windows Server 2003 R2 SP2 Tria-Image von Microsoft herunterzuladen. Die ISO's gibt es hier.

Team Foundation Server, Visual Studio vsts 2008, virtual pc, windows 7, team foundation server