Archive

Posts Tagged ‘Tools’

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

WPF Databinding Probleme mit Snoop finden

January 15th, 2009 Bernd 4 comments

WPF Databindings werden häufig in XAML definiert. Da kann es schon mal vorkommen, daß sich der eine oder andere Tippfehler einschleicht – mit dem Ergebnis, daß das Binding nicht wie gewünscht funktioniert. Simples Beispiel:

<Window x:Class="DataBinding.Window1"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   xmlns:local="clr-namespace:DataBinding"
   Title="Binding error" Height="300" Width="300">

   <Window.Resources>
       <local:CompactDisc x:Key="myOneAndOnlyCD" Title="Images And Words" Artist="Dream Theater"/>
   </Window.Resources>

   <StackPanel>
       <TextBlock Text="{Binding Source={StaticResource myOneAndOnlyCD}, Path=Titel}"/>
       <TextBlock Text="{Binding Source={StaticResource myOneAndOnlyCD}, Path=Artist}"/>
   </StackPanel>
</Window>

 

CompactDisc ist die einfachste aller Klassen:

namespace DataBinding
{
   public class CompactDisc
   {
       public string Title { get; set; }
       public string Artist { get; set; }
   }
}

 

Wird dieser Code ausgeführt, wundert man sich, daß zwar der Künstlername angezeigt wird, aber der Titel nicht. Was ist passiert?

Hier kommt Snoop ins Spiel. Snoop ist eines der vielen kleinen Tools die dem WPF Entwickler das Leben leichter machen. Neben diversen anderen Features wie

  • den Visual Tree betrachten
  • Eigenschaften der Elemente im Visual Tree editieren
  • Routed Events verfolgen
  • Zoom der ausgewählten WPF Anwendung

kann das Tool auch Binding Fehler anzeigen.

Nach dem Start listet Snoop in einer Combobox alle WPF Applikationen auf, die momentan ausgeführt werden.

SnoopStartup

Man wählt die betreffende Applikation aus und mit einem Klick auf das Fernglas verbindet sich Snoop damit. Es öffnet sich ein weiteres Fenster in dem man sich den Details widmen kann:

 Snoop visual tree

Öffnet man nun die Combobox in der linken, oberen Ecke findet man den Eintrag “Visuals with binding errors”. Wählt man diesen aus, erhält man eine gefilterte Liste:

Snoop binding errors

In dem Properties Tab auf der rechten Seite wird nun die betroffene Eigenschaft rot eingefärbt. Ein Tooltip zeigt die komplette Fehlermeldung:

System.Windows.Data Error: 39 : BindingExpression path error: ‘Titel‘ property not found on ‘object’ ”CompactDisc’ (HashCode=33736294)’. BindingExpression:Path=Titel; DataItem=’CompactDisc’ (HashCode=33736294); target element is ‘TextBlock’ (Name=”); target property is ‘Text’ (type ‘String’)

Es hat sich also ein Tippfehler bei dem ersten Binding gegen die Eigenschaft “Title” eingeschlichen.

Ok, ok. Den Fehler sieht man auch sofort, wenn die Anwendung im Debugmodus aus dem Visual Studio gestartet wird. Dort wird der gleiche Fehlertext im Output Fenster angezeigt. Aber ich wollte halt meine Begeisterung über Snoop teilen…

Um auch komplizierteren Bindingproblemen auf die Spur zu kommen gibt es seit .Net 3.5 an der PresentationTraceSources Klasse die Attached Property TraceLevel. Bea Stollnitz zeigt hier wie man sie einsetzt (und gibt noch ein paar weitere Tipps zu Debugging von WPF Databinding).

Categories: Softwareentwicklung Tags: ,