cardo4 und 64 Bit
Hintergrund
Der cardo4 Anwendungspool, genau wie auch in cardo3, ist mit der Option "32 Bit Anwendungen zulassen" definiert.
Dies bedeutet, dass die Webanwendungen als 32 Bit Prozess laufen. Von der Ausführungsgeschwindigkeit etc. spielt das auch keine große Rolle (es gibt einige Verbesserungen durch Nutzung von CPU Features die nur in x64 vorhanden sind, aber das dürfte sich nicht spürbar auswirken).
Allerdings ist der Adressraum hier begrenzt, d.h. effektiv kann eine 32 Bit .Net Anwendung nicht mehr als ca. 2 GByte Hauptspeicher konsumieren. Das kann bei einigen Vorgängen, vor allem auch mit Blick auf parallele Anforderungen, ein limitierender Faktor sein (Stichwort "OutOfMemory").
Aus diesem Grund haben wir, beginnend mit cardo4 Version 4.1.5, die Möglichkeit eingeräumt, dies auch als 64 Bit Prozess laufen zu lassen.
Potentielle Probleme 32 Bit/64 Bit
Generell ist der Unterschied zwischen 32/64 Bit Entwicklung kein großes Hexenwerk (zumindest bei .Net, bei systemnahen Dingen, wie Iwan7 oder unsere IduIT.GeoLib.Net in C++, gibt es dort schon mehr zu beachten).
Es gibt allerdings eine grundlegende technisch bedingte Regel, die das in Summe doch etwas verkompliziert:
- ein 32 Bit Prozess kann nur 32 Bit Komponenten laden
- ein 64 Bit Prozess kann nur 64 Bit Komponenten laden
Damit kommt die Lawine der Abhängigkeiten ins Rollen. D.h. alle verwendeten Komponenten müssen dann in 64 Bit (bzw. in .Net als AnyCPU Version) vorliegen.
Und alle sind eben auch solche Dritter. Besonders problematisch sind dabei die Datenzugriffstreiber für Access (Stichwort: user.mdb). Diese gibt es schlichtweg nicht (das stimmt so nicht ganz, aber fast, da keine Koexistenz möglich ist).
Andere Komponenten sind .Net Assemblies, die mit native Code erstellt sind (z.B. Versionen von System.Data.SQLite, HiQPdf oder unser IduIT.GeoLib.Net und GeoLib.Net).
Schon seit langem haben wir alle Komponenten auch in einer 64 Bit Version erstellt. Da wir aber nicht alle durch die Anwender erstellten und verwendeten Komponenten kennen, wollten wir keinen Zwang zu einer 64 Bit Version einführen.
Aus diesem Grund haben wir ab Version 4.1.5 einen Mechanismus bereitgestellt, der das wahlweise Umschalten des Anwendungspools auf 64 Bit zulässt.
Erkennung der Architektur
In cardo4 existiert im Bin Ordner ein Unterordner ARCH, dort dann der Unterordner x86 und x64.
Durch den cardo Updater werden die betroffenen Komponenten, d.h. die nicht architekturneutral sind, im:
- "bin" Ordner als 32 Bit Version,
- in "bin\ARCH\x64" als die dazu gehörende 64 Bit Version
ausgeliefert.
Der Updater verschiebt dann alle Komponenten aus "bin" in "bin\ARCH\x86" zu denen in "bin\ARCH\x64" ein Gegenstück existiert.
Allerdings nur, wenn:
- mindestens ein Anwendungspool für cardo4 mit 64 Bit vorhanden ist
- oder der Unterordner bin\ARCH\x86 nicht leer ist (damit auch beim Zurückschalten in 32 Bit Modus die einmal bereitgestellten Dateien aktuell sind)
Wenn eine plattformspezifische Version eines Assemblies direkt im "bin" Ordner liegt und diese nicht der Architektur des Prozesses entspricht, kommt beim Aufruf der cardo4 Anwendung ein Fehler der Art: Die Datei oder Assembly "XYZ" oder eine Abhängigkeit davon wurde nicht gefunden. Es wurde versucht, eine Datei mit einem falschen Format zu laden.
Aus diesem Grund dürfen die Dateien nicht direkt im Bin Ordner liegen und werden vom Updater verschoben.
In cardo4 ist jetzt ein spezieller Module-Initializer integriert, der die Assemblies dann spezifisch lädt. Das Schema ist recht einfach:
- der Assembly-Name entspricht dem Namen der DLL
- es ist im Ordner ARCH<x64|x86> eine entsprechende DLL vorhanden (x64|x86 wird abhängig vom Prozess bestimmt)
D.h. eigene Komponenten die diesem Schema entsprechen, können auch in diesem Ordner abgelegt werden. Der Updater löscht keine fremden DLLs.
- die Assembly-Dateien (xxx.dll) dürfen sich dabei zwischen den Versionen nicht im Dateinamen unterscheiden.
Das Verschieben der DLL durch den Updater erfolgt dabei, wie oben bereits geschrieben, nur dann, wenn auch ein Anwendungspool mit 64 Bit vorhanden ist. Damit kann auf Entwicklungsrechnern mit der bisherigen 32 Bit Version unverändert weiter hantiert werden.
Checkliste für Entwickler
Wenn Sie planen die 64 Bit Version zu verwenden, dann prüfen Sie bitte folgende Punkte für selbst erstellte Anwendungen:
Für alle Assemblies ist als "Plattform-Target" "AnyCPU" eingestellt (Build Options).
Die Option "Prefer 32Bit" ist deaktiviert (Build Options).
PInvoke-Aufrufe gehen auf System-DLLs oder laden die DLL plattformspezifisch.
Für referenzierte Assemblies sind diese Regeln ebenfalls anzuwenden, handelt es sich um Native-Assemblies, dann können diese in dem ARCH Ordner mit ablegt werden.
Alle verwendete Datenbanken verfügen über x64 Treiber, ggf. sind die Connection-Strings in zwei Versionen bereitzustellen.
Checkliste für Betreuer
Alle Entwickler von Anwendungen haben die "Checkliste für Entwickler" umgesetzt.
Alle verwendeten Datenbanken verfügen über x64 Treiber, ggf. sind die Connection-Strings anzupassen, evtl. sind auch ODBC DSN Einträge vorhanden, die als 64 Bit Version neu erstellt werden müssen.
Etwas ungünstig ist z.Z., dass zu beachten ist, das cardo3 nach wie vor als 32 Bit Prozess läuft, d.h. das Testen der Einstellungen der Datenbankverbindungen kann erfolgreich sein, aber in der 64 Bit cardo4 Umgebung trotzdem fehlschlagen. Evtl. sind auch die Ausführungen zu Iwan7 unter Punktebenen aus Datenbanken / Was tun? hilfreich.
Ausgewählte Einstellungen aus der "user.mdb" (die Tabelle WebProperties) werden aus der "user.sqlite" Datenbank gelesen. Die Einstellungen werden beim cardo Update jeweils neu übernommen.
D.h. nach Änderungen in den Grundeinstellungen (ja, die ganz alten :)) müssen diese Änderungen manuell übernommen werden. Dazu wurde der Dienst diagnostics.asmx um die Methode CreateOrUpdateUserMdbSQliteMirror* erweitert. Der Updater ruft diese Methode im Zuge des SQLUpdates immer mit auf.
Der Zugriff auf folgende Module, die auf die "user.mdb" zugreifen, ist nicht mehr möglich:
Migration der cardo3 Benutzer-Einstellungen (Übernahme von Sketch, gespeicherten Karten etc.)
gKK (dieses Modul ist obsolet und wird mit einer der kommenden Versionen entfernt)
Bedenken Sie, dass nicht alle Probleme unmittelbar beim Systemstart berichtet werden. Tückisch können hier Laufzeitfehler sein, d.h. solche die erst bei der unmittelbaren Verwendung bestimmter Funktionen auftreten. Beobachten Sie die Funktionalität nach der Umstellung entsprechend sorgfältig.
In cardo erkennen Sie die aktivierte 64 Bit Version an einer zusätzlichen Ausschrift im Bereich "Informationen":
Zuletzt geändert: 24.09.2024 17:54:52 (erstmals erstellt 26.12.2020)