Thomas Woelfers Baustatik Blog

Baustatik-Software und was sonst des Weges kommt

So sieht der vollständige Installationsvorgang aus

Das Setup der Baustatik teilt sich in mehrere Teile, und ab der nächsten Version läuft die Sache ein bisschen anders ab als bisher. Ein guter Zeitpunkt, das kommende Setup einmal kurz vorzustellen.

Vorab gilt natürlich: Das hier abgebildete Setup in allen Einzelschritten sieht man nur dann, wenn man von CD oder einer heruntergeladenen Komplettversion installiert – die (voll)automatischen Updates sind quasi unsichtbar. Außerdem: Nicht alle Schritte die hier abgebildet sind, treten in allen Fällen auf – das habe ich dann aber beim einzelnen Schritt markiert.

Der erste Tell des Installationsprogramms kümmert sich um Systemvoraussetzungen, und dies sind das .NET Framework in einer bestimmten Version sowie die C++ Laufzeitbibliotheken. Nach dem Start geht es mit dieser Meldung los:

Unbenannt3

Zu diesem Zeitpunkt untersucht das Programm, welche Voraussetzungen installiert werden müssen. Ist die richtige Version der .NET Frameworks nicht vorhanden, gibt es als nächstes folgendes Fenster. Ist die richtige Version schon installiert, geht es direkt mit der Installation der C++ Laufzeitbibliotheken weiter,

Unbenannt

Das Programm extrahiert dabei die von uns verwendete Version des Frameworks – bzw. dessen Installationsprogramm. Das äußert sich so:

Unbenannt11

Nachdem das Installationsprogramm für .NET extrahiert wurde, wird es gestartet. Das sieht dann so aus:

Unbenannt13

Nach diesem Schritt überprüft das .NET Installationsprogramm, ob eventuell irgendwelche .NET Anwendungen laufen. Die kann man entweder anhalten oder nicht – hält man die nicht an, dann muss man nach der Installation des Frameworks den Rechner neu starten. Es macht also auf jeden Fall mehr Sinn, solche Programme anzuhalten. Wenn derartige Programme vorliegen, kommt folgende Meldung:

Unbenannt12

Wenn das erledigt ist, erfolgt der eigentliche Installationsvorgang fürs .NET Framework. Das sieht dann so aus:

Unbenannt14

Wenn dieser Vorgang abgeschlossen ist, werden weitere Systemvoraussetzungen installiert. Zunächst kommt die 32bit-C++ Laufzeitbibliothek dran. Die meldet sich mit diesem Fenster. Das Fenster geht immer auch – ganz gleich ob die richtige Version der C++ Laufzeit schon vorhanden ist. Ist sie es, bleibt das Fenster nur sehr kurz geöffnet, weil gar nichts installiert wird. Im anderen Fall dauert es ein bisschen länger.

Unbenannt2

Auf 64bit Systemen kommt als nächstes die 64bit C++ Laufzeitbibliothek dran:

Unbenannt4

Wenn das alles erledigt ist gibt es ein Fenster mit dem Text “Extrahiere die Daten der Hauptanwendung”. Davon habe ich leider keinen Screenshot, weil das Fenster bei mir so schnell wieder verschwindet, das ich davon einfach keinen machen kann…. Danach startet aber dann tatsächlich das eigentliche Installationsprogramm der Baustatik. Und das meldet sich mit diesem Fenster:

Unbenannt5

Man drückt hier auf weiter, und wird dann gefragt, welche Verknüpfungen im Windows-System angelegt werden sollen. Ich rate davon ab, dabei irgendwas auszuschalten – es sei denn, man weiss ganz genau, was man da tut. (Wenn ich diese Options-Seite im Installationsprogramm irgendwie ausschalten könnte, ich würde es tun…)

Unbenannt6

Danach fragt das Programm, wohin die Baustatik installiert werden soll. Ich empfehle auch hier, die voreingestellten Werte zu übernehmen.

Unbenannt7png

Damit sind dann alle Angaben für die Installation erfasst, und das Installationsprogramm weist auch darauf hin. Wenn man dann im folgenden Fenster auf “Weiter” klickt, startet die Installation.

