Wenn der Breakpoint nicht erreichbar ist …

Ein kleiner Tipp aus der Praxis. Beim debuggen eines Projektes hatte ich in einer Klasse einen Breakpoint gesetzt, aber dieser wurde zur Laufzeit nie erreicht. Ich konnte mir das Problem nicht erklären. Das Projekt, in dem die Klasse sich befand, war korrekt eingebunden, das eigentliche Projekt kompilierte ohne Fehler, wieso wurde also der Breakpoint nicht erreicht? Bei einem genaueren Blick zeigte der Tooltip des Breakpoints folgende Meldung an:

Der Haltepunkt wird momentan nicht erreicht. Für dieses Dokument wurden keine Symbole geladen.

Nach einer kurzen Suche kam ich zu der Lösung. Das Problem bestand darin, dass in den Einstellungen für den Verweis des eingebundenen Projektes die Einstellung für Lokale Kopie auf false gesetzt war. Das führte dazu, dass die .pdb Datei (Programmdatenbank), welche die für das Debugging nötigen Informationen enthält, nicht erstellt wurde und der Breakpoint somit nicht erreichbar war. Die Einstellung von Lokale Kopie auf true gesetzt, der Breakpoint war erreichbar und das Problem war behoben.

Bug beim Parsen eines Währungsstring der tzm-CultureInfo in .NET

Beim Testen der Konvertierung numerischer Werte in einen Währungsstring und umgekehrt ist mir ein Fall aufgefallen, den man als Bug einstufen kann. Das Parsen von Währungsstrings, unter Verwendung der CultureInfo als FormatProvider, funktioniert bis auf die tzm-CultureInfo problemlos. Der Versuch einen mit der tzm-CultrueInfo formatierten Währungsstring zu parsen verursacht eine FormatException.

Ergebnis Meldung:    System.FormatException : Die Eingabezeichenfolge hat das falsche Format.
Ergebnis StackTrace:
bei System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
bei System.Number.ParseDecimal(String value, NumberStyles options, NumberFormatInfo numfmt)
bei System.Decimal.Parse(String s, NumberStyles style, IFormatProvider provider)
bei Currency.Test.CurrencyTest.TestCurrency(CultureInfo cultureInfo) in CurrencyTest.cs:Zeile 29.

Bei der tzm-CultureInfo ist der CurrencyDecimalSeparator = "." und der CurrencyGroupSeparator = ",". Tauscht man jedoch die Werte, wird der Währungsstring korrekt geparsed. Das Problem besteht in den .NET Framworks 2.0 bis 4.5.1. Eine Lösung für das Problem habe ich leider nicht gefunden. Die einzige Möglichkeit bei dynamischen Unit Tests besteht darin diese CultureInfos rauszufiltern.

Eine weitere Besonderheit ist mir auch beim Testen mit dem Framework 3.5 aufgefallen. Das Parsen eines Währungsstrings mit einer neutralen CultureInfo wird mit einer NotSupportedException quitiert. Andere Frameworkversionen sind davon nicht betroffen.

Ergebnis Meldung:    System.NotSupportedException : Die Kultur "af" ist neutral. Sie kann nicht als die aktuelle Threadkultur festgelegt werden, da sie nicht zum Formatieren und Analysieren verwendet werden kann.
Ergebnis StackTrace:
bei System.Globalization.CultureInfo.CheckNeutral(CultureInfo culture)
bei System.Globalization.CultureInfo.get_NumberFormat()
bei Currency.Test.CurrencyTest.TestCurrency(CultureInfo cultureInfo) in CurrencyTest.cs:Zeile 21.

Die tzm-CultureInfo steht für Tamazight, Berbersprachen und -dialekte. Nun wird man wohl selten in die Verlegenheit kommen diese CultureInfo direkt zu verwenden, aber im Hinblick auf dynamische Unit Tests ist es vorteilhaft von diesen Einschränkungen zu wissen.

Weiterlesen

GitHub Markdown Tipp

Auf GitHub kann man die Readme-Dateien bekanntlich in Markdown verfassen. Da ich mich noch mit Markdown vertraut mache, hatte ich so meine Anlaufschwierigkeiten.

Vor das erste Problem stellte mich ein einfacher Zeilenumbruch. Ein einfaches return oder ein \n brachten leider nicht das gewünschte Ergebnis. Nach etwas Suchen bin ich dann schließlich fündig geworden. In Markdown erzeugen zwei oder mehr Leerzeichen am Ende einer Zeile einen Zeilenumbruch.

Das zweite Problem war die Darstellung des #-Zeichens am Ende einea Markdown-Headers. In Markdown wird ein Header mit dem #-Zeichen eingeführt. Endet der Satz ebenfalls mit einem #-Zeichen (z.B. Examples in C#), wird es nicht angezeigt. Abhilfe schafft auch hier ein Leerzeichen am Ende der Zeile und der Satz wird korrekt angezeigt.