Zufällig drüber gestolpert, wird aber bestimmt auch anderen helfen: Das Deutsche Institut für Bautechnik veröffentlicht eine Excel-Tabelle mit den Schneelastzonen, sortiert nach Verwaltungsgrenzen. Zu haben hier: DIBt

Ich hatte vor kurzem darüber berichtet, das wir von SourceSafe auf Vault umgestiegen sind. Mir war aufgefallen, das ein automatisches Checkout innerhalb von VS2005 doch relativ lange dauerte - beim mir etwa 20 Sekunden.

Laut dem SourceGear Support tritt dieses Problem wohl nur in größeren Solutions bzw. Projekten auf, und das trifft auf die Baustatik wohl zu: Die Solution enthält zur Zeit knapp 70 Projekte und etwa 10.000 Dateien.

Seit heute gibts ein Update für den integrierten Client, und der ist in der Tat dramatisch viel schneller: Statt 20 Sekunden dauert es nun weniger als 1 Sekunden. Prima! Das Update umfasst einen Client-Only Installer und kann zusammen mit einem 4.1.x Server eingesetzt werden. Zu haben ist es zur Zeit hier, aber wer lieber auf etwas "offizielleres" warten soll: In der nächsten Woche soll es das offizielle Release geben.

Update:  Es gibt ein neues Download hier. Darin ist nun auch das hinzufügen von Dateien zu einem Projekt dramatisch viel schneller geworden.

Mir ist noch nicht ganz klar, was eigentlich passiert. Offenbar ist es aber so, das beim installieren des Updates auf Version 1.24 bei verschiedenen Kunden Probleme auftreten: Die Installation endet mit einer Fehlermeldung und scheitert. Das kann man zum Glück aber umgehen: Man muss die aktuell installierte Version einmal manuell über die Systemsteuerung deinstallieren, und erst dann das Update installieren - dann gehts.

Ich untersuche das Problem aber noch: Wenn ich herausgefunden habe woran es liegt, geben ich noch Bescheid.

Update: Ich kann das Problem nun zumindest reproduzieren, habe aber noch nicht die geringste Ahnung, was das verursacht. Der oben beschrieben Work-Around funktioniert aber. Ich nehme nun auf jeden Fall die Downloads erstmal vom Server, bis die Sache geklärt ist.

Update:  Ich vermute, das das Problem mit einer internen Umstellung auf unseren Entwicklungsrechnern zusammenhängt; wirklich erklären kann ich es aber nicht. Es bleibt zur Zeit nichts anderes übrig, als die Vorgängerversionen über die Systemsteuerung manuell zu deinstallieren, und dann erst das Update zu installieren. Bei zukünftigen Updates wird es aber wie gewohnt auch ohne manuelles deinstallieren gehen - das habe ich bereits überprüft.

Manchen ist es ja nicht so wichtig, ob die Dinge, mit denen sie täglich zu tun haben, hübsch anzusehen sind oder nicht. Solche Menschen meckern dann auch gerne rum, das Vista zu viel "Klicki-Bunti" hätte. Mir geht das anders: Ich mags hübsch. Darum gefällt mir auch einiges in Vista deutlich besser als in XP. So sieht zum Beispiel mein Laufwerks-Ordner in der Darstellung "Große Symbole" aus:

Man kann die Bilder für die Laufwerke übrigens stufenlos noch deutlich größer machen - etwa 4 mal so groß, wie hier abgebildet.

Ab sofort gibts im Downloadbereich neue Programme: Es gibt eine neue Version vom Durchlaufträger Xdur  und von der Baustatik. Details dazu gibts wie immer im Blog meines Bruders und im Update-Protokoll im Download-Bereich. Bei der Baustatik hat sich leider nicht ganz so viel getan wie ich gehofft hatte - oder, um es anders auszudrücken: Der Durchstanz-Nachweis ist doch nicht fertig geworden. Ich bin aber zuversichtlich, das das im nächsten Update auf jeden Fall der Fall sein wird.

Es gibt dafür aber ein paar nette neue Kommandos:

• Eines zum wiederholen des letzten Kommandos (kann per "Bearbeiten" oder das Tastenkürzel F4 gestartet werden.)
• Zwei zum "korrigieren" von Geometriedaten, was man meist nach einem Import aus einem Drittprogramm tun muss. Beide befinden sich im Menü "Geometrie-Korrektur im "Bearbeiten" Menü.
• Eines zum löschen von "nicht benutzten" Objekten. (Ebenfalls im "Bearbeiten" Menü.)

