Archive

Archive for July, 2010

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: , ,