Unbenannt8

Die Installation an sich verläuft dann immer im gleichen Fenster: Nur die Position des Fortschrittsmelders und der angezeigte Text ändern sich. Meistens sieht das ungefähr so aus:

Unbenannt10

Und das wars auch schon: Am Ende gibt es nur noch einen Hinweis, das die Installation nun abgeschlossen ist.

Die ganze Sache sieht natürlich ziemlich aufwendig ist – und das ist sie auch. Lange dauern tut das aber nicht. Auf meinem PC läuft die komplette Geschichte in ca. 30 Sekunden durch – und mein PC ist nicht besonders “State of the Art”. Wenn es wesentlich länger dauert, sollte man mal über neue Hardware nachdenken Smiley

Das bedeuten die Dateinamen

Wer schon mal einen Blick in das Installationsverzeichnis der Baustatik gewagt hat, hat festgestellt, das die Namen der Dateien darin einem gewissen Muster folgen. Aber was bedeutet dieses Muster?

Eigentlich ist es ganz einfach: Die Baustatik ist ein relativ komplexes Programm, und wie bei allen Dingen die komplex sind, braucht es eine gewisse Ordnung, damit sich alle zurecht finden. Bei den Installationsdateien der Baustatik geht das eben über den Dateinamen, und da gibt es folgende Kategorien:

Alle Dateien, die mit “framework.” anfangen, sind .NET Assemblies, die zu unserer Benutzerinterface-Bibliothek gehören. Diese Dateien enthalten Programmcode, der von allen Dokumenten gleichartig verwendet wird.

Alle Dateien die mit “kernel.managed” anfangen, sind .NET Assemblies, die zu den diversen Rechen-Kernen gehören. Alle, die mit “kernel.native” anfangen, sind native (32 oder 64 bit) Programmodule, die die Rechenkerne enthalten,die der Rest des Namens verrät. kernel.native.calculations.fem enthält also zum Beispiel den FEM-Kern.

Alle Dateien die auf “64.dll” enden, sind speziell für 64bit CPUs übersetzter Programmcode. Diese Endung gibt es nur bei den “nativen” DLLs, weil eine spezielle 64bit Übersetzung für .NET Assemblies nicht notwendig ist: Der endgültige Code wird bei denen erst zum Start auf dem Zielsystem erzeugt (das passiert im wesentlichen beim Installieren), sodas es bei diesen im Zuge der Installation keine Namensunterschiede zwischen 32bit und 64bit Modulen gibt.

Alle Dateien die mit “x” anfangen (xdach… xdur…) enthalten den Programmcode der speziell für die Benutzerschnittstelle eines Dokumentes zuständig ist. xdach…. enthält also zum Beispiel den Dach-spezifischen Code.

Alle anderen DLL-Dateien sind Komponenten von Drittherstellern, bei denen wir keinen Einfluss auf den Namen haben. Die mit “sql” beginnenden sind zum Beispiel von Microsoft stammende Dateien die den Programmcode für die von uns benutze SQL-Server Variante enthalten.

Happy Birthday, Blog !

Heute vor 12 Jahren gab es meinen ersten Blog-Beitrag, und der letzte Geburtstagswunsch war natürlich vor einem Jahr. In diesem letzten Jahr ist viel passiert – auch bei der Anwendung der BaustatikSmiley

Eine große Änderung des letzten Jahres: Lange Zeit nachdem Microsoft Windows XP nicht mehr unterstützte haben auch wir damit aufgehört, weiter für XP zu entwickeln. Für alle, die nicht auf irgendwas modernes wechseln können oder wollen, gibt es noch eine “alte” Version der Baustatik, die unter XP läuft, aber alle neuen Versionen brauchen ein aktuelleres Betriebssystem. Das ist auch bei den Anwendern angekommen – laut unseren Telemetriedaten gibt es – alle Kunden, Studenten, Demos- und Hochschulversionen zusammengenommen – noch insgesamt 8 (!) Rechner, auf denen die Baustatik läuft, und die noch immer Windows XP verwenden. Wäre übrigens echt mal an der Zeit, die upzudaten Smiley

