Archive

Archive for the ‘Softwareentwicklung’ Category

Compiler warning CS0067 – es muss nicht immer #pragma sein

July 29th, 2010 Bernd 2 comments

warningSignDa ist es wieder. Der Compiler spuckt die Warnung CS0067 “The event ‘XXX’ is never used” aus. Das kann z.B. passieren, wenn das Interface ICommand implementiert wird, das Command aber immer ausführbar sein soll. Das Event CanExecuteChanged muss also nie gefeuert werden:

 

 

public class SomeCommand : ICommand
{
	public void Execute(object parameter)
    {
		// do sth.
	}

	public bool CanExecute(object parameter)
    {
		return true;
	}

	public event EventHandler CanExecuteChanged;
}

Bei obiger Imlementierung bekommt man beim Übersetzten die Compiler Warnung CS0067:

warning CS0067: The event ‘CommandDemo.SomeCommand.CanExecuteChanged’ is never used

Was einem als erstes (zumindest mir) einfällt die Warning zu “beheben”, ist sie mit einem #pragma Statement kurzzeitig aus- und wieder einzuschalten:

#pragma warning disable 0067
	public event EventHandler CanExecuteChanged;
#pragma warning restore 0067

So richtig gut gefällt diese Lösung aber nicht. Bei Implementierungen, wo das Event später vielleicht doch einmal gefeuert wird, ist die Wahrscheinlichkeit ziemlich hoch, dass diese #pragma Statements vergessen werden und im Code verbleiben. Das ist nicht schön. Aber es gibt eine andere, (mittlerweile meiner Ansicht nach bessere) Lösung:

public event EventHandler CanExecuteChanged { add{} remove{} }

Durch das Hinzufügen der leeren Eventaccessors “add” und “remove” mache ich klar, dass dieser Event nicht verwendet wird. Da das Event sowieso nie gefeuert wird, ändert sich auch für den potentiellen Konsumenten des Events nichts. Wenn in einer späteren Phase dieser Event doch einmal ausgelöst werden soll, wird der Entwickler sofort mit einem Kompilerfehler darauf hingewiesen, das dies nicht möglich ist. Die leeren “add” und “remove” Accessoren müssen also entweder wieder entfernt oder entsprechend vollständig implementiert werden ==> der Code bleibt sauber.

Wie man sieht, muss man also nicht sofort zum #pragma greifen, wenn man mit der Warnung CS0067 konfrontiert wird. Das Hinzufügen der leeren Eventaccessoren bietet eine elegante und saubere Lösung mit dem Fall umzugehen.

Categories: Softwareentwicklung Tags: ,

NUnit mit .NET 4.0 Assemblies verwenden

July 19th, 2010 Bernd 2 comments

lightbulb Bei unseren Projekten stellen wir gerade von Visual Studio 2008 auf Visual Studio 2010 mit .NET 4.0 um. Der Umstieg läuft recht problemlos. Die Unittests sind alle mit dem NUnit Unittest Framework entwickelt. Ein kurzer Blick auf die NUnit Homepage zeigt, dass die aktuelle Version 2.5.5 mit .NET 4.0 funktioniert. Also, Version runtergeladen, entpackt und alles kompiliert noch. Als Entwickler verwende ich den Unittestrunner von Resharper. Und siehe da, alle Tests laufen noch und sind grün. Perfekt!

Auf dem Buildrechner sieht es leider nicht so gut aus. Die Unittests laufen überhaupt nicht mehr. Dort werden die Tests mit dem Consolerunner von NUnit ausgeführt. Ein Aufruf desselben auf meinem Rechner bringt folgende (bzw. eine ähnliche) Ausgabe:

Execution Runtime: net-2.0
Unhandled Exception:
System.BadImageFormatException: Could not load file or assembly ‘C:\Users\Bernd\documents\visual studio 2010\Projects\SomeProjects\SomeProject.Unittests\bin\Debug\SomeProject.Unittests.dll’ or one of
its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
File name: ‘C:\Users\Bernd\documents\visual studio 2010\Projects\SomeProjects\SomeProject.Unittests\bin\Debug\SomeProject.Unittests.dll’

Was ist da los?

