Wer schon einmal ein eigenes Control entwickelt hat, kennt die Situation eventuell: Wie bekomme ich das Control sauber in die ToolBox?

Wer sogar in einem Team arbeitet fragt sich mitunter auch: Wie verteile ich meine Controls an mein Team?

Gleich vorweg: Dieser Blogpost behandelt das Problem, dass es mit dem Visual Studio 2010 SP1 SDK unmöglich erscheint, VSIX-Pakete mit ToolBox Controls für .NET 3.5 Projekte zu erstellen (oder besser: Projekte, die auf eine Runtime früher als .NET 4.0 setzen).¹

Das Intro nimmt es bereits vorweg: Ein mögliches Werkzeug, um Controls zu verteilen, nennt sich VSIX. Dabei handelt es sich um ein Paketformat von Microsoft, das im Prinzip nichts weiter ist, als eine ZIP komprimierte Datei deren Inhalt sich neben den zu verteilenden Assemblies auch aus Konfigurations- und Metadaten zusammensetzt. Am meisten hat der Entwickler natürlich Spass an solchen Daten, wenn es dafür eine Konfigurationsoberfläche gibt. Und die gibt es tatsächlich!

Sobald das Visual Studio 2010 SP1 SDK installiert ist, findet sich in der Liste angebotener Templates beim Erstellen eines neuen Projektes unter dem Punkt "Extensibility" u.a. das Windows Forms ToolBox Control Projekttemplate. Obacht: Natürlich nur, wenn in der ComboBox das .NET 4.0 Framework ausgewählt ist.

Im Microsoft Developer Network findet sich ein hervorragendes Walkthrough, das die Arbeit mit dem Template erklärt. Insofern gibt es keinen Grund auf diesen Aspekt hier näher einzugehen.

Besonders spannend dabei ist die Möglichkeit, in dem Konfigurationsdialog für das VSIX-Paket anzugeben, für welche minimale und welche maximale Framework-Version das Paket zur Verfügung stehen soll. Die Frage, die sich nämlich aufdrängt ist diese: Wird dort z.B. als minimale Version .NET 3.5 angegeben, wie sollen die Controls dann in einem Projekt eingesetzt werden können, wenn das VSIX-Paket mit dem .NET Framework 4.0 kompiliert wird? Antwort: Gar nicht.

Und hier der Grund für das Dilemma:

Das Projekttemplate importiert das Target-File Microsoft.VsSDK.targets aus dem MSBuild-Verzeichnis unter %ProgramFiles%\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK. Diese Datei referenziert die Assembly Microsoft.VsSDK.Build.Tasks.dll, die u.a. für das Ausführen des Tools CreatePkgDef.exe verantwortlich ist. Dieses Tool analysiert die Assembly, die mit dem Template gebaut wurde, und sucht dabei u.a. nach Klassen, die mit dem RegistrationAttribute dekoriert wurden. Hier drin stecken Metainformationen, die z.B. die ToolBox-Gruppe definieren, in die die jeweiligen Controls gelegt werden sollen.

Das Template beherbergt dazu das ProvideToolboxControlAttribute, welches sich vom RegistrationAttribute ableitet. Dessen Herkunft liegt in der Assembly Microsoft.VisualStudio.Shell, die in verschiedenen Versionen vorliegt. Und hier liegt der Hund begraben. Das Template referenziert dafür die Datei Microsoft.VisualStudio.Shell.Immutable.10.0.dll aus dem Verzeichnis %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v4.0. Das Tool CreatePkgDef.exe wurde mit der gleichen Version kompiliert. Ändert man also in seinem Projekt die Runtime auf .NET 3.5 und ersetzt die Referenz durch die Assembly Microsoft.VisualStudio.Shell.dll aus dem ...\2.0 Verzeichnis, lässt sich der Code zwar kompilieren, aber sobald MSBuild CreatePkgDef ausführt, quittiert dieses das Bemühen mit folgender Fehlermeldung:

The assembly should contain an instance of the attribute 'Microsoft.VisualStudio.Shell.RegistrationAttribute' defined in assembly 'Microsoft.VisualStudio.Shell.Immutable.10.0' version '10.0.0.0'

So bringt das keinen Spass!

