Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik-Blog

Erste Dokumentation für Baustatik-Makros


In diesem Beitrag hatte ich ein erstes Beispiel für ein "Baustatik" Makro vorgestellt. Der Großteil dessen, was man für ein rudimentäres Makro benötigt, wird vom Makro-Editor automatisch bereitgestellt. Soweit ist die Sache ja klar - etwas unklarer wird es dann an der Stelle, an der die Knoten erzeugt werden: Woher weiss man, das sich die Knoten im Namespace "DIE.Applications.Faltwerk.Objects.Nodes" befinden und man oben im Makro ein entsprechende "using" Statement braucht, woher weiss man das die Objekte "Node" genannt werden - und woher weiss man eigentlich, welche Objekte es sonst noch so alles gibt?

Lauter gute Fragen - hier ein paar Antworten. Der erste und einfachste - dafür aber nicht vollständige - Weg ist der hier: Sie können von hier eine Hilfe-Datei (Baustatik.chm ca. 15 MB) herunterladen, in der die erste verfügbare Dokumentation zusammengefasst ist. (Wenn der Browser fragt, ob die Datei geöffnet oder heruntergeladen werden soll: Laden Sie die herunter, und öffnen Sie sie erst lokal auf dem eigenen Rechner. Das beschleunigt die Sache, wenn Sie später nochmals reinsehen möchten.)

Es gibt nun eine etwas aktuellere Online-Variante: Dokumentation für die Programmierung mit dem Faltwerk in der Baustatik.

Dabei handelt es sich nicht um die vollständige Programmier-Dokumentation für "Baustatik" sondern nur um die erste Version davon. Enthalten sind alle Faltwerks-Objekte (die finden sich in den Namensräumen "DIE.Applications.Faltwerk.Objects.*"), sowie die Objekte, mit denen man auf Berechnugsergebnisse zugreifen kann ( "DIE.Applications.Faltwerk.Results.*" ).

Außerdem gibts ein paar interessante und hilfreiche Objekte für geometrische Operationen in "DIE.Geometry.*".

Mit dieser Hilfedatei sollte man schon relativ weit kommen. Wer noch mehr braucht, und zwar bevor wir zusätzliche Dokumentation bereitstellen können, hat aber auch dafür diverse Möglichkeiten.

Das erste Tool wäre der kostenlose Reflektor. Damit kann man sich den Inhalt von Assemblies ansehen - man braucht also bloss die installierten DLLs von "Baustatik" damit zu betrachten.

Darüber hinaus geht das ähnlich auch mit Visual C# Express, mit dem man übrigens auch Makros programmieren kann: Im wesentlichen legt man dort ein Projekt an, fügt Referenzen zu den Assemblies hinzu - und hat Zugriff auf alle Methoden und Eigenschaften der Objekte. (Zur Entwicklung von Makros mit C# Express schreibe ich zu einem späteren Zeitpunkt nochmals etwas.)


Makros in "Baustatik"


Die neue Baustatik-Umgebung (zur Zeit mit dem Faltwerk und dem Dachprogramm) ist vollständig programmierbar - wer also will, kann eigene "Makros" schreiben, um den Funktionsumfang zu erweitern. Die Programmiermöglichkeit geht dabei sehr weit: Man kann den eingebauten Makro-Editor verwenden (die einfachste aber am wenigsten komfortable Methode), aber auch die (kostenlosen) Express-Ausgaben der Entwicklungsumgebungen von Microsoft - bis hin zum professionellen Visual Studio.

Ich habe vor im Laufe der Zeit an dieser Stelle häufiger auf die Makros einzugehen, heute will ich aber nur ein kurzes Beispiel für den Einstieg anbringen: Programmiert wird dabei nicht mit einem der externen Tools, sondern mit dem einfachen eingebauten Makro-Editor.

Um ein neues Makro anzulegen, klickt man auf Optionen -> Makro -> Makro erstellen.