Die NUnit Assemblies selbst sind mit .NET 2.0 kompiliert. Der Consolerunner von NUnit läuft also auch mit der CLR 2.0 und kann somit keine Assemblies laden, die mit .NET 4.0 erstellt wurden. Glücklicherweise haben die Entwickler von NUnit genau für diese Fälle einen Kommandozeilenparameter für nunit-console.exe eingebaut. Mit dem Schalter “/framework” kann man angeben mit welcher .NET Runtime die Test ausgeführt werden sollen. Der korrekte Aufruf lautet also:

nunit-console.exe /framework:v4.0.30319 bin\Debug\SomeProject.Unittests.dll

Jetzt tritt keine Exception mehr auf und die Tests laufen auch auf der Console sauber durch.

Der Schalter war übrigens vor dem Umstieg (es wurde .NET 3.5 SP1 verwendet) nicht notwendig, da .NET 3.5 dieselbe CLR wie .NET 2.0 verwendet.

Categories: Softwareentwicklung Tags: , ,

TDD – ein Garant für heiße Diskussionen

March 28th, 2010 Bernd No comments

tdd

Beim allmonatlichen Treffen der .NET User Group Franken hatten wir am 25.03.2010 einen interaktiven Vortrag zum Thema Test Driven Development (TDD). Interaktiv deshalb, weil die Vortragenden Jürgen Laude und Jan Welker an einem praktischen Beispiel mit Live Coding gezeigt haben, wie TDD funktioniert. Dabei handelte es sich nicht um ein konstruiertes Beispiel, sondern um ein Problem, welches Jan vor ein paar Jahren schon einmal in einem Projekt gelöst hatte. Es wurde ein spezieller Parser für RSS Feeds entwickelt, die nicht standardkonform aufgebaut sind.

Schon die Anzahl der Gäste an diesem Abend (mit knapp 40 Teilnehmern war der Raum prall gefüllt) hat gezeigt, dass das Thema Testen und testgetriebene Entwicklung viele Softwareentwickler umtreibt. Dementsprechend zahlreich und kontrovers waren auch die Fragen und Diskussionen an dem Abend. Ich möchte hier zu ein paar der diskutierten Punkten meinen Kommentar abgeben.

TDD dient nicht dazu Fehler zu finden

Ein Punkt, der auch von den Referenten angesprochen wurde ist, dass mit TDD nicht in erster Linie Fehler gefunden, sondern verhindert werden sollen. Dadurch, dass die Tests vor dem zu testenden Produktionscode geschrieben werden, ist man gezwungen, testbaren, modularen und lose gekoppelten Code zu schreiben. TDD ist also das Werkzeug des Entwicklers für gutes Design. Hat man sich dieses Sicherheitsnetz aus Unit Tests geschaffen, kann man viel furchtloser mit dem Code arbeiten. Während der ständigen Refaktorierungen, die bei TDD üblich sind, wird man sofort auf Fehler hingewiesen, die man eventuell eingebaut hat. Auch wird sichergestellt, dass sich beim Implementieren neuer Features keine Fehler in die bereits bestehende Funktionalität eingeschlichen haben.

Sollten Internas einer Klasse getestet werden?

Meine Vermutung ist, dass diese Frage hauptsächlich von Leuten aufgeworfen wird, die den Code nicht testgetrieben entwickelt haben. Wenn Unittests im Nachhinein geschrieben werden, schleichen sich Zweifel ein, ob auch wirklich alles getestet ist und ob nicht doch was vergessen wurde. Lieber eine Methode zuviel als zuwenig getestet. Bei testgetriebener Entwicklung wird gegen das öffentliche Interface getestet. Die privaten Methoden entwickeln sich während der Refaktorierungschritte. Es wird damit zu jedem Zeitpunkt sichergestellt, dass die privaten Methoden implizit über das öffentliche Interface mitgetestet werden. Wenn man den Drang verspürt eine private Methode testen zu wollen, ist das ein Code Smell der auf eine Umstrukturierung der Klasse hindeutet.

Unittests können Integrations-, Akzeptanz- oder Systemtests nicht ersetzen

Wenn im Zuge von TDD erstellte Unittests keine Fehler finden, müssen diese Fehler natürlich durch andere Tests gefunden werden. Hier können Integrationstests (die durchaus auch mit einem Unittest Framework geschrieben werden können) und natürlich auch Systemtests helfen. Wenn die Projektstruktur es zulässt, können auch Akzeptanztests (z.B. mit FitNesse) erstellt werden, die es leichter machen direkt mit dem Kunden zu kommunizieren. Bei Akzeptanztests werden die Tests in einer Sprache beschrieben, die sowohl der Entwickler als auch der Kunde versteht.

