Erwartungsgemäß war Lori mit Ihrer Kamera auf dem Launch-Event in Frankfurt unterwegs und hat etliche Interviews geführt.

Unter anderem hat sie sich auch Albert Weinert geschnappt, der ihr prompt aktuelle Infos zur AfterLaunch-Veranstaltung am 11. April in Köln erzählt hat.

(Wen das Interview mit Michael Kalbe nicht interessiert: Albert wird nach ca. 6:05 Minuten in Szene gesetzt ;-))

Rund um Visual Studio Team System und Team Foundation Server gibt es inzwischen eine ganze Reihe interessanter Blogs, weshalb ich hier meine Blog Roll mit etwas mehr als 70 Blogs zu eben diesem Themen zum Download bereitstelle.

Auf CodePlex ist das WCF Load Test Tool verfügbar, das basierend auf einem WCF trace file, einem WCF Client proxy oder einem WCF Interface contract einen Unit-Test erstellt und diesen basierend auf der Abfolge von Methoden-Aufrufen, die im trace file stehen, ausführt.

Das Tool erzeugt Code für Visual Studio 2005 und 2008.

Aktuell sind folgende Features vorhanden:

• Replay of captured scenario in a unit test that can be included in a load test.
• Support for the DataContractSerializer.
• Support for message contracts.
• Support for proxies generated using svcutil.
• Support for clients that create proxies at run time from contract interfaces.
• Supports calls to multiple services in a single scenario.
• Supports multiple calls to the same service operation.
• Filtering by SOAP action of which messages in the trace to replay.
• Readable and modifiable code is generated.
• Automatic association of trace message with proxy method (requires all operations to have a unique SOAP action).
• Support for client and server side traces.
• A command line tool for processing traces and generating code.
• Visual Studio 2005/2008 integration (Team Developer, Team Test, Team Suite and for 2008 also Professional)) that can be used instead of the command line tool.

Vor fast 15 Monaten hat Microsoft die erste öffentliche Version von LINQ to XSD veröffentlicht, welche mit der Beta 1 von Visual Studio 2008 (damals "Orcas") lief.

Danach wurde es lange Zeit still um LINQ to XSD, obwohl sich viele Entwickler eine Weiterentwicklung wünschten.

Nun hat das Microsoft XML Team eine neue Version (Alpha 0.2) veröffentlicht, die mit  der Final von Visual Studio 2008 läuft.

LINQ to XSD ermöglicht den typisierten Zugriff auf XML, hier ein kurzes Beispiel:

Zunächst die Lösung mit "klassischem" LINQ to XML:

from item in Orders.Elements("Item") select (double)item.Element("Price") * (int)item.Element("Quantity")

Die gleiche Funktionalität implementiert mit LINQ to XSD:

from item in Order.Item select item.Price * item.Quantity

Die Vorteile von LINQ to XSD liegen also klar auf der Hand:

• Bessere Lesbarkeit
• Typüberprüfung während der Kompilierung
• Intellisense für das gesamte Konstrukt

Brian Harry, Product Unit Manager für Team Foundation Server, hat in seinem Blog Slides zum Thema verteilte Entwicklung mit Team Foundation Server veröffentlicht, welche von Bill Essary erstellt wurden.

Nachdem Microsofts OpenXML im September letzten Jahres die Zertifizierung als ISO-Standard leider nicht geschafft hat, findet diese Woche (also vom 25. bis 29. Februar) nun die Einspruchsberatung statt.

Und natürlich muß der Software-Trendsetter der letzten 30 Jahre - IBM - wieder gegen OpenXML wettern - wahrscheinlich aus Angst, sie könnten mit ODF schon wieder auf ein totes Pferd (nur ein Beispiel von vielen war OS halbe OS/2) zu setzen.

Natürlich hat Bob Sutor die 6000 Seiten Dokumentation nicht gelesen (genauso wenig wie ich), aber hätte er das getan, müßte er vermutlich eingestehen, dass die Dokumentation schlichtweg aus dem Grund umfangreicher ist, weil OpenXML mehr Features bietet.

Witzig finde ich übrigens auch seine (Bob Sutors) Aussage, dass er die Zukunft der Textverarbeitung darin sieht, dass die Dokumentverarbeitung nicht mehr auf den einzelnen User beschränkt ist.

Witzig deshalb, weil ausgerechnet OpenOffice.org aktuell keine in der Praxis brauchbare Funktion zur Handhabung von Überarbeitungen hat - tolle Teamfunktionen.

Naja, warten wir mal ab, was dabei herauskommt, ich hoffe nur, dass sich die entsprechenden Gremien nicht der neidgetriebenen Meinung zu Microsoft in Europa anschließen.

Offensichtlich geht man in Frankfurt davon aus, dass die ATEs beim morgen beginnenden Launch-Event von Visual Studio 2008 & Co. in Frankfurt fürstlich entlohnt werden ;-)

(aufgenommen gegen 22:00 Uhr in Frankfurt)

Konfiguriert man SubText in der Version 1.9.5b, um mehrere Blogs in einem virtuellen Verzeichnis zu betreiben, bekommt man nach der Definition des 2. Blogs nur noch 404-Fehler.

Der Grund ist ein Fehler in der web.config - der letzte HttpHandler hat einen Fehler in der Pattern-Definition und muß wie folgt gersetzt werden:

Das Anlegen von Team-Projekten in Visual Studio Team System ist dank der Assistenten sehr einfach.

Wer sich jedoch frägt, wie er ein Team-Projekt löschen kann, findet in der Team Explorer-Oberfläche keinen entsprechenden Eintrag.

Der Grund hierfür ist, dass Team-Projekte nur mit dem Kommandozeilen-Tool "TFSDeleteProject.exe" gelöscht werden können.

Dieses findet sich bei Visual Studio 2008 bei installiertem Team Explorer 2008 unter

Der Aufruf erfolgt als berechtigter TFS-User per

Bei der Entwicklung im Team ist es wichtig, dass sich die Entwickler gegenseitig auf den geschriebenen und eingecheckten Code verlassen können. Eine erste Hürde, die man dem Code vor dem Einchecken stellen kann (und sollte), ist die Prüfung auf einen erfolgreichen Build am Rechner des Entwicklers des jeweiligen Codes.

Mit Team Foundation Server und Visual Studio ist dies über die Check-in Policies leicht zu realiseren.

Zunächst führen wir im Team Explorer einen Rechtsklick auf das Projekt aus und wählen die dargestellten Optionen:

Im folgenden Fenster ist der Reiter "Check-in Policy" auszuwählen und dann der Add-Button zu klicken:

Daraufhin erscheint eine Liste von Check-in Policies. Wir wählen die "Code Analysis" Policy und klicken auf "OK":

Im Anschluß kann die Policy konfiguriert werden. Hierbei können alle Regeln deaktviert werden, ebenso wie die C/C++-Code Analysis:

Danach müssen noch die Code Analysis Settings des Projekts mit denen der Check-in Policy kombiniert werden:

Versucht man nun, Code einzuchecken, der fehlerhaft ist und deshalb zu keinem erfolgreichen Build führt, erhält man folgende Warnung beim Check-in:

Die Details finden sich nach einem Doppelklick auf die Meldung:

Somit lässt sich ab sofort also nur noch Code einchecken, wenn der Build am lokalen Rechner,  auf dem der Code geschrieben wurde, erfolgreich war.