Das öffnet ein Fenster, in dem man verschiedene Dinge eingeben kann:

  • Makroname: Das ist der Name, unter dem das Makro später wieder gefunden werden kann.
  • Namensraum: Für den Anfang uninteressant. Lassen Sie hier ruhig "MeineMakros" stehen.
  • Kurzbeschreibung: Ein kurzer Text, der das Makro beschreibt. Dieser Text erscheint später hinter dem Namen des Makros.
  • Dateiname: Name der Datei, in der das Makro abgelegt werden soll.
  • Programmiersprache: Entweder CSharp (C#) oder VisualBasic - meine Beispiele werden alle in CSharp verfasst sein. (Mit den externen Tools wie Visual Studio (Express) können Sie auch in anderen Sprachen programmieren - jede .Net fähige Sprache ist uns Recht. [Hint: Nehmen Sie C#])

Dann klickt man "Erstellen" - und dann hat man auch schon sein erstes eigenes Makro. Das wird in einem Textfenster angezeigt, in dem man auch editieren kann. Das Makro tut zwar noch nicht viel - man kann es aber bereits laufen lassen. Das geht, indem man auf den grünen Pfeil in der Werkzeugleiste des Editors klickt: Das Makro wird dann ausgeführt - und zeigt eine Meldungsbox an.

Im folgenden wird das Makro nun erweitert, um Knoten für eine Faltwerksdatei zu erzeugen.

Ganz oben im Makro-Editor sehen Sie die Zeile "using System;" - direkt darunter fügen Sie dann die folgende Zeile ein:

using DIE.Applications.Faltwerk.Objects.Nodes;

Damit wird der Namensraum der Knoten (Nodes) dem Makro bekannt gemacht. Was ein Namensraum ist müssen Sie eigentlich nicht wissen - was Sie wissen müssen ist: Wegen dieser Zeile können Sie später im Makro die Objekte vom Typ "Node" (die Knoten) verwenden.

Dann kommen einen Zeilen, die automatisch für Sie erzeugt wurden und nur der Infrastruktur dienen: Die können Sie getrost ignorieren - der interessante Teil kommt bei der Zeile:

public override void Execute(IExecuteCommandContext context)

Bei dieser Zeile startet das eigentliche Makro: Im automatisch erzeugten Code finden Sie im Funktionskörper der Funktion "Execute" den Ausdruck, der das Meldungsfenster anzeigt. Den können Sie eigentlich löschen, und dann das gewünschte Makro schreiben: Das Makro soll einfach ein regelmässiges Feld aus Knoten erzeugen. Das geschieht mit 2 Schleifen: In der einen wird der Wert für x gesetzt, die andere (innere) setzt einen Wert für Y. Die Z-Koordinate wird einfach immer auf 0 gesetzt. Das sieht dann so aus:

for( double x =0; x<12; x+=4)
{
   for( double y =0; y<7; y++)
   {

X nimmt also die Werte "0", "4", und "8" an. Für jeden dieser Werte nimmt Y alle Werte von "0" bis "6" an. Mit diesen Werten wird dann ein Knoten erzeugt, und dem neuen Knoten werden seine Koordinaten zugewiesen:

 Node node = new Node();
 node.X = x;
 node.Y = y;
 node.Z = 0.0;

Zuletzt muss der Knoten noch in das aktuelle Dokument getan werden: Dadurch erscheint er auch in der Dokumenten-Ansicht, in den graphischen Fenstern und in der Tabellen-Ansicht:

context.TargetDocument.AddObject( node);

Wie man sieht: Die Sache ist wirklich einfach - und ungeheuer mächtig. Mit Makros können Sie nicht nur Objekte erzeugen - Sie können diese auch verändern, Sie können Ergebnisse erfragen - und unter Umständen berechnungen auf Basis der Schnittgrößen durchführen, die wir von Haus aus nicht mitliefern. Und: Makros können auch eigene Fenster haben - wer will kann also auch komplett eigene Dialogboxen programmieren. Ich will versuchen, alle diese Bereiche hier in Zukunft abzudecken, da die Dokumentation zu den Makros momentan leider sehr spärlich ist.

Knotenfeld.cs (.6 KB)

Debug.Assert() - eher ein Kommentar


Nimmt ein eher Debug.Assert() oder eher "throw new XXXException()" - offenbar eine Frage über die sich häufig zu wenig Gedanken gemacht wird.

Die Kurzanleitung lautet: Debug.Assert() nimmt man besser nie.

Etwas mehr Hintergrund:
Letztlich dient sowohl das werfen einer Exception als auch Debug.Assert() der Fehlersuche. Beim Assert() stellt man sicher, das eine bestimmte Bedingung vorliegt, was allerdings nur in Debug-Builds (also nicht beim Anwender der Software) passiert. Wirft man eine Exception, so verhält sich die Sache anders: Der Test der Bedingung findet vor dem werfen der Exception statt - und beides passiert sowohl in Debug- als auch in Release-Builds.

Man muss sich die Frage stellen: Was will man eigentlich erreichen, wenn eine Fehlerbedingung eintritt. Und die Antwort ist da relativ einfach: Mal will, das das Programm abstürzt - und zwar so schnell wie möglich (und wenn irgend möglich, auch mit einer passenden Fehlermeldung - am besten mit einer, die man auch noch gleich auf einen eigenen Mail- oder Webserver transportieren kann.).

Mit "so schnell wie möglich" ist gemeint, das das Programm möglichst nicht mit einem fehlerhaften Zustand weiterbetrieben werden sollte, denn das führt nur dazu, das Folgefehler auftreten: Die machen es aber schwieriger, das eigentliche Problem zu diagnostizieren. Behandelt man aber Fehler mit Debug.Assert(), und tritt der Fehler dann beim Anwender - also in einem Release-Build - auf, dann läuft das Programm einfach ganz "normal" weiter - nur eben in einem Zustand, für das es nicht gedacht war. Dieser Zustand für dann dazu, das es zu einem späteren Zeitpunkt und an einer ganz anderen Stelle ganz sicher zu einem Absturz kommt - und zwar zu einem, dessen Ursache nicht mehr zu erklären ist: Ein Zustand, der bei der verwendung einer Exception statt eines Assert()s erst gar nicht eintreten würde.

In den allermeisten Fällen reicht es schon aus, einfach nur die eingehenden Parameter einer Funktion zu prüfen - und das dürfte praktisch nie ein Performance-Problem machen. (In den seltenen Fällen wo das vielleicht doch mal der Fall ist, nimmt man halt eben doch mal Debug.Assert()). Passt ein Parameter nicht, wirft man eine Exception.

Ein Debug.Assert() ist bestenfalls eine Art sehr deutlicher Kommentar, aber kein sinnvoller Mechanismus für die Qualitätssicherung.


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.




Baustatik Demoversion ausprobieren »