.NET und PDF Software

Bezüglich der Verarbeitung von Komma-Werten habe ich heute wieder einge Erkenntnisse gewonnen, die teilweise auch aus der verbesserten Dokumentation vom Microsoft.NET Framework 4 her rührten. Dort ist unter anderem zum Typ Double folgendes zu lesen:

Bei Verwendung einer Gleitkommazahl könnte ein Wert möglicherweise nicht wiederhergestellt werden.

Das Problem verdeutlicht folgendes gekürztes Beispiel aus der MSDN:

double fromLiteral = -4.42330604244772E-305;
double fromParse = Double.Parse("-4.42330604244772E-305");
 
Console.WriteLine("Double value from literal: {0,29:R}", fromLiteral);
Console.WriteLine("Double value from Parse method: {0,24:R}", fromParse);
 
// On 32-bit versions of the .NET Framework, the output is:
//    Double value from literal:        -4.42330604244772E-305
//    Double value from Parse method:   -4.42330604244772E-305
//
// On other versions of the .NET Framework, the output is:
//    Double value from literal:      -4.4233060424477198E-305
//    Double value from Parse method:   -4.42330604244772E-305

Das die hinteren Stellen einer Double-Zahl Ungenauigkeiten unterliegen, war mir schon länger klar. Das der selbe Code auf verschiedenen Systemen aber andere Genauigkeiten erzielen kann, war eine neue Erkenntnis, die bis dato nur als ungeäußerte und nicht beweisbare Vermutung im Raum stand.

Um das Problem zu umgehen, habe ich zwei Extensions für mich geschrieben:

public static bool NearZero(this double value)
{
    return Math.Abs(value) < 1e-12;
}
public static bool NearValue(this double value, double compareValue)
{
    if (value.NearZero() && compareValue.NearZero()) return true;
 
    return Math.Abs(value - compareValue) < 
        Math.Min(Math.Abs(value), Math.Abs(compareValue)) * 1e-12;
}

Mit der ersten prüfe ich auf 12 Stellen hinter dem Komma, ob die Zahl fast Null ist. Mit der zweiten Methode kann ich simple 2 Werte auf annähernde Gleichheit überprüfen.

Mittels des Attributes SerializableAttribute ist es sehr einfach, komplexe Objekte auf Festplatte zu speichern und später erneut zu laden. Allerdings gibt es einige Fallen, die man dabei kennen sollte:

1. Kommerzielle .NET-Anwendungen werden gern durch Codeverschlüsselung geschützt. Das bereitet natürlich Probleme, wenn solche Objekte auf Festplatte gespeichert werden. Eine spätere Verschlüsselung hat evtl. den Namen der Properties wieder geändert. Abhilfe kann hier das ObfuscationAttribute verschaffen. Damit kann man einzelne Code-Teile von der Verschlüsselung ausschließen. Damit ist der Code zwar nicht mehr vor fremden Blicken geschützt, aber das Laden/Speichern von Klassen klappt dann auch Versionsübergreifend.

2. Refaktorierung von Klassen: Klassen, die serialisiert werden, dürfen auf keinen Fall umbenannt werden. Gleiches gilt natürlich für deren Properties und Unterklassen.

Leider hat der Hersteller von VistaDB den Vertrieb dieser Datenbank eingestellt. Als kleinen Trost konnte man zum Abschluss noch den Sourcecode sehr günstig erwerben und mit diesem auch eine unverschlüsselte Version ohne Lizenzabfragen herunterladen.

Im Folgenden möchte ich den somit letzten Umstieg von VistaDB.Net 3 auf 4.1, die bei mir noch in einigen Projekten aktiv ist, zeigen:

1. Installation von VistaDB.Net 4.1. Diese Version 4.1 ließ sich problemlos parallel zur Version 3 installieren und nutzen.

2. Upgraden der Datenbank auf die 4er Version. Das geht im VistaDB Data Builder im Menü Database unter dem Punkt Upgrade VDB3 Database sehr einfach. Leider ändert sich die Dateiendung von .vdb3 auf .vdb4. Setup-Skripte müssen hier evtl. auch angepasst werden.

3. Öffnen der Projekte in Microsoft Visual Studio. In den Projekten ist ein Verweis auf VistaDB.NET20 vorhanden. Dieser wird entfernt und durch den VistaDB 4 Provider ersetzt.

4. Die Datasets (.xsd) müssen in einem externen Editor geöffnet werden, um den XML-Code direkt zu bearbeiten. Man findet darin mindestens einmal Provider=“VistaDB.NET20″, was durch Provider=“System.Data.VistaDB“ ersetzt werden muss.

5. Jetzt kommt der schwierigste Teil. Die Connectionstrings müssen aktualisiert werden und die Datasets nochmal neu geschrieben werden. Dazu reicht es eigentlich, den Connectionsstring in den Einstellungen auf die neue Datei (die Dateiendung hat sich ja geändert) zu setzen und einen TableAdapter im Dataset neu zu konfigurieren (ohne Änderung). Jedoch war bei mir das Problem, dass die ConnectionsStrings nicht mehr gültig waren. Das ist zwar ein Problem von Visual Studio und nicht von VistaDB, es steht hier aber trotzdem im Weg. Darum gehe ich einen anderen Weg. Darum habe ich einen anderen Weg gewählt.

Ich habe mir den Namen des Connectionstrings notiert und ihn aus den Einstellungen gelöscht. Dann habe ich ein neues Dataset erzeugt und dort den Connectionstring neu eingegeben und unter dem alten Namen gespeichert. Damit wurde dann als Dummy ein Tableadapter konfiguriert. Das Dataset kann zum Schluss wieder gelöscht werden. Nun können die alten Datasets geöffnet und ein Tableadater neu erzeugt werden.