Versionshistorie

v1.0.9 — 04.08.2026

🐛 Fixed

• Doppelverarbeitung bei gesperrten Dateien: Konnte eine Datei nach der Verarbeitung nicht nach Erfolgreich/Fehler verschoben werden (z.B. noch im Zugriff durch Scanner/Virenscanner), blieb sie im Quellverzeichnis liegen und wurde beim nächsten Start erneut verarbeitet — beim Split wurden die Einzeldokumente dadurch doppelt importiert. Dateien werden jetzt vor der Verarbeitung in das neue Arbeitsverzeichnis InArbeit (Parameter WorkFolder) verschoben: Scheitert das Verschieben an einer Sperre, ist noch nichts verarbeitet und der nächste Lauf beginnt von vorn. Das gilt für die Split-Vorschaltstufe und den regulären Import.
• Verschieben mit Wiederholung: Alle Verschiebe-Operationen versuchen es bei Dateisperren jetzt bis zu 10-mal im 500-ms-Abstand; ein endgültiges Scheitern wird als Fehler geloggt statt still verschluckt. Beim Dienststart werden in InArbeit zurückgebliebene Dateien (Absturz/Stopp mitten in der Verarbeitung) automatisch zurückgeholt und erneut verarbeitet.
• Demomodus verschiebt konsequent keine Dateien mehr: Bisher wurden Dateien im Demomodus in Fehlerfällen (z.B. Render-Fehler beim Split) trotzdem nach Fehler verschoben — entgegen dem dokumentierten Verhalten.

v1.0.8 — 04.08.2026

🐛 Fixed