Dann kann man nun Daten aus zusätzlichen Quellen importieren: Neben DWG (ging schon länger) kann nun auch ZEIG und ISB-CAD eine Datenquelle sein. Und neben den anderen Änderungen (wie gesagt: Siehe Update-Protokoll) wurde auch die Zeit für die Netzerzeugung bei großen Netzen deutlich verbessert, und zwar wurde sie auf etwa ein Zehntel der ursprünglichen Dauer geschrumpft.

Bei WinRAR handelt es sich um ein Kompressionsprogramm, das auch .ZIP-Dateien lesen und dekomprimieren kann. Wer Windows XP oder eine neuere Version von Windows einsetzt, braucht das Programm eigentlich nicht, da diese Windows-Versionen ZIP-Dateien ohne Hilfe einer weiteren Software behandeln können. In einem solchen Fall kann mann in der baustatik_setup.zip einfach auf das "setup.exe" klicken um die Baustatik zu installieren: Die Dateien werden dann "automatisch" im Hintergrund in einen temporären Ordner entpackt, und die Installation erfolgt dann über diesen Ordner. Das geht problemlos, allerdings kann die Installation dann nicht automatisch "repariert" werden, wenn das zu einem späteren Zeitpunkt mal notwendig werden sollte.

Auf Basis eines Gesprächs mit einem Kunden geht das mit WinRAR offenbar nicht so gut: Zumindest im Fall des Kunden war es so, das die Installation zwar gestartet wurde, aber dann letztlich nicht abgeschlossen werden konnte. Statt dessen wurde das fehlen einer Datei mit dem Name rar(...)\data.msi angemeckert. Unser Installationsprogramm enthält keine Datei mit diesem Pfad. Aufgrund des "rar" im Namen vermute ich aber, das es sich um eine von RAR angelegte temporäre Datei handelt - die aber nicht wirklich angelegt wurde. Darum ging die Installation dann schief. Offenbar muss man, wenn man WinRAR zur Behandlung von .ZIP-Dateien verwendet, die Installationsdatei der Baustatik erst in einen separaten Ordner extrahieren und von dort starten, statt sie direkt aus der ZIP-Datei heraus auszuführen.

Sie stammen nicht aus dem "neuen" Visual Studio 2008 Paket, sondern es gibt sie schon seit .Net 2.0 und dem Visual Studio 2005: Die beiden Generic Delegates "Action" und "Converter". Und obwohl sie nun schon einige Jahre auf dem Buckel haben, habe ich es bis zu dieser Woche geschafft, die beiden vollkommen zu übersehen. Nachdem ich annehme das ich da nicht der einzige bin, ist das Grund genug, beide kurz unter die Lupe zu nehmen.

Das Action Generic Delegate

Die Dokumentation sagt dazu lapidar "Encapsulates a method that takes a single parameter and does not return a value.". Das ist schön. Die Frage ist aber: Wozu soll das gut sein?

Ein ganz typischer Fall ist der, das man eine Sammlung von Objekten hat, und für jedes dieser Objekte einen Vorgang durchführen möchte. Gängigerweise tut man dann folgendes:

foreach( TypeOfObject obj in sammlung)
{
   DoSomethingWithObject( obj );
}

Weil man das so oft braucht, hat List<T> ein eigenes ForEach. Hat man beispielsweise eine List<string>, kann man auch folgendes Konstrukt verwenden:

list.ForEach( DoSomethingWithString );  // (DoSomethingWithString ist eine Methode die einen string als Parameter bekommt.

List<T> verwendet als Parameter den Action-Delegate. Das ganze geht dann auch anonym, also ohne explizit eine DoSomethingWithString( string s) Methode zu implementieren:

list.ForEach( delegate( string s)
{
   Console.WriteLine( s );
});

Nun muss man sich ein etwas umfangreicheres Konstrukt vorstellen: Man hat eine Sammlung an Objekten und muss für alle Objekte mehrere Aufgabe durchführen: Die Aufgaben sind im wesentlichen gleich, unterscheiden sich aber durch einen bestimmten Vorgang. Auch hier hilft das Action-Delegate.