Der Blick in den Code des RegistrationAttribute (freundlicherweise liefert Microsoft den im SDK mit) zeigt schnell: Das Attribut selbst hat keine weiteren nennenswerten Abhängigkeiten.

Daher funktioniert tatsächlich folgendes Vorgehen:

1. Aufsetzen eines neuen (Consolen-) Projektes
2. Dekompilieren der CreatePkgDef.exe² (z.B. mit JetBrains dotPeek)
   
3. Überführen des Quellcodes in das neue Projekt
4. Referenzieren der Microsoft.VisualStudio.Shell.dll aus dem 2.0'er Zweig des SDKs
5. Kompilieren
6. Ersetzen der Original CreatePkgDef.exe im Verzeichnis %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Tools\Bin durch die eigene (vorher ein Backup erstellen!)

PWNED!

Hier zeigt sich, dass Microsoft sehr nachlässig war. Es erschließt sich leider nicht einmal im Ansatz, warum das Visual Studio SDK neben den 4.0'er Assemblies zwar auch 2.0'er Versionen mitliefert, aber keine Tools, die mit diesen funktionieren. Das hier beschriebene Vorgehen zeigt indes eindeutig, dass es keinen (vernünftigen) Grund gibt, warum das Windows Forms ToolBox Control Template nicht auch mit .NET 3.5 funktionieren sollte.

¹ Natürlich hindert einen niemand daran, manuell ein VSIX-Paket zu erstellen. Wie gesagt: Es ist eigentlich nur eine ZIP-Datei mit zusätzlichen Informationen.

² Microsoft hat keinen Obfuscator bei CreatePkgDef.exe eingesetzt, was das Vorgehen im Prinzip sehr einfach gestaltet.

HowTo, Visual Studio

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

Ralf philosophiert in seinem aktuellen Blog-Eintrag über sich entwickelnde Softwarestrukturen und versucht dabei eine Analogie zur Evolution im Speziellen und zur Natur im Allgemeinen aufzubauen. 

Während seine Gedanken in der Basis sicher richtig sind und sich daraus Vieles ableiten lässt, sollte dabei ein wichter Punkt nicht vergessen werden: Obwohl die Natur unzählbare Iterationen Zeit hatte, um sich in ihrer Vielfalt bis zu dem heutigen Stand zu entwickeln, gibt es dennoch immer wieder "Bugs" - und damit meine ich nicht diese kleinen possierlichen Tierchen, die einst in einem Großrechner ihr Unwesen trieben.

Das Leben und seine Altlasten

Ralf schreibt, "alles an allen Organismen hat einen Zweck, den es erfüllt, so wie es ist. Da ist nichts zuviel, nichts zuwenig." Leben sei "insofern “lean”".

Das stimmt nicht ganz. Meiner Meinung nach muss man dieses Thema von zwei Seiten betrachten. Denn was das betrifft, hält die Natur sicher keinen etwaigen "Steckplatz" für einen weiteren Fingersatz an den Händen bereit (unter der Annahme, er könne mal gebraucht werden),... auf der anderen Seite wiederum halten unsere (rezessiven) Gene aber wiederum eine Menge Informationen bereit, die inaktiv sind.

Das ist in dem Sinne nicht einmal auskommentierter Code sondern lediglich Code, der nicht mehr angesprungen wird (unsere Compiler meckern heutzutage über so etwas). Genau das führt eben häufig zu "Systemfehlern", indem eigentlich rezessive Gene gelegentlich eben doch mal wieder aktiviert werden und aufgrund veränderter Umweltbedingungen den Mechanismus der evolutionsbedingten Anpassung teilweise aushebeln.

Im übertragenen Sinne fühlt sich das an, wie ein Entwickler, der wider besseren Wissens obsoleten Code nutzt oder Methoden verwendet, die eigentlich brachliegen... nur hat keiner darauf hingewiesen, dass das auch so gewollt ist.

Warum passiert so etwas in der Entwickler-Welt? Häufig, weil keine Quellcode-Versionierung verwendet wird und die Entwickler Angst haben, Code zu löschen. Die Natur hat keine Versionierung. Die Natur ist wie ein COM Objekt: Bis zu einem gewissen Grad abwärtskompatibel, dann und wann aber auch ziemlich instabil. Bei der Masse an Objekten (nächsten Monat allein ~7 Mrd Menschen) fällt das aber kaum auf.

