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

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:

VerticalAlignment	Stretch
HorizontalAlignment	Stretch
Height	Auto
Width	Auto
Margin	0;0;0;0

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

Bevor dieser Tag endgültig in die Geschichte eingehen wird, denke ich, dass sich der geneigte Leser noch schnell folgendes Video anschauen sollte. Es zeigt die Visual Studio 2010 "On The Go" Edition: Visual Studio for Windows Phone ON the Windows Phone...

 

Visual Studio, April 1st windows phone, visual studio

Arabind Coomaraswamy hat im Januar einen kleinen Beitrag verfasst, in dem er erklärt, was sich von Visual Studio 2008 auf Visual Studio 2010 für Partner ändert.

Hier gibt es eine übersichtliche Matrix. Das wesentlich spannende dabei ist, dass die bisherige Development Edition dabei durch die Premium Edition ersetzt wird. Partner können auf die Ultimate Edition mit immerhin 20% Discount aktualisieren (über das Open Business Volume Licensing Program).

Wenn weitere Unklarheiten bestehen, finden sich auf der Seite Email-Adressen und Telefonnummern der richtigen Ansprechpartner.

 

 

Visual Studio visual studio 2010

Spätestens mit Erscheinen der Microsoft Visual Studio Team System 2005 Team Tester Edition wurde deutlich, dass Microsoft sich intensiv mit der Thematik beschäftigt, wie es den Entwicklern einfacher gemacht werden kann, Code zu testen.

Seit dem hat sich viel getan. Dass neben den bereits kommerziell verfügbaren Produkten aus der Visual Studio Reihe auch weitere Tools in den "Startlöchern" stehen, ist hingegen nicht vielen bekannt. Microsoft veröffentlicht aus dem Research-Bereich und den sog. DevLabs hin und wieder Tools und Programme, die sich noch in der Forschungsphase befinden. Es kommt allerdings auch vor, dass sie dabei bereits intern produktiv genutzt werden.

Highlights zum Thema Software-Testing:

Pex - Automatisiertes Whitebox Testing

Pex steht für Program Exploration. Es generiert automatisch Unit-Tests basierend auf bereits geschriebenem Code. Dabei analysiert es die Eingangsparameter der Methoden und erzeugt automatisch ein entsprechendes Set an Unit-Tests, das mittels Parametrisierung alle Codepfade durchläuft und damit eine hohe Codeabdeckung erreicht. Darüber hinaus liefert Pex einem wertvolle Hinweise. Bei einem String-Eingangsparameter ist es z.B. nicht gewollt, dass ein Null-Wert übergeben wird. Dennoch ist es möglich. Falls daraufhin nicht getestet wird, bietet Pex eine automatische Korrektur an. Mehr dazu hier.

CHESS - Aufspüren von Heisenbugs

Bei der Heisenbergschen Unschärferelation handelt es sich um eine Aussage der Quantenphysik, "[...] dass zwei Messgrößen eines Teilchens nicht immer gleichzeitig beliebig genau bestimmbar sind." Danach wurden die sog. Heisenbugs benannt. Kurzum: Fehler, die verschwinden, sobald man versucht sie aufzuspüren. Das kommt bevorzugt im Bereich des Multithreadings vor, bei dem erst durch die parallele Verarbeitung innerhalb des gleichen Zeitraumes Methoden sich gegenseitig in die Quere kommen. CHESS ist in der Lage, Threads zu visualisieren und derartige Probleme mittels automatisierter Testdurchläufe aufzuspüren. Mehr dazu hier.

Spec Explorer - Testfälle anhand visualisierbarer Softwaremodelle generieren

Das neuste Mitglied in der Testing-Familie auf DevLabs ist der Spec Explorer 2010. Hiermit lassen sich Modelle definieren anhand derer automatisch Testfälle generiert werden. So unspektakulär das auf den ersten Blick auch klingen mag: Laut Microsoft erreichen komplexe Softwareprojekte mit durchschnittlich 300 Testfällen eine Produktivitätssteigerung von 42% durch den Einsatz vom Spec Explorer gegenüber manuell erstellten Tests. Ein beeindruckendes Video dazu zeigt in aller Kürze, wie das funktioniert.

Visual Studio pex, specexplorer, chess, testing

Wer schon einmal mittels Visual Studio eine Website veröffentlicht hat, kennt die verschiedenen Möglichkeiten. Im Wesentlichen sind diese auf FTP, Filesystem oder Frontpage Server Extensions begrenzt. Nachdem hoffentlich keiner mehr letzteres benutzt, kennt sicher auch jeder die Probleme, die es mit der FTP-basierten Veröffentlichung gibt: Es dauert länger als wie man denkt. Darüber hinaus ist es eine Herausforderung, eine Strategie zu entwickeln, die es Möglich macht, eine Website auf verschiedene Hoster zu verteilen ohne jedes Mal neue Credentials eingeben und die web.config anpassen zu müssen (z.B. in Hinsicht auf einen Sql Connectionstring).

