Man lernt nie aus: C++ Breakpoint Hit Count

Wer viel zwischen C++ und einer "gescheiten" Sprache wie C# hin und her wechselt, wird das besonders lieben: Auch nach fast 20 Jahren Visual C++ hat Microsoft es noch nicht geschafft, dass bei einem Crash mit Break on Exception der Callstack immer stimmt. Also schrittweise "von Hand" an den Fehler herantasten. Kann einen bei großen Datenmengen und rekursiven Aufrufen gerne mal in den Wahnsinn treiben. Was ich wusste, dass es einen Break on Hit Count gibt. Was ich NICHT wusste, ist, dass man folgendes tun kann:

• Breakpoint setzen auf einer Funktion, die man im Verdacht hat
• Hit Count erstmal auf 99999 oder so setzen
• reinrumpeln lassen
• nach dem Crash ist in den Breakpointeigenschaften zu sehen, wie oft die Stelle durchlaufen wurde, bis es geknallt hat

Was freue ich mich wieder auf meinen C#-Compiler ;)

Outlook 2010 "Speichern unter" Standardordner ändern

Kleinigkeiten, die einen jeden Tag nerven, saugen Energie

Tag gerettet :-)

Silverlight for Windows Phone 7

Der Silverlight-Part meines "streng geheimen Privatprojektes" (Name steht immer noch nicht wirklich) wächst und gedeiht. Und das neue Windows Phone 7 unterstützt ja bekanntermaßen neben XNA für Spiele die Silverlight-Plattform für "Geschäftsanwendungen" (oder meinetwegen ein textbasiertes iBeer, äh sorry X-Beer.NET). Was liegt also näher, "schnell mal" (wie ich das schon hasse, wenn sich diese Wortkombination in meinem Kopf formuliert) einen "Port" zu probieren.

Schlagartige Ernüchterung!

1. Die Installation der Windows Phone Developer Tools spielt mir keine Projektvorlagen auf und bringt irgendwelche Fehler bei der Installation von Expression Blend 4 (vermutlich weil ich das schon draufhab, ist das andere eine Phone-Spezialversion?).

Na gut dann geh ich auf die Vorlagen aus dem Internet...

2. Silverlight-Assemblies lassen sich nicht so einfach referenzieren! (Er faselt irgendwas von einer indirekten Referenz auf System.Windows.Browser)

auch schön, ich referenzier den Code dateiweise, ermöglicht mir die gute alte bedingte Compilierung, wie anno dunnemal, als ich berufsmäßig meinen C- und C++-Code noch für Windows und OS/2 abgeben mußte (manche Dinge sind gut, dass sie vorbei sind!)

3. Da haben wir den Salat! Schon fehlt die erste Klasse! Die TreeViewExtensions, beim "echten" Silverlight Bestandteil des Control-Toolkits... Ein substanzieller Teil meiner Anwendung braucht diese Funktionen für meinen aufgepimpten Tree... Also: Ende des Tests!

Wie man sieht: Es ist wieder mal verdammt viel Wissen darüber notwendig, was geht und was nicht, so ähnlich wie am Anfang von Silverlight (2), als nirgendswo in den Microsoft-Anleitungen ein Sterbenswörtchen darüber verloren wurde, ob die Funktion A oder B nun in der jeweils anderen Welt vorhanden ist oder nicht. So wird der Neuanfang einer Anwendung auf grüner Wiese für einen "alten Silverlight-Hasen" mit seinem festverdrahteten Know-How vermutlich auch nicht viel leichter als das Umschreiben einer bestehenden Anwendung...

Wirklich profitieren werden wohl nur die Anfänger, die sich ohne Vorurteile in eine einfach zu lernende Softwareplattform einarbeiten können, und in ein paar Jahren, wenn alle Systeme gleichgezogen haben, sind sie dann plötzlich gleichermaßen Silverlight- und .NET-Spezialisten.

SynchronizationContext.Current == null

Warum ist SynchronizationContext.Current manchmal null?

SynchronizationContext ist eine Klasse, die dabei helfen soll, unabhängig von GUI-Technologien (WPF/WinForms) einen Synchronisierungsmechanismus vom Background-Workerthread zurück zum GUI-Thread zur Verfügung zu stellen (GUI-Thread = der Thread, in dem die GUI-Komponente XY erzeugt wurde).

Möglich dass das hier hilft (dort, wo die oberste GUI-Komponente, sprich Dialog/Window verfügbar ist, also z.B. in deren Konstruktor):

if( SynchronizationContext.Current == null )
SynchronizationContext.SetSynchronizationContext(
new System.Windows.Threading.DispatcherSynchronizationContext( this.Dispatcher )
); // ersetze "this" durch irgendein lebendes GUI-Objekt mit Dispatcher