Natürlich gibt es auch andere Meinungen zu dem Thema. René Drescher-Hackel hat z.B. auf seinem Blog den Post Gedanken zum Test Driven Development (TDD) veröffentlicht.

Es leuchtet ein, dass ein zweistündiges Event zum Thema TDD nicht alle Fragen beantworten und alle Zweifel ausräumen kann. Vielmehr ist es ein Denkanstoß und vielleicht ein Motivationsschub um die Ärmel hochzukrämpeln und TDD in eigenen Projekten anzuwenden und auszuprobieren.

Categories: Softwareentwicklung Tags:

Fehler bei der Installation des Visual Studio 2010 RC

February 15th, 2010 Bernd 4 comments

Ich hatte das Problem, dass sich der Release Candidate von Visual Studio 2010 auf dem Windows XP Firmenrechner nicht installieren ließ. Das Setup brach mit der Fehlermeldung

“A problem has been encountered while loading the setup components. Canceling setup”

ab.

Eine Suche nach obigem Fehlertext hat keine Antwort zu Tage gefördert. Da ist es gut zu wissen, dass im %TEMP% Verzeichnis während des Setups diverse Log Dateien angelegt werden.

In dem File “dd_error_vs_vstscore_100.txt” fand sich folgender Eintrag:

[02/15/10,10:17:33] vs70uimgr: [2] UI Thread exiting with error code: -2147172341.
[02/15/10,10:17:33] setup.exe: [0] StartUIManager(), RunScenario failure
[02/15/10,10:17:33] setup.exe: [2] CSetupManager::RunIntro() – Failed to Start the UI Manager
[02/15/10,10:17:36] setup.exe: [2] CSetupManager::RunLoadSetup() – Failed to Run the Intro

Mit dieser Zusatzinformation hat mich die Suchmaschine meiner Wahl dann auch zu einem MSDN Forum Artikel geführt, welcher die Lösung parat hat: http://social.msdn.microsoft.com/Forums/en-US/setupprerelease/thread/dbcdcd52-d162-4460-9920-33c9ab54b36f

Der Lösung bestand darin, über den “Settings” Dialog in der Language Bar die Unterstützung für Schrifterkennung zu entfernen. Dannach lief das Setup ohne Probleme durch.

Categories: Softwareentwicklung Tags:

WPF 4.0 – Verbesserungen beim Textrendering

November 13th, 2009 Bernd No comments

Am 22. März 2010 wird Visual Studio 2010 als finales Produkt verfügbar sein. Damit ist auch eine neue Version des .NET Frameworks verbunden, .NET 4.0. Auch für WPF Entwickler wird so einiges Neues in .NET 4.0 enthalten sein. Lester Lobo stellt auf seinem Blog in der Reihe “New WPF 4 Features” die wichtigsten Neuerungen vor.

Natürlich will ich nicht alles von Lester wiederkauen, aber eine Neuerung möchte ich doch herausstellen. Bei bisherigen WPF Anwendungen ist die Darstellung von Text mit kleiner Schrift teilweise etwas (manche sagen sogar sehr) unscharf. Der Artikel Textclarity in WPF auf windowsclient.net geht ziemlich gut auf diese Problematik und mögliche Workarounds ein. In .NET 4.0 ist es nun möglich das Textrendering mit zwei attached properties zu beeinflussen.

TextOptions.TextFormattingMode kann mit zwei unterschiedlichen Werten belegt werden. Einmal mit Ideal, was dem bisherigen WPF Textrendering entspricht oder mit Display, was die Darstellung bei kleinen Schriftarten schärfer aussehen lässt.

TextOptions.TextRenderingMode legt den Algorithmus für das Antialiasing fest und kann die Werte Auto, Aliased, Greyscale oder ClearType haben.

Der folgende Screenshot zeigt einige der Einstellungen für kleine und große Schrift:

WPF4TextImprovements

Bei der kleinen Schrift sieht man eine deutliche Verbesserung der Lesbarkeit des angezeigten Textes. Das unscharfe, verwaschene Schriftbild ist einer klaren Darstellung gewichen, was vorallem bei Businessanwendungen mit WPF sehr wichtig ist. Wer jetzt schon die neuen Features von .NET 4.0 ausprobieren möchte, kann sich weiterhin die Beta 2 von Visual Studio 2010 hier herunterladen.

Categories: Softwareentwicklung Tags: ,