Das Closed / Open Prinzip

Wenn wir tatsächlich versuchen wollten, so einen Pfad zu beschreiten... was wird dann aus dem OCP? Quasi das O in SOLID? Die Natur ergänzt auch nicht ohne zu verändern. Im Gegenteil: Sie verändert. Weil genau wie Ralf auch richtig anmerkt, das System als Gesamtheit betrachtet wird. OCP setzt auf die Idee, von Anfang an bereits die Möglichkeit noch nicht erdachter Funktionen in Betracht zu ziehen und entsprechende Techniken einzusetzen, um sie tatsächlich mal hinzufügen zu können ohne bereits Existierendes modifizieren zu müssen.

Das steht im Widerspruch zu seinem Hinweis, es auch gedanklich bei dem zu belassen, was hier und jetzt gebraucht wird. Oder sehe ich das falsch?

Fakt ist:
Die (natürliche) Evolution ist in der Lage, ein System im Laufe der (Entwicklungs-) Zeit der (sich stetig ändernden) Umwelt anzupassen. Ob die Zwischenergebnisse oder auch über viele Generationen hinweg vorläufig finalen Ergebnisse dabei besonders effektiv sind oder nicht, sei einmal dahingestellt.

In sofern bin ich nicht sicher, ob es der richtige Weg ist, sich für die Entwicklung von Software die Natur zum Vorbild zu nehmen. Ich habe auch das Gefühl, dass es nicht der richtige Weg ist, Legosteine, Elektronische Bauteile (die Paten standen für die EBC) oder organische Zellen (wie im Falle der Softwarezellen) als Ideengeber zu verwenden.

Da aber in Teilbereichen die Analogien zu existierenden Mustern immer mal wieder hilfreich waren, sollten wir die Möglichkeit in Betracht ziehen, dass es eben nicht Die Eine Programmiersprache gibt oder Das Eine Muster, nach dem Software entwickelt werden sollte... sondern lediglich Lösungswege, die in der Lage sind ein spezifisches Problem in einem spezifischen Kontext zu lösen.

Dieser Kontext ist abhängig von der Zielgruppe, die die Software einsetzt, von den Rahmenparametern die die Entwicklung bestimmen, von den Mitteln, die für die Entwicklung zur Verfügung gestellt werden, den Problemen, die von der Software zu lösen sind, etc.

Denn ehrlich:
Dass heutzutage Software immer weiterentwickelt wird und immer wieder neue Funktionen hinzukommen, ist keine Anforderung aus der Softwareentwicklung heraus. Es ist lediglich ein Konstrukt, dass der Softwareentwicklung aufgezwungen wird, um das Marketing und den Vertrieb rund um ein Produkt künstlich aufrechtzuerhalten und es (dauerhaft) konkurrenzfähig zu machen.

Wie Ralf in einem anderen Artikel bereits beschrieben hat: Warum die (ablaufenden) Lebenszeit eines Produktes nicht von vornherein mit einplanen und auf dem Weg zum Ende dafür sorgen, dass ein neues Produkt das alte ablöst und dabei die gemachten Erfahrungen mit einbezieht.

So schließt sich der Kreis

Denn HIER haben wir imho den einzigen und relevantesten Bezug zur Natur: Die Lebenszeit eines Organismus ist begrenzt. Aufgrund programmierter Triebe (Arterhaltung, etc) ist von der Natur sichergestellt, dass die nächste Generation rechtzeitig auf den Weg gebracht wird, wobei Erfahrungen (Metainformationen, Erziehung) und technische Funktionsweisen (DNS) eine mögliche Verbesserung pro Iteration ermöglich, zumindest aber eine kontinuierliche Anpassung an die Umweltbedingungen stattfinden kann.

Reaktion

Ich habe lange mit mir gehadert, ob ich tatsächlich diese Überschrift wähle. Mir ist bereits beim Schreiben klar, dass ich die nächsten Wochen vermutlich mit dem Löschen von Spam-Kommentaren verbringen werde. Und das, obwohl der Titel nicht einmal von mir stammt. 