• Endlosschleife der Split-Stufe bei fehlgeschlagenen Dateien: Das Verschieben einer Datei nach Fehler/Erfolgreich löste im überwachten Split-Verzeichnis erneut ein Created-Event aus, die Datei wurde sofort wieder verarbeitet und bei jedem Fehlschlag ein weiteres Fehler-Verzeichnis ineinander verschachtelt (Fehler\Fehler\Fehler\…). Watcher und Batch-Scan überspringen jetzt alle Dateien, die auf beliebiger Ebene unterhalb eines Systemverzeichnisses liegen — der Batch-Scan prüfte bisher nur das direkte Elternverzeichnis.
• PDF-Rendern schlug im veröffentlichten Dienst fehl: Im Publish fehlte die DevExpress.Pdf.v26.1.SkiaRenderer.dll, dadurch brach jedes Rendern (Barcode-/OCR-Erkennung der Split-Stufe) mit PdfRenderingOutOfMemoryException („assembly reference is missing") ab. Das für PdfRenderingEngine.Skia erforderliche Paket DevExpress.Pdf.SkiaRenderer wird jetzt referenziert; SkiaSharp dafür auf 3.119.1 gehoben.

v1.0.7 — 04.08.2026

💎 Added

• PDF-Split für Sammel-Dokumente: Gescannte Sammel-PDFs (mehrere Dokumente in einer Datei) werden über die neue Split-Vorschaltstufe automatisch in Einzeldokumente zerlegt und regulär importiert. Trennung konfigurierbar per Barcode/QR (dekodierter Wert = Identifier) oder OCR (PaddleOCR, Regex-basiert). Neues Wurzelverzeichnis Split:SplitPath spiegelt das Import-Layout; Einzeldateien landen unter dem gespiegelten Pfad in ImportPath. Demomodus erkennt und loggt Segmente, schreibt und verschiebt aber nichts.
• Doku-Publishing nach BookStack: Änderungen an der README.md auf master werden über den neuen Workflow documentation.yml automatisch als Buch „MESO Archivimport" nach BookStack veröffentlicht (geteilte Action CSS-EDV-Support/.github/actions/publish-bookstack).

🏗️ Refactoring

• .NET 10: Das Projekt zielt auf net10.0, die Container-Images auf mcr.microsoft.com/dotnet/{sdk,runtime}:10.0. Für die Installation als Windows-Service ändert sich nichts — das Publish-Artefakt ist weiterhin self-contained und braucht keine .NET-Installation auf dem Zielrechner.
• Upgrade auf DevExpress 26.1 und aktuelle MesoXPO-Pakete: MesoXPO-DevEx26.1 2026.4.76, MesoXPO.Business-DevEx26.1 2026.4.76-beta02 und DevExpress.Document.Processor 26.1.3. System.Security.Cryptography.Xml auf 10.0.10 und AutoMapper auf 16.1.1 gehoben (behebt die NU1903-Advisories und passt zur Anforderung der neuen MesoXPO.Business).
• Automatische Paket-Updates: Neue MesoXPO-/MesoXPO.Business-Releases lösen über repository_dispatch einen Update-PR aus (update-dependency.yml); Dependabot-Updates laufen gruppiert in einem Sammel-PR.
• DevExpress-Pakete kommen jetzt von nuget.org statt vom persönlichen Feed nuget.devexpress.com (seit DevExpress v25.1 der empfohlene Weg). Die CI benötigt dafür keine Feed-Credentials mehr; die Lizenzierung erfolgt ausschließlich über die Umgebungsvariable DevExpress_License.
• Thread-sichere Archiv-DB-Registrierung: Beim Aufräumen wird die von InitializeFromSystemUnitOfWork gesetzte Static-Factory gelöscht (SetStaticFactory(null)) statt des veralteten Legacy-Singletons (SetStaticService).

🐛 Fixed

• Archiv-Service-Locator vollständig verdrahtet: Der SystemDatabaseServiceProvider wird jetzt vor InitializeFromSystemUnitOfWork gesetzt. Zuvor delegierte die von MesoXPO registrierte Archiv-Factory an einen nicht gesetzten Provider und lieferte bei jedem Zugriff null — das Archiv funktionierte nur über einen internen Notfall-Fallback und protokollierte pro Zugriff eine Warnung.
• ArchivBusiness wird beim Herunterfahren freigegeben: Die von ArchivBusiness intern erzeugte Archiv-Session blieb bisher offen, weil DatenbankProvider.Dispose das Objekt nicht disposed hat.
• Logger für ArchivBusiness: Ohne explizit übergebenen Logger verwarf die MesoXPO-Business- Schicht alle eigenen Meldungen. Hinweise wie „Kein Archiv-Formular mit der Bezeichnung … gefunden" erscheinen jetzt im Log.
• Ausgelagerte Archiv-Datenbank wieder nutzbar: Bei konfiguriertem EXTERNARCHIVEDATABASE gingen Schlagworte, OCR-Langtexte und Archivjournal-Einträge still verloren, weil MesoXPO die Archiv-Session pro Zugriff neu erzeugte und der Commit dadurch auf einer leeren Session landete. Behoben in MesoXPO.Business 2026.4.73-beta23 (CSS-EDV-Support/MesoXPO.Business#153) und in allen seither eingesetzten Versionen enthalten. Hinweis: ArchivBusiness hält seine Session damit pro Instanz und ist thread-gebunden — der Import nutzt eine gemeinsame Instanz und serialisiert alle Datenbankzugriffe.
• Split-Dateierkennung und OCR-Engine: Die Split-Vorschaltstufe verwendet dieselben Dateifilter wie der reguläre Import (global und je Objekttyp) und prüft vor dem Zugriff, ob die Datei noch existiert — im Watch-Mode kann sie zwischen Ereignis und Verarbeitung verschwinden. Die OCR-Engine wird zudem korrekt im DI-Container registriert; ohne sie startete die Strategie Ocr nicht.
• Linux-Container publiziert wieder: Der Container-Build zieht mit -r linux-x64 die RID-gebundenen nativen Pakete (PaddleOCR/OpenCvSharp) für Linux. Ohne die RID fehlten sie im Image.
• Auslieferung der ZIP-Artefakte wiederhergestellt: Ein Versionsversatz zwischen MesoXPO-DevEx26.1 und MesoXPO.Business-DevEx26.1 ließ den Restore mit NU1605 (Paket-Downgrade) scheitern. Da der Build mit -warnaserror läuft, brach die CI schon vor dem Publish-Schritt ab und es entstand kein neues ZIP mehr.