void foo1()
{
   Action<Control> showNameDelegate = delegate(Control c) { MessageBox.Show(c.Name); };
   DoWork(showNameDelegate, this.Controls);
}

void foo2()
{
   Action<Control> showSizeDelegate = delegate(Control c) { MessageBox.Show(c.Size.ToString()); };
   DoWork(showSizeDelegate, this.Controls);
}

private void DoWork(Action<Control> action, System.Windows.Forms.Control.ControlCollection controls)
{
   foreach (Control control in controls)
   {
      // hier wird "allgemeingltige" arbeit mit dem
      // control durchgefhrt.

      // hier wird "allgemeingltige" arbeit mit dem
     // control durchgefhrt.
   }
}

Man kann dadurch also die "allgemeingültige" Arbeit mit einer Methode versorgen, die die unterschiedlichen Aspekte übernimmt.

Das Converter Generic Delegate

Hier geht es um folgendes: Das Delegate bekommt ein Objekt von einem Typ und liefert eines von einem anderen Typ. Angenommen man hat eine Methode zum anzeigen einer Form, die, bevor sie die Form anzeigt, viele aufwendige Dinge mit der Form tut. (Im Beispiel ist das nur das Verändern des FormBorderStyle, aber die Sache kann ja auch aufwendiger werden.)

Nun will man aber im einen Fall die Form Modal anzeigen, im anderen nicht. Wird Sie modal angezeigt, muss das DialogResult geliefert werden: Die Form wird also effektiv in ein DialogResult "umgewandelt". Im nicht-modalen Fall passiert das auch, nur ist das DialogResult dann "None".

Mit dem Converter Delegate ist das kein Problem:

Creepy Girl. (Laden dauert ein bisschen).

Ich arbeite nun seit einigen Tagen mit Vault, dem RCS von SourceGear. Soweit lief das alles ganz gut (bis auf ein Installationsproblem bei einem Entwickler) - und ich bin mit der Performance des Programms mehr als zufrieden. Es gibt allerdings eine Stelle die mich stört: Ein automatisches Checkout in der VS 2005 IDE dauert doch recht lange. Allerdings ist der Support von SourceGear sehr flott und kompetent - und hat mir kurzerhand mitgeteilt, das sie dieses Problem bei "großen" Solutions gehen: Nächste Woche gibts dafür ein Update.

Bin gespannt.

Wer sich auch die Frage gestellt hat: Ja - man kann es parallel zu VS 2005 installieren.

Nicht so schön: Wenn man LINQ verwenden will, dann muss man auch das .NET Framework 3.5 verwenden. Das hätte mich nicht weiter gestört (auch wenn das Redistributable dafür ganz schön umfangreich ist) - aber die 3.5 läuft nicht mehr wie die 2.0 auf "älteren" Windows-Versionen: Nur XP, 2003 und spätere werden unterstützt.

Mit ein bisschen Glück wird es noch für die nächste Version fertig (wenn nicht, dann in der übernächsten): Der direkt ins Faltwerk eingebaute Durchstanznachweis.

Anders als bei Xpla gibt es denn dann nicht nur für Einzelstützen, sondern auch für Streckenlager.

Jetzt auch mit Details: Hier

Schon seit der ersten Veröffentlichung der Baustatik ist die komplette Dokumentation online verfügbar. Bisher war es so, das ich jedesmal wenn es eine neue Programmversion gab, auch die Dokumentation auf www.die.de aktualisiert habe.

Zumindest dann, wenn ich es nicht vergessen hatte :-)

Ab sofort ist das anders: Die Dokumentation wird nun jeden Tag automatisch aus dem Revision Control System abgeholt und auf www.die.de platziert - die online verfügbare Dokumentation ist damit aktueller als die, die wir ausliefern.

Das Seminar in Hamburg war sehr angenehm: Dazu trug meiner Ansicht nach auch unter anderem die Tatsache bei, das wir nicht wie bei den Vorgängern mit knapp 100 Personen im Raum waren, sondern eine übersichtliche Menge von etwa 30 Personen waren: Das führte dann auch während der Vorträge zu mehr Interaktion.

Die nächste Veranstaltung findet am 4.7. in Erfurt statt. Zur Zeit gibts dafür aber noch keinen Anmeldebogen - sobald es einen gibt, gebe ich an dieser Stelle natürlich Bescheid.