Auslöser ist ein Blogeintrag von Ralf Westphal. Ralf dürfte den meisten .NET Entwicklern bekannt sein als Visionär in Sachen Event Based Components, Philosoph und Querdenker. Seine regelmäßige Kolumne "Sandbox" in der Fachzeitschrift dotnetpro ist meist geprägt von Fragen über Sinn und Unsinn gehypter Technologien, danach, warum das Offensichtliche meist übersehen wird und Weltanschauungen, die zu lesen man einfach nicht verpassen darf. Häufig eckt Ralf mit seiner Meinung an und überrumpelt dabei den Rest der Community mit bewusst polarisierenden Vorstellungen.

Und genau das ist es, was häufig fehlt. Technologien können nicht nur sondern sollten auch regelmäßig in Frage gestellt werden. Und manchmal muss das Offensichtliche eben erst herausgearbeitet werden, damit es auch jeder erkennt.

Beispiele der Vergangenheit:

In der Ausgabe 8/2011 schreibt Ralf über die "Lizenz zum Sterben" und fragt sich, warum eigentlich alle wissen, dass Software nur eine begrenzte Lebenszeit haben, aber dennoch keiner von Anfang an die Konsequenzen einplant. In der Ausgabe 7/2011 mahnt Ralf an, dass Teams häufig der Blick auf's Ganze fehlt und daher die Planung einen wesentlichen Baustein komplett ausklammert. Und in seinem Blog ist zurzeit u.a. zu lesen, dass es in der Programmierung mehr Porno und weniger Erotik geben sollte.

Bitte was?

Ralf bezieht sich dabei auf ein Zitat aus dem brand eins Magazin: "Das Erotische setzt das Geheimnis voraus. Wo es ganz verschwindet, beginnt die Pornografie." (Byung-Chul Han, Ausgabe 7/2011) Dabei überträgt er diese Vorstellung auf die Softwareentwicklung und arbeitet anhand von Beispielen heraus, dass Erotik höchstens Platz hat, wenn Zeit dafür ist, "höhere Erotik" in Form von Eleganz gern gesehen ist, grundsätzlich aber die "krasse Nacktheit" das Mittel der Wahl sein sollte. Denn unterm Strich soll der Code auf den ersten Blick zu verstehen (was bei Linq nicht immer gelingen will) und seine Funktionalität nicht kunstvoll verhüllt sein.

Ralf, solltest Du das hier lesen: Wo ordnest Du die EBC ein?

Visionen, Empfehlung

Das war sie nun also. Die erste DotNet DevCon.

Nachdem zu Beginn des Jahres bekannt wurde, dass der Herausgeber des Fachmagazins dotnetpro plant, eine neue Entwicklerkonferenz ins Leben zu rufen und neben der BASTA!, der prio, der ADC, der VSOne und einigen anderen eine neue Plattform zu etablieren, auf der Entwickler sich weiterbilden können, stand die Frage im Raum: Wozu?

Doch schnell wurde klar: Während viele Konferenzen auf State of the Art, Visionen und Zukunft ausgerichtet sind, wird nicht allzu selten vergessen, die Entwickler dort abzuholen, wo sie gerade sind und genau da anzusetzen. Um diese Idee nicht auf ein fachspezifisches Thema zu reduzieren, bot die DevCon nach einer entsprechenden Auswahlphase gleich vier verschiedene Tracks an und bereicherte diese mit den unterschiedlichsten Themen:

- Sprachen
- Architektur
- Sharepoint&Daten
- ALM/Produktion

Von Design Patterns, dem absoluten Minimum, das jeder über C# wissen sollte und Continuous Integration über ein automatisiertes Installationsverfahren zum TFS 2010 (präsentiert von TOP TECHNOLOGIES) und Parallelprogrammierung bis hin zu Resharper, eXtreme Programming, Agile und TDD war alles enthalten, was einen Entwickler heutzutage bewegt und was er braucht, um seinen Job effektiv und mit viel Spaß an der Freud zu gestalten.

