Thomas Woelfers Baustatik Blog

Baustatik-Software und was sonst des Weges kommt

Neue Updates verfügbar

Ab sofort verfügbar: Ein Update für das Mauerwerksprogramm Xmau sowie für das Stützenprogramm Xksn. Details wie immer im Update-Protokoll im Download-Bereich. Bei Xmau gibt es übrigens auch ein erweitertes Handbuch - das findet sich im Downloadbereich innerhalb der Datei "Handbuecher.zip".

Automatische und manuelle Updates

Unsere neue Programmoberfläche "Baustatik" verfügt über eine Funktion, mit der das Programm Updates automatisch aus dem Internet herunterladen kann. Beim Start überprüft das Programm, ob es eine neue Version auf unserem Webserver finden kann. Ist das der Fall, dann lädt es diese Version herunter und plaziert Sie auf dem Desktop. Von dort aus kann das Programm dann einfach installiert werden.

Wer die automatischen Updates nicht mag, der kann die natürlich in der Programmoptionen abstellen. Wie kommt man dann aber an neue Versionen? Ganz einfach: Genau wie früher - im Downloadbereich unseres Webservers liegen die aktuellen Programmversionen weiterhin zum download bereit.

Zur Zeit gibt es dort 3 Dateien: handbuecher.zip, setup.zip und baustatik_setup.zip.

"Handbuecher" enthält die Handbücher zu den Programmen im Word-Format. "setup" enthält den Installer für die "alten" Programme wie Xpla, Xrst, Xdur und soweiter. "baustatik_setup" enthält den Installer für die neuen Programme. Zur Zeit sind die das Faltwerkprogramm und das Dachprogramm mit der neuen Holzbaunorm.

XmlSerializer beschleunigen

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.

Neue Updates verfügbar

Ab sofort im Downloadbereich zu haben: Eine neue Version von "Baustatik" - darin enthalten: Das Faltwerkprogramm und das Dachprogramm mit der neuen Holzbaunorm. Im Wesentlichen wurden zwei Probleme im Dach beseitigt, außerdem startet das Programm (je nach Rechner) jetzt etwa in der Hälfte der Zeit wie zuvor.

Wichtig: Im Prinzip erhalten Sie dieses Update automatisch über die automatischen Updates. Wenn Sie aber noch eine Beta-Version verwenden (also eine Version < 1.7 ), dann müssen Sie in diesem Fall auf jeden Fall das Update von unserem Webserver und NICHT das Update, das Sie per automatischen Updates erhalten verwenden.

Der Grund dafür ist dieser: Die per automatischen Updates heruntergeladenen Dateien unterscheiden sich von denen, die Sie manuelle vom Webserver runterladen können. Auf dem Webserver finden Sie immer nur die "vollständige" Version - also eine, die auch Komponenten wie die .NET 2.0 CLR enthält. Wenn man Updates per automatischen Updates herunterlädt, dann bedeutet das aber, das diese Komponenten bereits installiert sind: Schließlich läuft das Programm ja bereits. Aus diesem Grund ist das "automatische" Update deutlich kleiner als das "manuelle".

Nun ist es aber so, das sich einige der "Fremd" Komponenten im Zuge des Betas verändert haben: Diese Änderung liegt daher also nur im "manuellen" Update vor, und nicht im "automatischen".

Einstellungen, selbst definierte Profile und Materialien wiederverwenden

Bei allen unseren Programmen kann man Farben, Strichstärken, Schriftarten und viele andere Optionen für die Darstellungsweise der Elemente in der Graphik einstellen. Außerdem ist es möglich, selber Profile und Materialien zu definieren. Lästig ist es, wenn man diese Einstellungen auf mehreren Rechnern vornehmen muss. Statt alle Einstellungen von Hand vorzunehmen, kann man aber einfach die Dateien mit den Einstellungen auf den anderen Rechner kopieren. Das geht so:

Profile und Materialien befinden sich in Dateien im Ordner "\Programme\DIE\Sys". Die Dateien haben Namen, die mit dem Text "User" anfangen - also z.b. "UserProfiles.data". Wenn Sie diese Dateien auf den anderen Rechner kopieren, liegen dort sofort alle selbst definierten Materialien und Profile vor. Für die Einstellungen wie Farben und Strichstärken muss man ein bisschen mehr tun. Zunächst braucht man das Programm "Regedit". Das startet Sie einfach dadurch, indem Sie in der Textbox "Ausführen" im Start-Menü den Programmnamen eingeben und "Return" drücken. Das Programm sieht so ähnlich aus wie der Windows Explorer. Links wird ein Baum dargestellt. Darin öffnen Sie die Ordner HKEY_CURRENT_USER\Software\DIE und markieren "DIE". Dann öffnen Sie das "Datei" Menü (das bei einigen Windows-Versionen "Registrierung" genannt wird) und wählen dort den Befehl "Exportieren". Sie können dann einen Dateinamen angeben. In dies Datei werden die Einstellungen dann gespeichert. Die Datei kopieren Sie dann auf den anderen Rechner, und starten dort wieder "Regedit". Über das Menü "Datei" (oder "Registrierung") finden Sie den Befehl "Importieren". Damit importieren Sie die kopierte Datei.

Diese Beschreibung gilt für alle Programme außer der neuen "Baustatik". Wie es dort geht, beschreibe ich zu einem anderen Zeitpunkt.