Letzthin untersuchte ich das Startverhalten unserer neuen Software: Aus mir unklaren Gründen dauerte der Start des Programms deutlich länger als ich vermutet hätte. In solchen Fällen ist es immer sinnvoll, das Verhalten des Programms zu messen– und genau das habe ich also getan. Dazu verwende ich meistens den Profiler „dotTrace“ der Firma jetBrains.
DotTrace hat diverse Möglichkeiten das Laufzeitverhalten einer .NET Anwendung zu messen. Unter anderem kann man auf Funktionsebene sehen, wie viel Zeit eine einzelne Methode verbraucht hat. Da wurde ich relativ schnell fündig: Während das Programm geladen wird, werden mehrfach XmlSerializer erzeugt – und der Aufruf der Konstruktoren brauchte jeweils zwischen 300 und 600 MSecs.
Angesichts der Tatsache, dass die eigentliche Arbeit des XmlSerializers in Serialize() bzw. Deserialize() erledigt wird, erschien mir das ein bisschen sehr lange zu dauern. Stellte sich die Frage: Was passiert da eigentlich?
Praktischerweise ist diese Frage viel einfacher zu beantworten als man meinen möchte, denn um das herauszufinden braucht man nur einmal kurz Reflector anzuwerfen und kann sich dann den in C# umgesetzten MSIL Code der Xml-Assembly ansehen.
Man findet folgendes: Offenbar gibt es da nicht nur einen Cache von Assemblies, sondern auch irgendwelche „Generated“ Assemblies, die geladen werden können. Wenn das nicht klappt, dann erzeugt der XmlSerializer eine temporärer Assembly die dann zum (de)serialisieren verwendet wird. Die Überlegung dahinter ist relativ klar: Es wird davon ausgegangen, das im Zuge des deserialisierens sehr viele Objekte aus XML konvertiert werden sollen – da ist es einfach performanter, wenn man zur Laufzeit passende spezialisierte Klassen erzeugt, die die Konvertierung dann vornehmen. Und die Erzeugung dieser Klassen und deren Übersetzung in die temporäre Assembly braucht halt Zeit – Zeit, die sich dann beim Erzeugen der XmlSerializer-Instanz messbar bemerkbar macht. (Im Visual Studio kann man das übrigens sehen: Da wird dann im Ouput-Window eine Meldung angezeigt, laut der eine Assmebly mit mit "merkwürdigen" synthetisierten Namen geladen wurde.)
Dagegen ist also relativ wenig zu tun – es blieb aber die Frage offen: Was hat es mit diesen „Generated“ Assemblies auf sich, wo kommen die her, und warum werden die nicht verwendet? Auch diese Frage kann Reflector prima beantworten.
Schaut man sich nämlich den Code zu LoadGeneratedAssembly an, dann stellt man fest: Dort findet sich ein BooleanSwitch. Ist der eingeschaltet, dann schreibt der XmlSerializer Statusinformationen ins EventLog: Genau diese Informationen sind also von Interesse.
Im nächsten Schritt muss man sich also ein Application-Configuration File (app.config) anlegen, und dort den passenden Boolean eintragen. Den Namen des Boolean findet man, indem man sich per Reflector der Source zu PregenEventLog ansieht – und dort findet man dann „XmlSerialization.PregenEventLog“.
Unter diesem Namen trägt man dann den Boolean ein, setzt seinen Wert auf 1, startet das Programm – und findet dann einen informativen Eintrag im EventLog.
Doch leider – ganz so informativ wie erhofft ist der Eintrag dann nicht. Ich für meinen Teil vermute, das die echte Information beim Übersetzen verloren gegangen ist – doch eines kann man dem Eintrag auf jeden Fall entnehmen: Es gibt tatsächlich eine vordefinierte Assembly – nur kann der XmlSerializer die nicht verwenden.
Ein Blick ins Build-Verzeichnis der Anwendung klärt dann: Ja tatsächlich, es gibt eine „AssemblyName.XmlSerializers.dll“. Bleibt die Frage: Wo kommt die her, und warum funktioniert sie nicht?
Hier hilft nun ein bisschen Vorwissen: Mir war nämlich eigentlich von Anfang an klar, das diese Assembly existiert. Das Visual Studio hat nämlich in den Projekt-Settings eine Option, mit der man die Erzeugung dieser Assembly anwerfen kann. Ist diese Option eingeschaltet, dann wird nach dem übersetzen der Assembly das Tool „sgen“ angeworfen und erzeugt für die Assembly zusätzlich eine XmlSerializers-Assembly. Genau die versucht dann der XmlSerializer zu verwenden – und schafft das nicht.
Jetzt musste also ein bisschen Internet-Recherche herhalten. Die ergab dann folgendes: Die Option im VS 2005 existiert zwar, führt aber nicht ganz zu dem Ergebnis das man erwarten würde. Statt spezialisierte Varianten von XmlSerializern für alle Verwendungen innerhalb der Quell-Assembly zu bauen, werden nur solche für XmlSerializer erzeugt, die im Kontext von Web-Diensten zum Zuge kommen. Grund: Die Build-Regel mit der sgen aufgerufen wird, enthält den Kommandozeilenparamter /proxytypes – und der schränkt sgen in genau dieser Weise ein.
Man muss also das Build-System von VS so erweitern, das ein anderer Aufruf von sgen erfolgt – eben einer, der den „/proxytypes“ Parameter nicht enthält. Auch das ist aber einfacher als man meinen möchte.
Zunächst muss man dazu wissen, dass das komplette Build-System von Visual Studio im Wesentlichen auf MSBuild aufbaut – und das ist extrem flexibel. Im Fall eines CS-Projektes im Visual Studio sieht das ganze so aus: Das zum Projekt gehörende .csproj-File enthält im Kern eigentlich nur die „Projekt“-spezifischen Angaben. Hauptsächlich sind das die am Projekt beteiligten Dateien, externe Referenzen und ein paar Compiler-Optionen. Das Regelwerk das den Build-Vorgang steuert kommt aber aus statischen Dateien, die einfach in das „lokale“ Projekt inkludiert werden.
Nun kann man einfach ein eigenes „Target“ mit einer eigenen Build-Regel in das lokale Projekt aufnehmen – und beim Build-Vorgang wird dann diese Regel ausgewertet und der erwünschte Vorgang ausgeführt. Praktische Sachen, wenn man weiß, was man da eigentlich an welcher Stelle genau eintragen muss.
Mit ein wenig Hilfe von Grant war das aber auch einfach. In der Projekt-Datei findet sich (fast) am Ende das Import-Statement, mit dem die CSharp-Targets inkludiert werden: <Import Project=…>
Dahinter fügt man dann folgendes ein:
<!-- Begin of Change -->
<Target Name="GenerateSerializationAssembliesForAllTypes" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);@(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="@(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="$(SGenToolPath)">
<Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly"/>
</SGen>
</Target>
<Target Name="AfterBuild" DependsOnTargets="GenerateSerializationAssembliesForAllTypes"/>
<!-- End of Change -->
Es wird also ein Ziel namens „GenerateSerializationAssembliesForAllTypes“ angelegt und mit den passenden Abhängigkeiten und Inputs versorgt. Außerdem gibt man den gewünschten Aufruf für sgen und den gewünschten Ausgabenamen der Ziel-Assembly an: Fertig.
Genau das habe ich auch getan und dann mein Projekt neu übersetzt. Resultat: Gar keins. Ich hatte zwar (genau wie zuvor) eine XmlSerializers.dll – nur funktionierte die immer noch nicht.
Das wunderte mich natürlich ein bisschen. Die Suche nach der Ursache war dann aber einfach. Zunächst einmal habe ich das Build-Logging vom VS von „minimalistic“ auf „diagnostic“ umgestellt (Das geht in den Option von Visual Studio) und dann nochmal ein Build durchgeführt. Das brachte auch sofort die Erleuchtung: Im Projekt war die Option zum erzeugen der Serialization-Assemblies noch eingeschaltet, und darum wurde direkt nach dem bauen der eigentlich Assembly auch die Serialization-Assembly gebaut – aber eben noch mit der „alten“ Kommandozeile.
Danach kam dann das von mir eingeführte Target dran. Das hat aber den gleichen Namen und die gleichen Abhängigkeiten wie das ursprüngliche, und darum war die Assembly aus Sicht von MSBuild „up to date“. Resultat: Entsprechende Option im Studio abstellen, neu bauen: Und siehe da – es geht.
Abonnieren