Seit letztem Sommer gibt es Windows 10, und das kommt zur Zeit etwa AUF 25% aller Rechner mit Baustatik zum Einsatz. Tendenz steigend – was wohl auch nicht verwunderlich ist.

In der Baustatik gab es natürlich auch jede Menge Veränderungen und Neuheiten. Nicht zuletzt ist da die Ankunft der ersten “richtigen” Lastweiterleitung mit dabei – und davon kommen im Laufe der nächsten Zeit jede Menge weitere Teile dazu. Man darf auf die nächsten Monate gespannt sein …

Was gerade passiert …

Wir sind gerade dabei unser “komplettes” Toolset umzustellen: Es gibt unter anderem einen neuen Compiler (eigentlich 2), einen neuen Gleichungslöser und einen neuen Netzgenerator. (Die beiden letzten “neuen” sind eigentlich ein Resultat des neuen Compilers..)

Diese Umstellung braucht etwas mehr Zeit, als ich ursprünglich angenommen hatte – darum zieht sich die Sache ein bisschen.

Erste Resultate sind aber schon da, und die sind recht vielversprechend: Ohne “weitere” Maßnahmen sieht es so aus, als würden die Berechnungen deutlich schneller laufen, als zuvor. Zumindest die Testberechnungen brauchen statt bisher etwa 100 Minuten etwas weniger als 70. Ich denke aber, das wir noch ein bisschen mehr umbauen werden, als “nur” den Compiler – und das da auch noch mehr Rechengeschwindigkeit bei rausspringen wird. Ist aber nur so ein Gefühl – genaueres, wenn ich mir etwas sicherer bin Smiley

TuneUpUtilities–Just say No!

Ich kann es gar nicht oft genug sagen: Installieren Sie die “TuneUpUtilities” NICHT. Ich hatte gerade mal wieder ein Gespräch mit einem Kunden, der das doch getan hatte. Leider Pech gehabt: Dieses “Tool” führt Änderungen an einer normalen Windows-Installation vor, die eindeutig zu Folgeproblemen, teilweise in größerem Umfang führen.

Im Beispiel heute konnte man das Installationsprogramm der Baustatik nicht einmal mehr starten. Dabei ist das Installationsprogramm nichts ungewöhnliches: Es handelt sich um ein stinknormales Windows-Installer MSI File – die komplette Installation wird vom Windows Installer durchgeführt. Nur eben nicht, wenn die TuneUpUtilities installiert sind.

Kaum waren die deinstalliert, lief alles so, wie man das erwarten würde. Darum nochmal: Hände weg von TuneUpUtilities. Wer das aber schon installiert hat: Einfach deinstallieren – vermutlich verschwinden dann diverse Probleme die man mit dem Rechner hat auch gleich mit.

Baustatik-Update: Leider noch ein Problem

Bei der Korrektur-Version die wir gestern veröffentlicht haben, trat leider auch ein Problem auf. Die Korrektur hatte eigentlich nur die eine Änderung, das einige der Programmdateien (i.b. der Timeserver) nicht mehr digital signiert waren. Trotzdem waren im zugehörigen Installationsprogramm defekte Datenbank-Tabellen enthalten. Ich kann mir das eigentlich nur mit einem nicht erkannten Festplattendefekt erklären – denn die zugehörigen Quelldateien waren unbeschädigt, und die daraus resultierenden Dateien in der Vorversion völlig ok. Nach dem erneuten Herstellen des Installationsprogramms verschwand das Problem auch wieder, ohne das irgendwelche Veränderungen vorgenommen wurden.

Wie dem auch sei: Ich habe gerade nochmal eine neue Version (140) veröffentlicht, bei der keine der Probleme mehr auftreten. Um sicherzustellen das auch das Installationsprogramm nicht beschädigt ist, habe ich auch dieses nochmal manuell auf einen anderen Rechner transferiert und getestet: Es sollte nun wirklich nichts mehr auftreten.