Ab sofort zu haben: Ein Update für das Programm zur Stützenbemessung Xksn. Details zum Update wie immer im Update-Protokoll und im Blog meines Bruders.

Heute so bei uns aufgetreten:

Ein Rechner im Netzwerk kann nicht mehr auf unseren Mailserver zugreifen. Das ist auch kein Wunder, denn ein Ping auf mail.die.de liefert: 91.156.237.80 - sollte aber 80.237.156.91 liefern. Es sieht also so aus, als würde der DNS-Server (der vermutlich einen Cache hat) im Router einen PTR Record als A-Record gespeichert haben. Für andere Domains klappen DNS-Anfragen aber wunderbar.

Interessanterweise trat das außerdem nur auf einem Rechner im LAN auf - die anderen bekamen die richtige Adresse. Was ich dann überhaupt nicht mehr verstand: Der Fehler überlebte sogar ein ipconfig /flushdns - und trat danach auch auf den anderen Rechner NICHT auf.

Bisherige Lösung: Einmal den Router neu gestartet - danach ging es wieder. Bin gespannt, ob das morgen wieder auftritt.

Der Windows Installer ist eine Systemkomponente, die für das installieren von Software gedacht ist. Vermutlich jeder hat schonmal eine Datei mit der Erweiterung .msi gesehen - das sind die Dateien die (u.a.) vom Installer installiert werden. Im Normalfall gibt es zur .msi - Datei auch noch eine "setup.exe": Die braucht man aber nicht unbedingt, denn man kann die MSI-Datei auch "von Hand" installieren. Und besonders wenn bei der Installation ein "unerwarteter" Fehler eintritt muss man das auch.

In einem solchen Fall hilft die Fehlermeldung meist nicht weiter: Alles was man weiss ist, das es einen Fehler gibt - man kennt den genauen Grund aber nicht. Da kommt man aber dran, und zwar, indem man den Installer dazu bringt, ein ausführliches Protokoll des Installationsvorganges anzulegen. Mit diesem Protokoll kann man dann die eigentliche Ursache für den Fehler aufspüren. Um das Protokoll anzulegen geht man wie folgt vor:

- .msi-Datei in einem temporären Ordner (z.b.: c:\temp ) kopieren
- Eingabeaufforderung öffnen und in diesen Ordner wechseln
- Folgende Kommandozeile eingeben: msiexec /i NameDerMsiDatei.msi /L*v PfadZuEinemLogfile

Dabei steht NameDerMsiDatei natürlich für die Msi-Datei (also zum Beispiel data.msi) und PfadZuEinemLofile für den Namen der Protokoll-Datei, also zum Beispiel c:\temp\logfile.txt.

Wie viele Eiffel-Türme gibt es in Paris? - Ungefähr zehn.

Jetzt zu haben.   

Als Revision Control System haben wir in den letzten Jahren Source Safe eingesetzt. Nun ist mir bewusst, das Source Safe keinen besonders guten Ruf hat - ich kann aber wirklich nicht sagen, das wir damit irgend ein Problem gehabt hätten. (Bei der Umstellung tauchte dann zum ersten mal eines auf - aber zuvor hat die Sache für uns eigentlich recht gut funktioniert.)

Das Setup sah dabei bisher so aus, das die Oberhausener und die Münchner Niederlassung per VPN verbunden waren: Dazwischen gab es (unter anderem) eine 2MBit Standleitung, durch die die Oberhausener "durch" mussten, denn die Daten selbst waren auf einem Server in München. Das sollte anders werden, damit auch bessere Geschwindkeiten als 2MBit erzielt werden können. Ziel: Das RCS sollte auf einen Server im Internet, der mindestens mit 100 MBit erreichbar ist.

Da fing das Problem an: Bei Source Safe gibt es zwar die Möglichkeit auf die Daten per HTTP zuzugreifen - allerdings nur in sehr eingeschränktem Umfang: So kann man per HTTP beispielsweise keine Dateien löschen. Es musste also ein anderes RCS her. Ich habe mir verschiedene angesehen (und ja: Ich weiss auch das es Subversion gibt) und mich letztlich für Vault von SourceGear entschieden.

