Versionshistorie

v1.1.1 — 15.09.2026

🏗️ Refactoring

Ordner-Kern als Bibliothek Meso.Dokument.Eingang: Verschieben mit Sperr-Retry und Zeitstempel, die Systemordner-Konvention (InArbeit/Erfolgreich/Fehler) und die Rückholung liegengebliebener InArbeit-Dateien liegen jetzt im NuGet-Paket Meso.Dokument.Eingang (privater GitHub-Feed, eigenes Repo mit Testsuite), das auch die Eingangsquelle „Scan-Ordner" des MESO WebArchiv nutzt. Der Importer reicht nur noch die Schlagwortdatei als Begleitdatei herein. Verhalten, Retry-Werte, Zeitstempelformat und Verzeichnislogik sind unverändert. Die Rückholung aus InArbeit überspringt jetzt unzugängliche Unterordner statt beim Start abzubrechen, holt Dateien auch aus Unterordnern von InArbeit an die gespiegelte Stelle zurück und hält bei Namenskollisionen das Paar PDF/Schlagwortdatei zusammen.
Konfigurationsprüfung beim Start: WorkFolder, SuccessFolder und ErrorFolder müssen gesetzt, frei von Pfadtrennzeichen und paarweise verschieden sein — bisher fiel ein Tippfehler erst im Betrieb auf. Bestandskonfigurationen, die zwei dieser Ordner gleich benennen (z.B. SuccessFolder = ErrorFolder), starten nicht mehr — die Namen müssen vor dem Update getrennt werden.
Logtexte beim Zurückholen angepasst: Die Bibliothek protokolliert „Begleitdatei verschoben nach" statt „Schlagwortdatei verschoben nach"; der separate Fehlerlog „Fehler beim Verschieben der Schlagwortdatei" heißt jetzt „Fehler beim Verschieben der Begleitdatei". Die Zeilen zum Verschieben und zum Sperr-Retry laufen jetzt unter der Logging-Kategorie Meso.Dokument.Eingang.DateiVerschieber statt MesoArchivImport.Services.DateiVerarbeitungService — ein MinimumLevel:Override auf MesoArchivImport erfasst sie nicht mehr.

v1.1.0 — 13.09.2026

💎 Added