Für die Zukunft müssen wir uns offensichtlich noch einen Mechanismus einfallen lassen, mit dem nicht nur die Baustatik an sich mit Testfällen geprüft wird, sondern auch das Installationsprogramm dafür.

So wird man das Problem nach dem Update auf Version 138 wieder los

Durch die Installation des Updates auf Version 138 (vom 3.2.2016) kam es bei einigen Kunden zu einem Problem im Zusammenhang mit dem TimeServer und bei anderen im Zusammenhang mit den “alten” XFEMily Programmen.

Dummerweise ist das TimeServer-Problem etwas nervig: Der TimeServer stürzt beim starten ab, und wird dann immer wieder automatisch gestartet. Das macht es, falls der TimeServer automatisch gestartet wird, praktisch unmöglich ein weiteres Update zur Korrektur zu installieren. Man muss also den TimeServer aus der Autostart-Gruppe von Windows entfernen. Das ist allerdings je nach Version von Windows auf eine andere Art zu erledigen. Um die Sache einfacher zu gestalten, können Sie den folgenden Schritten folgen: Die beseitigen das Problem.

  • Deinstallieren Sie “DIE Anwendungen” über die Systemsteuerung
  • Wichtig: Starten Sie den Rechner jetzt neu
  • Laden Sie die aktuelle Version (139) aus dem Download-Bereich von www.die.de herunter
  • Installieren Sie diese Version

Danach läuft alles wieder wie gehabt.

Ich entschuldige mich für die Störung. Den eigentlichen Grund suche ich noch, diese Update behebt aber auf jeden Fall die störenden Symptome.

Betriebssystem-Update wäre jetzt notwendig

Die allermeisten der Baustatik-Anwender verwenden ein “aktuelles” Betriebssystem: Etwa 75% verwenden Windows 7 mit aktuellem Service-Pack, 24% verwenden Windows 81 und Windows 10, und nur 1% verwenden Windows XP oder Windows 8. (Und irgendwo gibt es auch mindestens einen Windows-Vista User…)

Das Windows XP schon seit langem von Microsoft nicht mehr unterstützt wird, darauf habe ich schon mehrfach hingewiesen: Wer noch immer XP benutzt, sitzt eigentlich auf einem einzigen großen Sicherheitsleck, denn es gibt seit langer Zeit keine Sicherheitsupdates mehr für XP, und es wird auch in Zukunft keine geben. Man sollte wirklich updaten.

Seit gestern ist aber auch der Support für Windows 8 ausgelaufen, und wer noch 8 verwendet, sollte schleunigst – mindesten auf 8.1 updaten. Das Update ist kostenlos und über den Windows-Store erhältlich. Mit 8.1 bekommt man dann auch wieder einen langjährigen Support von Microsoft: 8.1 wird bis 2023 unterstützt. Alternativ kann man auch kostenlos auf Windows 10 umsteigen – das gilt übrigens auch für die Windows Vista und Windows 7 Nutzer – in dem Fall gibt es Support bis ins Jahr 2025.

Ich empfehle:

  • Wenn Sie XP verwenden: Ein Update auf Windows 10 durchführen. (Vermutlich ist der Rechner dann auch schon recht alt – es könnte nicht schaden in dem Fall auch mal über neue Hardware nachzudenken.) Unabhängig davon: Sie erhalten bei XP auch keine Updates mehr von uns – und die neuen Baustatik-Versionen können einige sehr interessante Dinge, die man bei XP eben einfach nicht bekommt.
  • Wenn Sie Vista verwenden: Auf Windows 10 updaten
  • Wenn Sie Windows 7 (Mit SP1) verwenden: Man muss nicht zwingend tätig werden. Allerdings gibt es das Update auf Windows 10 zur Zeit noch kostenlos, aber das wird nicht so bleiben. Der Support wird 2020 beenden, mit dem Update auf 10 gewinnt man also außerdem noch 5 Jahre.
  • Wenn Sie Windows 8 verwenden: Auf jeden Fall auf 8.1, oder besser auf 10 updaten.
  • Wenn Sie Windows 8.1 verwenden: Es ist nicht dringend notwendig, etwas zu unternehmen. Es gilt aber auch, das man eben jetzt noch ein kostenloses Update auf 10 bekommt. Außerdem kann man mit 10 definitiv besser arbeiten, als mit 8.1. Ich würde daher updaten.

