Abhängigkeiten

Plattform

• net10.0 in allen Projekten, ImplicitUsings und Nullable aktiv.
• Azure Functions v4, Isolated Worker, OutputType=Exe.
• Tests auf xUnit v3 mit Microsoft Testing Platform. Aufruf mit dotnet test --project …; das Positionsargument funktioniert nicht mehr.

Projekte

flowchart LR
    HOST["DataBridge (Host)"] --> CORE["DataBridge.Core"]
    DLM["DeadLetterMover"] --> CORE
    TEST["DataBridge.Test"] --> CORE
    TEST --> HOST

NuGet-Pakete

Die Versionen werden zentral in src/Directory.Packages.props gepflegt (Central Package Management); die .csproj-Dateien referenzieren Pakete nur noch ohne Version. Ein Update passiert also an genau einer Stelle.

Sicherheitsprüfung beim Build: Directory.Packages.props aktiviert NuGet Audit für alle Projekte, inklusive transitiver Pakete, und meldet Treffer jeder Schwere. Ab „moderate“ (NU1902–NU1904) gelten sie als Fehler, „low“ (NU1901) bleibt eine Warnung — solche Lücken betreffen oft Funktionen, die gar nicht genutzt werden, und sollen kein Release blockieren. Ein Paket mit einer Sicherheitslücke ab „moderate“ lässt damit Restore und Build lokal, im Dockerfile und in der Pipeline scheitern. Abhilfe ist ein Update der betroffenen Version; liegt die Lücke in einem transitiven Paket, dieses mit eigener Version in Directory.Packages.props aufnehmen. Weil neue Advisories jederzeit erscheinen, kann ein bisher grüner Stand ohne Code-Änderung rot werden. Ist der Advisory-Feed nicht erreichbar, bleibt es bei der Warnung NU1900, offline bauen funktioniert also weiter.

Hier nur die Rolle der wichtigsten Pakete:

Alle DB-Treiber werden immer mitgeladen, auch wenn nur ein Teil genutzt wird.

Azure-Dienste

Externe Systeme

Architekturkritische Kopplungen