Getoppt wurde das zweitägige Event von diversen Rahmenveranstaltungen wie z.B. dem beliebten Coding Dojo mit Ilker Cetinkaya (dem Erfinder des Coding Dojos). Mit um die 200 Teilnehmern hat die Konferenz einen sehr guten Start hingelegt und eine bunte Themenvielfalt geboten, die auf eine erfolgreiche Fortsetzung hoffen lässt.

Besonders interessant und hervorzuheben ist, dass sogar vermeintliche Randthemen außerordentlich gut besucht wurden und damit die Teilnehmer bestätigten, dass die Themenwahl trotz oder gerade wegen der Diversität als voller Erfolg zu verbuchen ist. An Tilman Börner und Golo Roden an dieser Stelle eine Gratulation und gleichzeitig auch ein Dankeschön für diese wunderbare Veranstaltung.

Ein persönlicher Gedanke und damit auch ein Fazit an dieser Stelle:

Nachdem z.B. die Besucher des Vortrages über Aufwandsschätzungen live Zeuge eines - nennen wir es einmal "Battles" - zwischen der Referentin Gilda Feller und Ralf Westphal wurden (der sicher nicht nur rein zufällig im völlig überfüllten Auditorium saß), drängt sich die Idee auf, derartige "Zufälle" in künftigen Veranstaltungen bewusst herbeizuführen. Nicht selten stoßen verschiedene Ideen aufeinander und nicht selten verbirgt sich hinter schlüssigen Argumenten lediglich eine einseitige Betrachtungsweise. Ansonsten möglicherweise eher trockene Präsentationen in eine Debatte zu verpacken wäre für die nächste DevCon die logische Konsequenz (und nicht zuletzt lehrreich sowie unterhaltsam für das Publikum zugleich).

Kurzum: Die Frage "Wozu?" wurde zweifelsfrei und überzeugend beantwortet. Bis zur nächsten DevCon!

DevCon, TOP TECHNOLOGIES

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

In der Woche vom 21.02. bis zum 25.02.2011 findet die BASTA! Spring 2011 statt. Wer als Alumni schon einmal auf einer BASTA! Konferenz gewesen ist, hat die Chance auf ein "Gratis" intellibook, welches auf Basis der Ubuntu 10.10 Netbook Edition bereits mit der adobe Air Applikation intellibook betankt ist. Damit haben Abonnenten verschiedener Magazine des S&S Verlages (z.B. des dotnet Magazins) und auch BASTA! Besucher Zugriff auf die Unterlagen der BASTA! sowie (im Fall der Abonnenten) auf die elektronischen Ausgaben aller Artikel.

Was aber eigentlich interessant sein dürfte für Besucher der Sessions, die evtl. kein eigenes Notebook mitgebracht haben und sich nun fragen, was sie mit einem Netbook auf Linux-Basis in .NET Sessions anfangen sollen (außer zu twittern), dem sei gesagt: Mit MonoDevelop steht eine Entwicklungsumgebung ähnlich dem Visual Studio zur Verfügung, mit dem sich viele Demos nachvollziehen lassen.

Dazu ein paar Informationen:

• Bei Mono handelt es sich um die freie (plattformunabhängige) Implementierung des .NET Frameworks
• Mono bildet einen Großteil des .NET Frameworks ab, aber leider nicht alles
• Die Installation von Mono inkl. MonoDevelop erfolgt auf dem intellibook am einfachsten so:
  • Klick auf das Ubuntu-Logo links oben
  • Klick auf das Icon "Neue Anwendungen installieren"
  • Suchen nach "MonoDevelop" (rechts oben)
  • Auswahl "MonoDevelop" und Klick auf "Weitere Informationen"
  • Zusätzliche Auswahl von "VersionControl...", "Mono Visual Basic Compiler..." und "Einfacher Webserver..."
  • Klick auf "Installieren"

Der Visual Basic Compiler z.B. ist nicht per Default ausgewählt, daher lassen sich bei der Standardselektion nach der Installation keine VB.NET Projekte übersetzen. Wer sich außerdem z.B. für die Extension Projekte von Better Office interessiert, findet sicher Gefallen an dem Plugin für die Versionskontrolle, mittels dessen direkt auf das SubVersion Repository auf CodePlex zugegriffen werden kann. Wer sich ASP.NET MVC anschauen möchte, benötigt darüberhinaus einen Webserver, der mit mono-xsp installiert wird.