Details zum Support-Lebenszyklus von Windows finden Sie hier.

Umstellung bei der Infrastruktur

In nicht gerade regelmäßigen Abständen müssen wir bei uns Änderungen an der Infrastruktur vornehmen – und in den Weihnachtsferien dieses Jahr war unsere Revision Control System dran: Dabei haben wir nicht nur ein Update durchgeführt, sondern gleich auch das Produkt gewechselt. Das alte Vault wurde durch die Visual Studio Team Services (früher Visual Studio Online) ersetzt. (Über lang oder kurz werden wir wohl auch mit unserem Issue-Tracking System diesen Wechsel vollziehen.)

So ein Wechsel ist nicht ganz so einfach, denn es hängen viele Dinge direkt vom Repository ab: Zunächst mal arbeiten natürlich alle Entwickler damit – das ist ja der Kern der Sache: Neben der Versionsverwaltung (sowas haben Sie übrigens auch in der Baustatik) ermöglicht RCS eben auch die parallele Arbeit mehrere Entwickler am gleichen Projekt. Wechselt man also die Verwaltung, müssen auch die Arbeitsplätze aller Entwickler umgestellt werden. Darüber hinaus haben wir aber auch noch andere Dinge, die an das Repository angekoppelt sind. So wird zum Beispiel die online verfügbare Dokumentation der Baustatik einmal pro Tag automatisch auf den neues Stand gebracht: Jedesmal, wenn jemand bei uns eine Änderung an der Dokumentation vornimmt und diese ins Repository eincheckt, landet diese Änderung spätestens nach 24 Stunden auch automatisch auf unserer Webseite. Auch dieser Mechanismus musste also an das neue Tool angepasst werden.

Darüber hinaus haben wir ja auch noch die Testcases, mit denen wir jeden Tag (eigentlich jede Nacht) automatisch sicherstellen, das die Änderungen vom Tag nicht dazu geführt haben, das sich irgendwelche Ergebnisse ändern. (Es sei denn, es handelte sich um eine Korrektur, und sie sollten sich ändern Smiley ). Dazu gehören ein paar tausend Baustatik-Dateien, die natürlich auch im Revision Control System liegen – und alle internen Tools, die damit zusammenarbeiten, mussten ebenfalls angepasst werden.

Die Umstellung sollte nun aber eigentlich vollständig vollzogen sein – es wird zwar sicher noch die ein- oder andere kleine Störung geben, aber im großen und ganzen ist das nun abgeschlossen.

Was ändert sich dadurch für den Anwender? Nichts – außer, das wir nun ein etwas besseres Toolset haben, und damit hoffentlich (noch) schneller an Verbesserungen unserer Software arbeiten können…

Zum Jahresende

Die Feiertage nähern sich rapide und das Jahr hat bald ein Ende… Eine gute Zeit für einen Rückblick auf das vergangene Baustatik-Jahr – und einen Ausblick auf das kommende.

Das ist passiert

Bei der Baustatik hat sich in diesem Jahr eine ganze Menge getan. Die wichtigsten Dinge waren dabei wohl die folgenden:

  • Erhebliche Erweiterungen beim Export nach VCMaster
  • Support für die Datenermittlung (Wind/Schneelasten) von Basis von Postleitzahlen
  • Der Dach-Designer “kann” nun auch Satteldächer
  • Support für den Export der Ausgabe im .docx Format für aktuelle Word-Versionen
  • Windows XP wird nicht länger unterstützt
  • Erhebliche Erweiterungen beim Export nach DXF
  • Die Updates werden nun vollautomatisch verteilt und in den meisten Fällen ohne zutun des Anwenders installiert
  • Platte und Faltwerkselemente können nun auch im Zustand 2 berechnet werden.
  • Es gibt nun eine automatische Lastweiterleitung
  • … und natürlich ist noch vieles mehr passiert. Die gesamte Liste findet sich im Update-Protokoll.