Bild-Vorverarbeitung für die Barcode-Erkennung (#99): Gerasterte Balken realer 200-dpi-Scans wurden von ZXing gar nicht gelesen — die ganze Sammel-PDF landete im Fehler-Ordner. Die Erkennung läuft jetzt zweistufig (Rohbild, dann Graustufen → Gauß-Weichzeichner → Schwellwert); Parameter unter Split:Barcode:Vorverarbeitung, Vorgaben aus der Messung an realen Scans. Split:Barcode:RenderDpi steht standardmäßig auf 300 statt 200. Die Laufzeit der Erkennung wird je Datei protokolliert.
Identifier-Muster für Barcodes (Split:Barcode:IdentifierRegex): Ein dekodierter Wert, der keine plausible Belegnummer sein kann, wird verworfen und protokolliert statt ein eigenes Dokument aufzumachen.

🐛 Fixed

Fehlerkennungen durch offene Symbologie-Liste (#98): Split:Barcode:Symbologien = [] ließ ZXing alle Formate probieren; Tabellenlinien und Rasterflächen wurden als ITF/Code-25-Barcodes gelesen und öffneten still Dokumente mit erfundenen Belegnummern, die anschließend an fremde Belege verknüpft wurden. Leer bedeutet jetzt die Standardauswahl ohne prüfsummenfreie 1D-Formate; beim Start warnt der Dienst und empfiehlt, die Symbologie explizit zu setzen. TryHarder bleibt auch mit eingegrenzten Formaten aktiv.
Ausgelieferte appsettings.json auf die neuen Barcode-Vorgaben gebracht (RenderDpi 300, konkrete Symbologie, Vorverarbeitung) – die Datei pinnte noch 200 dpi und hätte die Vorverarbeitung für Neuinstallationen unterlaufen.

🏗️ Refactoring

Split-Kern als Bibliothek Meso.Dokument.Split (#97): Segmentierung, Dateinamen, Identifier-Regeln sowie Barcode- und OCR-Regex-Strategie liegen jetzt im NuGet-Paket Meso.Dokument.Split (privater GitHub-Feed, eigenes Repo mit Testsuite), das auch das MESO WebArchiv nutzen wird. Der Importer liefert Rendering (DevExpress), OCR (PaddleOCR) und Seitenextraktion über die Schnittstellen ISeitenBildQuelle/ISeitenTextQuelle; die Seiten werden dabei lazy je Seite gerendert statt als PNG-Liste im Speicher gehalten. Die Trennstrategie wird je Split-Lauf aus der aktuellen Konfiguration erzeugt, der Hot-Reload bleibt erhalten. Verhalten und Verzeichnislogik sind unverändert.
PdfSeitenBildQuelle gibt das PDF-Handle bei fehlgeschlagenem Öffnen wieder frei: Schlägt LoadDocument fehl (z.B. defekte oder verschlüsselte PDF), wird der PdfDocumentProcessor jetzt sofort disposed, statt das Handle offenzuhalten – sonst hätte der anschließende Verschiebe-Versuch nach Fehler an der noch offenen Datei scheitern können.

v1.0.10 — 12.09.2026

🏗️ Refactoring

Beleg-Verknüpfung über die MesoXPO-Geschäftslogik: Die eigene Kopie der Verknüpfungslogik (Dokumenten-Id am Beleg setzen, Verweis-Id am Archiveintrag nachziehen) wurde durch BelegBusiness.VerknuepfeArchivdokumentMitBeleg ersetzt — dieselbe Methode, die auch das WebArchiv nutzt. Damit gelten zusätzlich die Vorabprüfung, dass das Archivdokument im Mandanten existiert, ein Nachlauf gegen parallele Erstverknüpfungen und Idempotenz bei bereits verknüpften Belegen. Das nach außen sichtbare Verhalten (Belegkey-Erkennung, Fehler-Verzeichnis bei fehlendem Beleg) bleibt unverändert. MesoXPO.Business-DevEx26.1 dafür auf 2026.4.79-beta45 gehoben.
Klare Meldung statt Stacktrace bei Verknüpfungsfehlern: Fehlender Beleg und fehlendes Archivdokument werden gezielt abgefangen (BelegNichtGefundenException, ArchivDokumentNichtVorhandenExpception) und als einzeilige Fehlermeldung mit Belegreferenz bzw. Dokumenten-Id protokolliert. Beides sind Datenzustände, keine Programmfehler — der Stacktrace trug nichts bei, und die Archivdokument-Ausnahme brachte gar keine eigene Meldung mit. Das Verhalten (Datei wandert nach Fehler) bleibt gleich.
ArchivRepository ohne ungenutzten Logger: Die Klasse hat nie über ihren injizierten Logger geschrieben — der Konstruktorparameter ist entfallen.

🐛 Fixed

Datei bleibt bei fehlgeschlagener Verknüpfung nicht mehr in Erfolgreich liegen: Die Verknüpfung läuft jetzt vor dem Verschieben. Vorher war die Datei bereits nach Erfolgreich verschoben, wenn die Verknüpfung fehlschlug; der Fehlerpfad versuchte sie dann vom nicht mehr existierenden Pfad im Arbeitsverzeichnis nach Fehler zu verschieben und scheiterte — die archivierte, aber unverknüpfte Datei blieb unbemerkt in Erfolgreich.
Keine zusätzliche Archiv-Session mehr: BelegBusiness bekommt jetzt auch den IArchivDatabaseService mit. Dessen Vorabprüfung „Archivdokument im Mandanten vorhanden" greift nicht auf ArchivBusiness zu, sondern auf die interne Archiv-Session — bei ausgelagerter Archiv-DB öffnete der Dienst dadurch eine weitere Verbindung und hielt sie bis zum Beenden offen.
Ergebnis der Verknüpfung wird wieder protokolliert: Dokumenten-Id, ob die Beleggruppe schon bestand und ob eine Kollision aufgelöst wurde, stehen jetzt in der Importzeile der Datei statt nur im Log-Kontext der Bibliothek. Der Beleg in der gecachten Mandanten-UnitOfWork wird zudem nachgeladen, weil die Geschäftslogik die Dokumenten-Id über eine eigene UnitOfWork schreibt.

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.