Aufgrund von Paketabhängigkeiten werden alle Mono-Bibliotheken automatisch mitinstalliert.

Problem: Dadurch gibt es eine Unterstützung für .NET bis zur Version 3.5 (Mono 2.4). Seit Mono 2.8 (aktuell ist Mono 2.10) wird auch .NET 4.0 unterstützt. Die Extension Bibliotheken von Better Office beispielsweise benötigen .NET 4.0. Aber auch das kann selbst auf dem intellibook gelöst werden:

Wie es der Zufall so will, wurde am 20.02. ein Script veröffentlicht, das alle Sourcen für Mono 2.10 herunterlädt, sämtliche Abhängigkeiten auflöst und Mono anschließend baut und einrichtet. Der Prozess dauert einige Stunden. Im Anschluss muss in MonoDevelop unter Bearbeiten\Einstellungen im Knoten Einstellungen als .NET Runtime Mono 2.10 hinzugefügt werden (Verzeichnis: /opt/mono-2.10).

Wer nun die Bibliotheken von Better Office über das SVN Repository (URL findet man auf bo.codeplex.com) herunterlädt und die Solution bo-Library aus dem Verzeichnis .NET öffnen möchte muss nur noch wissen, dass das Verzeichnis im Öffnen-Dialog nicht sichtbar ist, da der Verzeichnisname mit einem Punkt beginnt. Über das Stift-Symbol oben links im Öffnen-Dialog lässt sich das Verzeichnis aber auch manuell eingeben (inkl. Type-Ahead).

Mono, BASTA, HowTo basta! spring 2011, mono, monodevelop

Eine mit Sicherheit spannende Informationen für alle, die den MSDN Newsletter nicht beziehen oder ihn ungelesen im Papierkorb verschwinden lassen:

Charles Petzold hat vor kurzem auf msdn.com sein neues Buch zur Programmierung von Windows Phone 7 komplett zur freien Verfügung kostenlos zum Download ins Netz gestellt. Es umfasst 24 Kapitel mit um und bei 1.000 Seiten und beschäftigt sich mit Themen wie:

• Touch
• Sensors
• Bitmaps, Vector- / Rastergraphics
• Silverlight, XNA
• Databinding
• Animations
• und vieles mehr

Um das Team von Windows Phone 7 zu zitieren:

"Yes, Programming Windows Phone 7 is truly a free download, but for those readers who still love paper—as I certainly do—this book will also be available (for sale) divided into two fully-indexed print editions: Microsoft Silverlight Programming for Windows Phone 7 and Microsoft XNA Framework Programming for Windows Phone 7. [Note from Devon: we should have these ready for order in December 2010.]"

[Update] Folgende Tools sind unter Garantie spannend für alle Windows Phone 7 Entwickler

AccelKit - Mit Webcam und Augmented Reality den Beschleunigungssensor simulieren

MultiTouchVista - Mit zwei Mäusen Multitouch simulieren

GPS Simulator - Mit Bing Maps GPS Daten ans Windows Phone schicken

Ankündigungen, WP7, Windows Phone 7 wp7, windows phone 7, ebook

Wer schon einmal die Anforderung hatte, Texte in einer TextBox oder RichTextBox in einer WinForm Applikation auf Rechtschreibung prüfen zu müssen, kennt u.U. folgendes Szenario:

1. Word Instanz erstellen und unsichtbar machen
2. Dokument erstellen
3. Über die Zwischenablage den Text hineinkopieren
4. Die Methode SpellCheck von Word aufrufen
5. Den Text in Word markieren und in die Zwischenablage kopieren
6. Den Text zurück in die TextBox einfügen und Word schließen

Neben der eher ungeliebten Word-Automation in einer .NET Applikation kommt die Instabilität hinzu, die man damit riskiert (z.B. hängengebliebene Word-Instanzen).

Wer davon gehört hat, dass TextBox Steuerelemente in WPF eine eingebaute Rechtschreibprüfung besitzen, die sogar “inline” funktioniert, wird sich sicher fragen, was ihm das bringt, wenn er doch eine WinForm Applikation entwickelt.