Und natürlich werden wir auch im nächsten Jahr mit Volldampf weiterarbeiten. Die nächsten größeren sichtbaren Spuren werden folgende sein:

  • Erheblicher Ausbau der Lastweiterleitung: Es soll von und nach allen Dokument-Arten weitergeleitet werden, bei denen das Sinn macht.
  • Erheblicher Ausbau der Kommunikation mit Word: Man wird eigene Word-Dokumente und Deckblätter in den Ausdruck mit einfließen lassen können, und auch insgesamt an der Formatierung mit Word besser Hand anlegen können.
  • Integration von bisher fehlenden Dokument-Typen: Zunächst wird es in der Baustatik dabei Ersatz für die Querschnittsprogramme geben.

Nachdem ich ab in Kürze bis vermutlich zum 6.1.2016 nicht mehr im Büro sein werde: Ich wünsche schöne Feiertage, einen guten Rutsch und ein tolles und erfolgreichen 2016 !

So behalten wir unsere Test im Auge

Ich habe ja schon hin- und wieder darüber berichtet, das wir jede Nacht eine 32bit und eine 64bit Version der Baustatik auf Basis des aktuellen Entwicklungsstandes herstellen, und dann mit diesen Programmversionen eine Vielzahl an Dateien komplett durchrechnen – und die Ergebnisse dieser Berechnungen dann mit Referenzdaten vergleichen. Sinn der Sache ist es sicherzustellen, das eine durch die Weiterentwicklung entstandene Veränderung am Programm sich nicht auf die berechneten Ergebnisse auswirkt. Oder wenn, dann eben nur, weil das vom Entwickler auch gewünscht war.

Zur Zeit berechnen wir dabei pro Version ca. 3500 Eingabedateien (also insgesamt 7000). Und pro Datei gibt es dann natürlich noch jede Menge unterschiedlicher Ergebnissarten – und die an jeder Menge Stellen. Also zum Beispiel alle Auflagerkräfte für alle Lastfälle und Überlagerungen, aber eben auch alle Verformungen und Bemessungsergebnisse aller Faltwerkselemente in allen FE-Punkten. Mit einem Wort: Das sind echt viele Zahlen. Viele.

Und so machen wir das…

Zunächst mal haben wir 2 virtuelle Hyper-V Maschinen im Betrieb, beide mit installierter Quellcodeverwaltung und Visual Studio. Auf beiden werden abends Jobs angestoßen, und diese Jobs tun folgendes:

  • Aktuellen Quellcode runterladen
  • Programmversion herstellen (die eine virtuelle Maschine die 32bit Version, die andere die 64bit Version)
  • Aktuelle Testdateien runterladen
  • Für alle Testdateien alle möglichen Ergebnisse berechnen und protokollieren
  • Alle Ergebnisse mit den Referenzergebnissen vergleichen und eventuell aufgetretene Unterschiede protokollieren

Alles was protokolliert wird landet in einer Datenbank (in Azure), und dafür wiederum haben wir eine (interne) Webseite, mit der man sich die Daten ansehen kann. Die liefert zunächst mal eine Übersicht, aus der hervorgeht, welche Version überhaupt gebaut werden konnte, wo Testläufe durchlaufen wurden, und wo Testläufe fehlschlugen:

image

Im Fall eines Fehlschlags kann man auf den Testlauf klicken und bekommt eine Übersicht über diesen Testlauf. In dieser Übersicht sieht man dann auch schon, in welchem Bereich der Fehler lag:

image

Dort kann man dann wiederum auf den Fehler klicken und bekommt alle Details dazu, was genau nicht geklappt hat:

image

Danach kennt man also schon mal die Dokumente, bei denen es ein Problem gab und eine Zusammenfassung des Fehlers. Klickt man nun noch auf die Datei, gibt es auch (zum Teil etwas kryptische) Informationen darüber, welcher Teil der Berechnung genau nicht geklappt hat – und was genau der Fehler war:

image