Bei mir passiert das, wenn ich in einem Unit-Test (NUnit) eine GUI-Komponente öffne (warum sollte man das tun? nicht fragen...). Offensichtlich erzeugt der Testrunner einen neuen Thread für den Testfall (ich benutze die Testrunnerfunktion von Reshaper, aber ich denke Testdriven.NET oder der nunit-Runner macht das genauso). Damit ich dann (WPF-)-GUI-Komponenten aufrufen kann, muß ich die Testfunktion mit [STAThread] markieren (oder ist das schon falsch?).

Dann passiert genau das, dass ich den SynchronizationContext manuell setzen muß, und zwar auf den Dispatcher des obersten Fenster, das in dem Testfall erzeugt wird.

[Update 20.05.]
Ich hatte auch die Situation, dass der SynchronizationContext ein ThreadSynchronizationContext ist und kein DispatcherSynchronizationContext. Für meinen Anwendungsfall (Background-Threads posten ein Ergebnis an den GUI-Thread; was sollte man sonst mit einem SynchronizationContext machen?). Scheint das nicht zu gehen, also muß es sogar so lauten:

if( !(SynchronizationContext.Current is DispatcherSynchronizationContext) )
  SynchronizationContext.SetSynchronizationContext(
   new DispatcherSynchronizationContext( this.Dispatcher )
);

Visual Studio: Track Active Item in Solution Explorer

Hilfe! Wo ist meine Datei im aktuellen Solution-Baum?

Aktiviert man diesen Schalter



in den Einstellungen, folgt der Solution Explorer nun immer der aktuellen Datei. Bis es nervt. Es nervt ganz sicher irgendwann. Weder das eine noch das andere macht dauerhaft Sinn. Eigenlich braucht man nur eine Funktion "Finde aktuelle Datei JETZT" (nicht "Dauernd Finden an/aus").

Für Anwender von RESHARPER: Resharper/Tools/Locate in Solution Explorer (Shift-Alt-L)

Shift-Alt-L :-) Ich liebe es jetzt schon! Mehr wollte ich ja gar nicht. Alle Nicht-Regesharpten können sich immer noch das Kommando zur obigen Einstellung ("View/Track Item View" glaube ich) als Toolbar-Button irgendwo hin legen. Wenn man dann zweimal draufhaut (Tracking einschalten und gleich wieder ausschalten) erreicht man denselben Effekt wie mit der Resharper-Funktion

;-)

C#: LINQ und IEnumerable (non-generic)

Immer wieder falle ich darauf rein:
Da hat man eine Collection of Irgendwas, die man mal schnell mit einer Mengeoperation durchackern will, z.B. durchsuchen oder filtern. Zum Glück gibt's seit .NET 3.5 ja die tollen Extension Methods von LINQ. Also, simsalabim:

using System.Linq;

Und... nichts passiert :( . Intellisense zeigt mir trotzdem keine der Erweiterungsmethoden an. Warum? Tja... Da hat man es wohl mit einem Relikt aus den .NET 1.1-Zeiten zu tun, wie etwa CodeTypeMemberCollection oder DataColumnCollection. Diese Kameraden implementieren nur IEnumerable statt IEnumerable<>. Und ohne Typsicherheit keine typisierte Abfragerei, so einfach. Da hilft (beim ersten Mal hab ich echt lang danach gesucht) die Cast-Methode (die bekommen auch die untypisierten IEnumerables verpasst:

CodeTypeDeclaration type;
...
..
var member = type.Members.Cast<CodeTypeMember>().FirstOrDefault( t => t.Name == name );

Et voilà!

MultiTargeting im Visual Studio 2010

Hurra*, endlich umsteigen!

Visual Studio 2010 unterstützt Multitargeting, das heißt man kann sich aussuchen, für welchen .NET Framework einzelne Projekte übersetzt werden. Das wären 2.0, 3.0, 3.5, 3.5 Client Profile und 4.0, also im Endeffekt 2.0er-Runtime oder 4.0er-Runtime, der Rest ist nur Beschränkung der verwendbaren Assemblies.

Für die C#/VB-Assemblies kein Problem.

Wir haben leider gemischte Solutions, wo auch noch ein Haufen alter C++-Kram drin ist (managed/unmanaged gemischt). Nach der Migration steht dort als unterstützter .NET-Framework "4.0" drin, und zwar fix!

Und das ist die Lösung. Es geht nur 4.0! Mit manuellen Änderungen am Projektfile ist es möglich, Visual Studio 2010 dazu zu bewegen, mithilfe des C++-Compilers eines parallel installiert Visual Studio 2008 SP1 auch Assemblies zu erzeugen die sich mit < 4.0 vertragen (! GEHT'S NOCH?? !)

Ich glaub ich muß jetzt erstmal heimgehen...

*) Wieviel "hurra" oder nicht (sh. oben), das steht auf einem anderen Blatt, gehen wir einfach mal davon aus, ich will jetzt unbedingt VS2010, weil es viel besser ist als VS2008