Mit Visual Studio 2010 wird das Web Deployment einfacher, besser und vor allem schneller.

• Es kann für jedes Szenario ein eigenes Veröffentlichungs-Profil erstellt werden.
• Neben FPSE, File und FTP kommt das neue 1-Click Publishing hinzu.
• FTP Publishing ist jetzt richtig schnell!
• Transform Files passen web.config Einstellungen je Konfiguration an.
• Sql-Datenbanken können auch veröffentlicht werden (Schema und/oder Daten).

Besonders in Hinsicht auf das 1-Click Publishing sind die Blog-Posts von Vishal Joshi und Scott Forsyth zu empfehlen. 

UPDATE:

Wie mir von Vishal erklärt wurde, steht das automatische Sql-Update während der Veröffentlichung der Website nur beim 1-Click Publish via MSDeploy zur Verfügung. Obwohl die Einstellungen dazu auch unabhängig davon gemacht werden können, findet das Update bei der Veröffentlichung via FTP nicht statt. Dafür gibt es aber die Möglichkeit über den Server-Explorer die Datenbank zu veröffentlichen (server explorer > DataBase Connections > My DB > Publish to Provider).

Außerdem funktioniert die Veröffentlichung via FTP zurzeit nicht korrekt, wenn der Hoster das Löschen ein oder mehrerer Dateien und/oder Verzeichnisse verbietet und im Konfigurationsdialog ausgewählt wurde, dass vor der Veröffentlichung die Dateien und Verzeichnisse auf dem Server gelöscht werden sollen. Aufgrund eines Fehlers (nämlich dass die entsprechenden Dateien und/oder Verzeichnisse nicht gelöscht werden konnten) bricht der Veröffentlichungsvorgang an dieser Stelle ab. Microsoft überlegt, ob dafür ein Work Around entwickelt wird.

Visual Studio

Unter den Tweets meiner Freunde las ich neulich:

"Grad gehört: Amazon Klaut Computing, hoffentlich werden die bald erwischt"

Ich vermute, das ist der Grund, warum Microsoft zu einer ungewöhnlichen Methode gegriffen hat, um das Thema Cloud Computing im Kontext mit Windows Azure den Entwicklern näher zu bringen. Und was ist der beste Weg, schnell zu verstehen, worum es beim Cloud Computing geht? Richtig. Machen!

Daher läuft bis zum 10. November 2009 ein Gewinnspiel, dessen Ziel es ist, eine funktionsfähige Cloud Computing Anwendung auf der Windows Azure Plattform zu veröffentlichen. Und um den Einstieg zu erleichtern, gibt es ein offizielles Tutorial von MSDN Experte Dariusz Parys, das einem alle dazu notwendigen Schritte ausführlich erläutert und sogar eine Beispielanwendung zur Verfügung stellt. Denn letztlich ist es egal, um was es sich bei der Anwendung handelt, solange sie funktioniert.

Viel Spaß beim Ausprobieren und viel Glück beim Gewinnspiel!

Ankündigungen, Visual Studio visual studio 2010

Im April wurde bereits darüber berichtet und mittlerweile haben vermutlich schon alle, die es betrifft, ihr Visual Studio 2008 Database Edition auf das GDR 2 aktualisiert. Als Ergebnis sollte im Help/About Dialog dafür die Versionsnummer 9.1.40413.0 erscheinen. Details dazu hier.

Unter Umständen beobachten einige aber auch das Phänomen doppelter Einträge unterhalb des Data-Menüs. Das kommt daher, das das GDR "side-by-side" zur Version 2008 installiert wird. Gert Draper hat dazu bereits eine Anleitung gepostet, wie sich das Problem beheben lässt.

Hier die Vorgehensweise:

1. Visual Studio schließen

2. Einen Kommandozeilenprompt administrativ öffnen

3. Folgende Befehle starten

"%ProgramFiles%\Microsoft Visual Studio 9.0\DBPro\DBProRepair.exe" RemoveDBPro2008

"%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" /ResetUserData

4. Visual Studio neu starten

Im Falle eines 64 Bit Betriebssystems müssen folgende Befehle gestartet werden:

"C:\Program Files (x86)\Microsoft Visual Studio 9.0\DBPro\DBProRepair.exe" RemoveDBPro2008

"C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" /ResetUserData

 

Visual Studio