Wenn man nicht ganz so tief in die Details gehen will, dann gibt es natürlich auch etwas höher angeordnete Statistiken, zum Beispiel wie viele Testläufe durchlaufen wurden, und wie lange das gedauert hat. (Wenn sich hier was ändert, dann ist zwar nichts wirklich falsch – aber langsamer werden soll die Sache natürlich auch nicht):

image

Insbesondere bei der Zeit sind kleinere Unterschiede aber zu erwarten, das bringt schon allein die Verwendung der virtuellen Maschinen mit sich: Wenn der physische Rechner in dem die sich befinden gerade etwas “interessantes” tut – also zum Beispiel ein automatisches Update einspielt – dann verändert sich die Performance der virtuellen Maschine darin – und darum kommt es zu anderen Laufzeiten. Die sollten aber immer nur gering sein – sonst stimmt mit dem Programm etwas nicht.

Und das ist im großen und ganzen die Methode, mit der wir die Übersicht über unsere Test – und das Verhalten der Baustatik – behalten: Viele, viele, viele Daten – in hübsche Graphiken verpackt. Eigentlich genau so, wie die Baustatik selbst Smiley

Blogs nun auch mit SSL

Wir haben die Umstellung unseres Web-Angebotes auf SSL nun abgeschlossen: Das letzte Problem waren unsere Blogs. Die hatten zwar schon SSL, aber es gab ein Restproblem mit der Blog-Software. Bei der erfolgt die Anzeige aller Bilder nämlich über einen Bilder-Handler. Das bedeutet im wesentlichen, das das Bild nicht direkt als Quelle im IMG-Tag angegeben wird, sondern es wird statt dessen der parametrisierte Handler aufgelistet. Und der ist – zumindest in der Version die wir verwenden- fest kodiert, und zwar mit einer HTTP-URL.

Nun habe ich damals beim einrichten der Blog-Webseite den Fehler gemacht das ganze nicht auf dem Quellcode der Blogsoftware beruhen zu lassen (was gegangen wäre), sondern ich habe die Binäre Distribution verwendet. Das war damals einfacher, macht aber heute Änderungen schwieriger. Mit der Quellcode-Variante hätte man das Programm einfach so ändern können, das es eine HTTP-UPR ausgibt, bei der binären Variante geht das aber leider nicht.

Darum produzierte das Blog weiterhin fröhlich Webseiten, die zwar per HTTPS erreichbar waren, aber ihrerseits Referenzen auf HTTP-URLs verwendete. Wegen diese Referenzen wurden die Blog-Beiträge darum von allen Browsern als nicht vollständig sicher eingestuft (zu Recht) – und die Adressleiste enthielt darum auch nicht die “grüne” Farbe bzw. das Schloss-Symbol, mit dem die sichere Verbindung gekennzeichnet wird.

Das ist aber nun geklärt- und auch die Blog-Seiten und Beiträge sind vollständig per SSL erreichbar. (Anders als auf der normalen Webseite www.die.de erzwingen wir aber zur Zeit die sichere Verbindung nicht: Wer will, kann also noch “unsicher” surfen.)

Wer sich für die technische Lösung interessiert: So haben wir es gemacht….

Das wesentliche Problem ist, das das ASP.NET Programm das HTML erzeugt, das dann, wenn alles fertig ist, an den Client geschickt wird. Am eigentlichen Prozess der HTML-Erzeugung konnten wir nichts beeinflussen. Man musste das HTML also verändern, nachdem es von der Blog-Software erzeugt wurde, und unmittelbar bevor es an den Client gesendet wurde.

Das ist aber bei ASP.NET kein Problem: Dazu muss man nur ein IHttpModule  implementieren und in web.config eintragen. Die Implementierung ist in diesem Fall trivial: Im “Init” hängt man einen Eventhandler an das PostRequestHandlerExecute Event. Dort, falls es sich beim “CurrentHandler” um die Page handelt, hängt man an den Response-Filter einen neuen Filter.

Der Filter erbt von Stream und muss die gängigen Methoden überladen, die einzig wichtige ist aber “Write”. Dort hat man den kompletten Puffer mit dem HTML, und kann dort – in diesem Fall – den Text einfach mit string.Replace() ersetzen, und dann das eigentliche Write aufrufen.