Dieser Artikel zeigt in aller Kürze (…), wie man sich diese Tatsache als WinForm Entwickler zu Nutze machen kann.

Anforderungen

Folgende Anforderungen soll die TextBox unterstützen:

• Rechtschreibkorrektur
• Zählen der eingegebenen Zeichen (Events)
• Konfiguration der Schriftart aus der WinForm Applikation heraus (Databinding)

Projekt erstellen

File –> New Project –> Visual C#, Windows; Windows Forms Application; Name: WPFIntegrationDemo

Project –> Add New Item –> Visual C# Items, User Control (WPF); Name: ModernTextBox.xaml

Nun ziehen wir via Drag and Drop eine (WPF) TextBox aus der ToolBox in das (WPF) UserControl und machen wir folgende Einstellungen, um die TextBox das UserControl komplett ausfüllen zu lassen:

Damit die ModernTextBox in unserem Projekt zur Verfügung steht, kompilieren wir das Projekt an dieser Stelle einmal.

Nun wird der Form1 im Designmode das Steuerelement ElementHost hinzugefügt (zu finden in der ToolBox unter WPF Interoperability(-ation^*)). Dabei öffnet sich direkt das Smarttag und es kann das zu hostende WPF Steuerelement (ModernTextBox) ausgewählt werden.

Der Einfachheit halber kann hier das Control auch einfach im Winform angedockt werden. Das ist das gleiche, wie Dock: Fill.

Jetzt kann das Projekt bereits zum Testen gestartet werden und siehe da: Eine WPF basierte TextBox in einer WinForm Applikation.

Rechtschreibkorrektur

Dies ist der einfachste Teil, da WPF basierte TextBoxen von Haus aus eine Rechtschreibkorrektur ermöglichen.

In der ModernTextBox.xaml wird einfach das TextBox-Tag um das Attribut SpellCheck.IsEnabled erweitert:

<TextBox Name="textBox1" 
                 Height="Auto" 
                 Width="Auto" 
                 HorizontalAlignment="Stretch" 
                 VerticalAlignment="Stretch" 
                 Margin="0" 
                 SpellCheck.IsEnabled="True" />

Das war es auch schon:

Zählen der eingegebenen Zeichen

In WinForm Applikationen ist eine einfache Möglichkeit, die eingegebenen Zeichen zu zählen, auf das KeyUp Event der TextBox zu reagieren.

Das ist mit einem eingebetteten WPF Steuerelement zum Glück nicht anders. Für die Anzeige wählen wir einfach einen StatusStrip Steuerelement und fügen zwei StatusLabel hinzu. Dem ersten geben wir den Text "Zeichen:”, bei dem zweiten löschen wir den Text und aktualisieren ihn mit der Anzahl der eingegebenen Zeichen als Reaktion auf das KeyUp Event der WPF TextBox:

public Form1()
{
    InitializeComponent();
    this.modernTextBox1.textBox1.KeyUp += 
        new System.Windows.Input.KeyEventHandler(textBox1_KeyUp);
}
 
void textBox1_KeyUp(object sender, System.Windows.Input.KeyEventArgs e)
{
    this.CharacterCountToolStripStatusLabel.Text = 
        this.modernTextBox1.textBox1.Text.Length.ToString();
}

Konfigurieren der Schriftart

Es gibt verschiedene Wege, um dafür zu sorgen, dass die Konfiguration der Schriftart der TextBox einfach von der WinForm Applikation gemacht werden kann. Ich zeige jetzt einen Weg, der auch etwas über die Databinding Fähigkeiten von WPF Steuerelementen zeigt und das sog. PropertyMapping des ElementHost Steuerelementes.

Zunächst einmal: Während wir in WinForm Applikationen mit System.Drawing.Font arbeiten, gibt es in WPF Applikationen u.a. System.Windows.Media.FontFamily. Aber auch FontSize, FontStretch, FontStyle und FontWeight. Die schlechte Nachricht: Die sind nicht direkt kompatibel. Die Gute: Das Steuerelement ElementHost verfügt über eine PropertyMap, die transparent für den Entwickler bestimmte Eigenschaften von WinForm auf WPF mappt.