Ein RCS-Wechsel ist eine heikle Sache: Da drin befindet sich schließlich die Arbeit der letzten Jahre und zwar mit allen Änderungen: Diese Daten will man nicht verlieren. Um eines vorweg zu nehmen: Das hat mit Vault auch im großen und ganzen geklappt.

Der Wechsel zu Vault

Um den Wechsel durchführen zu können, müssen die Daten in Source Safe zunächst einmal so sauber wie möglich vorliegen: Das heist, man wirft zunächst das Analyse Tool von Source Safe an, und behandelt alle auftretenden Probleme. Im meinem Fall hat das Tool in den letzten Jahren noch nie einen Fehler gefunden, und so hatte ich auch nicht gerade jetzt damit gerechnet. Es gab aber einen, und der wurde auch nicht vom durch analyze vorgeschlagenen Vorgehen beseitigt: Eine Datei wollte einfach nicht mehr repariert werden können. Folgende Fehlermeldung trat auf:

There is a diff chain size mismatch in file 'overview.xml' (tugbaaaa) at version 7 (versions earlier than that version can no longer be retrieved from the database).

Sollte sonst mal wer über dieses Problem stolpern: Man kann es mit dem ssarc Tool beseitigen. Dieser KB-Artikel erklärt wie das geht.

Danach fand ich aber noch ein anderes Problem: Es gab Dateien die ausgecheckt waren - die aber schon seit Jahren nicht mehr Teil des Projektes waren. Es gab sie also eigentlich nicht mehr, Source Safe dachte aber, sie seien nur ausgecheckt. Ärgerlich. (Das wird in Zukunft nicht mehr passieren, da unser neuer automatischer Build-Server sowas finden und "bemängeln" wird.)

So ein Problem kann man aber auch mit einem Kommandozeilen-Tool von SourceSafe beseitigen: Man führt für die betroffenen Dateien ein Undo-Checkout unter dem SS-Account desjenigen aus, von dem SourceSafe glaubt, er oder sie hätte die Datei ausgecheckt.

Die Installation von Vault ist an sich kein besonderes Problem: Alles was man vorher braucht ist ein SQL Server (die Express-Variante tut es auch) und ein laufender IIS mit ASP.Net.

Dann kommt der spannende Teil: Das Importieren der Daten. Von SourceGear gibt es dazu ein VSSImport-Tool. Das muss auf dem Rechner installiert werden, der zuvor der SS Server war. Dann zeigt man dem Tool den Pfad auf die ss.ini und gibt noch an, wo der neue Vault Server installiert wurde.

Das Import-Tool durchläuft dann zwei Phasen: Eine "Pre-Scan" Phase sowie die eigentliche Konvertierung. Die Pre-Scan Phase ist relativ schnell durchlaufen - und wenn sie das ist, gibt es eine erste Angabe, wie lange denn der Import dauern würde: In Fall unseres "größten" Projektes (mit etwa 10.000 Files) schätzte das Import-Werkzeug den Zeitaufwand auf 22 Stunden. So lange hats dann nicht gedauert - aber 12 Stunden waren es locker. Wer nicht nur alle Änderungen sondern auch "Labels" importieren will muss sich in Geduld üben: Bei einem Projekt dessen Import nur ca. 10 Minuten gedauert hat, habe ich den "Label-Import" mal ausprobiert, aber nach etwa 5 Stunden abgebrochen. Beim großen Projekt habe ich es dann gar nicht erst versucht.

Ist die Sache importiert zeigt das Tool (möglicherweise: bei mir in einem von 3 Fällen) eine Liste an Fehlermeldungen an: Unter Umständen konnten einige Dateien nicht hochgeladen werden, oder es gab vielleicht andere Probleme: Die untersucht man besser von Hand und beseitigt sie. Danach hat man eine "funktionierende" Datenbank - man kann also ein "Get Latest" in ein frisches Verzeichnis machen, und ein Build starten.

Abgesehen von ein paar Dingen die ich für Anfangs/Umstiegsschwierigkeiten halte bin ich von Vault bisher rundrum begeistert: Ein "GetLatest" ist dramatisch viel schneller als bei SourceSafe und die Daten liegen obendrein im SQL Server vor - das macht auch das sichern deutlich einfacher.

Wer es selbst mal ausprobieren will: Die Single-User Version von Vault ist kostenlos.