Entity Framework bremst Visual Studio aus

Screenshot des Programms Process Monitor

Seit ein paar Tagen öffnete sich mein Visual Studio WPF Designer (XAML View) nur noch nach einer langen Wartezeit, oder manchmal auch gar nicht. Endloses Warten, ohne Aussicht auf Besserung.
Nach mehreren langen Web-Such-Sessions fand ich heute den entscheidenden Hinweis. Man sollte doch mit dem Tool Process Montitor von Windows SysInternals mal nachsehen, was Visual Studio während der Ladezeit macht.

Kaum gelesen, schon war das Tool runtergeladen und lief. Das Tool ist verständlich und kann bei fremden Programmen wirklich viel helfen. Es gibt ein Fadenkreuz, welches man auf ein Fenster des zu beobachtenden Prozesses zieht. Anschließend sind die Meldungen so gefiltert, dass nur die Meldungen des gewünschten Prozesses zu sehen sind. Ich habe das Tool parallel laufen lassen und konnte relativ schnell eine interessante Beobachtung machen. Wie im Screenshot zu sehen führte devenv.exe (VS2010) ca. 30 UDP Send Operationen aus. Auffällig ist dabei, das man in der Spalte Path sehen kann, wie der Port entsprechend hochgezählt wird. 000000.000 ist der entfernte Rechnername inklusive Domain. Visual Studio scheint nach einem passenden Port zu suchen. Nach ca. 1 – 2 Minuten stellt Visual Studio diese Suche dann ein und öffnet wie gewünscht den Editor. Was war geschehen?

Der Titel des Artikels verrät die Antwort. Das Entity Framework ist schuld. Ich habe einen Datencontext, welcher seinen Connection-String per Convention over Configuration aus der app.config bekommt. Dabei entspricht der Schlüssel des ConnectionStrings dem Namen des Contextes. Dieser Context wird im ViewModelLocator ins ViewModel injiziert. Nun lädt Visual Studio das ViewModel durch den ViewModelLocator aber auch wenn der Editor geöffnet wird. Dabei läuft der Code aber nicht mit der app.config meiner Anwendung, sondern mit der von Visual Studio. Hierdurch ist keine passende Konfiguration vorhanden und das Entity Framework begibt sich auf die Suche. Dabei wird unter anderem der Portscan durchgeführt, der sehr zeitaufwändig ist.

Die Lösung des Problems ist das Mvvm Light Toolkit, welches ich schon einsetzte. Dieses beinhaltet die Property ViewModelBase.IsInDesignModeStatic, welche angibt, ob der Code gerade im Designer läuft. Im ViewModelLocator kann man dann reagieren und statt des Context des Entity Frameworks einfache Objektdaten übergeben. Voraussetzung hierfür ist die Einführung einer Schnittstelle, welche vom Entity Framework und den Objektdaten implementiert wird. Jetzt lädt der Designer wieder schnell!

Das gezeigte Verhalten kann natürlich auch in richtigen Anwendungen zum Ärgernis werden, wenn die Konfigurationsdatei beispielsweise fehlt. Bevor eine Fehlermeldung kommt, würde einige Zeit vergehen, in der das Entity Framework nach einem passenden Server sucht. Ich habe allerdings noch nicht im Quellcode nachgesehen, der ja mittlerweile als Open Source vorliegt. Dies werde ich bei Gelegenheit nachholen.

Test der codierten UI

Als Student kann man tolle Programme ausprobieren. Ich wollte gerade einen „Test der codierten UI“, also einen aufgezeichneten Oberflächentest ausprobieren. Die Erstellung des Tests lief wunderbar, aber der generierte Test ließ sich nicht kompilieren. Ich habe eine weile gebraucht um zu verstehen, warum nicht. Eine Referenz konnte nicht aufgelöst werden, weshalb die Importe für diesen Test als fehlerhaft markiert wurden. Nach etwas suchen fand ich raus, dass diese GUI-Tests neu im .Net-Framework 4 sind.
Der Fehler war nun gefunden. In den Projekteinstellungen unter Kompilieren -> Erweiterte Kompilieroptionen war als Zielframework 3.5 angegeben, welches die Referenzen nicht besitzt. So einfach kann das manchmal sein.
Jetzt klappt es und sieht sehr nützlich aus. Demnächst kann ich evtl. Zeit sparen, indem ich Tests schreibe und ausführe anstatt manuell rumzuklickern.