Allerdings landen diese Einstellungen dann natürlich in dem WPF UserControl und erst einmal nicht in der darin angedockten TextBox.

Via DataBinding können nun die Eigenschaften der TextBox mit denen des UserControls verbunden werden (es gibt viele andere Wege… dieser dient der Demonstration):

Dazu klickt man auf das Kästchen direkt neben der Eigenschaft (Advanced Properties) und wählt Apply Data Binding. Als Quelle wählt man Relative Source –> Find Ancestor –> UserControl und als Pfad FontFamily (wie gesagt: Ein Beispiel).

Das wiederholt man für die anderen Eigenschaften. Damit wirken sich die Font Einstellungen des UserControls direkt auf die der TextBox aus.

Um das zu demonstrieren, fügen wir einen ToolStrip in das WinForm ein und konfigurieren einen Button, dessen OnClick Eventhandler folgenden Code implementiert:

private void toolStripButton1_Click(object sender, EventArgs e)
{
    using (var fontDialog = new FontDialog())
    {
     if (fontDialog.ShowDialog() == System.Windows.Forms.DialogResult.OK)
        {
         this.elementHost1.Font = fontDialog.Font;
        }
    }
}

Und hier sehen wir das Ergebnis: Die Font Eigenschaft des ElementHosts stammt aus dem Namespace System.Drawing und wird intern für WPF automatisch in die entsprechenden FontFamily, FontWeight, etc. Eigenschaften gewandelt:

Wer es übrigens noch nicht weiß: Im Visual Studio 2010 Verzeichnis unter Common7/VS2010ImageLibrary findet sich eine .zip Datei, die eine große Menge an u.a. Icons beeinhaltet, die frei in eigenen Applikationen verwendet werden dürfen. Die einzige “Restriktrion” ist, dass die Bilder nur für ihren angedachten Zweck verwendet werden dürfen (z.B. darf man das Icon für die Funktion Ausschneiden nicht für die Funktion Einfügen verwenden).

Für den ToolStrip Button habe ich z.B. folgendes Icon genutzt:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\VS2010ImageLibrary\1033\Actions\png_format\Office and VS\FontDialogHS.png

Zusammenfassung

Ich hoffe, dass dieser kleine Beitrag helfen konnte, aufzuzeigen, wie einfach es ist, zum einen WPF Steuerelemente in WinForm basierte Applikationen zu integrieren und zum anderen dort bekanntes Wissen anzuwenden, um mit ihnen zu interagieren. Natürlich gibt es viel Neuland zu betreten und einige Fallstricke zu umgehen. Aber der Einsatz kann sich lohnen. Vor allem, wenn er der erste Schritt in Richtung einer Migration nach WPF darstellt.

^* Wer den verstanden hat und es als erster kommentiert, bekommt von mir einen Kasten Bionade zugeschickt.

Visual Studio, WPF, Interoperability

Wer dachte, dass ein neues Visual Studio aufgrund der vielen Features das ein oder andere Tool obsolet macht, fand sich zwar darin bestätigt, dass das Visual Studio 2010 in der Tat einige sensationelle Verbesserungen frei Haus mitliefert (und damit ist nicht nur der stufenlose Zoomregler gemeint, der zur Legitimation von dank WPF nahezu überall zu finden ist), sich allerdings auch weiterhin viel Spielraum für jede Menge Extensions bietet.

Über das Menü Tools -> Extension Manager gelangt neben den lokal installierten Erweiterungen auch zu einer Online-Gallery in die ein Blick zu werfen sich auf jeden Fall lohnt.

Zu den TOP Extensions zählen auf jeden Fall:

• Productivity Power Tools
• PowerCommand for Visual Studio 2010
• VS10x Code Map
• Team Foundation Server Power Tools 
• CodeCompare

Wobei sich bei zumindest letzterem die Geister scheiden. Ich persönlich bin begeistert von der Idee ein vernünftiges Diff Tool in Visual Studio integriert zu sehen (ich sprach von vernünftig,.. bevor jemand auf das bereits integrierte WinDiff hinweist). Allerdings entpuppt sich CodeCompare (stand heute) noch immer als verhältnismäßig instabil, weshalb wir in unserer Firma Winmerge noch immer vorziehen.

Visual Studio