feat(sdk): Plugins AOT- und Trimming-kompatibel machen

[kirkone]

Übersicht

Plugins AOT- und Trimming-kompatibel machen, damit sie in Zukunft in einem potenziellen AOT-Build verwendbar sind. Unabhängig davon verbessert Trimming-Kompatibilität die Code-Qualität und eliminiert versteckte Reflection-Abhängigkeiten.

Hinweis: Dies betrifft die Plugin-DLLs selbst, nicht den Plugin-Loader (der bleibt Reflection-basiert, siehe #40).

Aktueller Stand

Komponente	AOT/Trim-Status	Blocker
LoggerMessage	✅ Source Generator	Kein Reflection
IConfiguration.Bind()	❌ Reflection	→ #38 löst das
System.Text.Json	⚠️ Hat Source Gen Mode	Noch nicht aktiviert
Scriban	⚠️ v7 hat AOT-Annotationen	Runtime Template Compilation
NetVips	⚠️ P/Invoke	Prinzipiell AOT-fähig
SSH.NET	⚠️ Pure .NET	Viel internes Reflection, unklar
Plugin-Loader	❌ Assembly.LoadFrom()	→ Eigenes Thema (#40)

Was "Plugin ist trimmbar" bedeutet

Ein Plugin ist trimmbar wenn der Trimmer alle nicht erreichbaren Typen sicher entfernen kann, ohne dass zur Laufzeit Fehler auftreten. Dafür muss das Plugin:

1. Kein Reflection für eigene Typen nutzen — kein Type.GetType(), kein Activator.CreateInstance()
2. [DynamicallyAccessedMembers] Annotationen an den richtigen Stellen haben
3. Source-Generated Config statt Reflection-basiertem IConfiguration.Bind() nutzen (→ feat(sdk): Source Generator für automatische Config-Registrierung #38)
4. Trimming-Warnings frei sein (<IsTrimmable>true</IsTrimmable>)

Schritte

Phase 1: Grundlagen (nach #38)

• <IsTrimmable>true</IsTrimmable> auf Sdk-Projekt setzen
• Trimming-Warnings in allen Plugin-Projekten aktivieren (<EnableTrimAnalyzer>true</EnableTrimAnalyzer>)
• Warnings analysieren und fixen
• [DynamicallyAccessedMembers] Annotationen wo nötig

Phase 2: Dependencies prüfen

• Scriban v7 AOT-Annotationen evaluieren — funktioniert Template-Rendering ohne Reflection?
• NetVips P/Invoke — AOT-Kompatibilität verifizieren
• SSH.NET — Trimming-Kompatibilität testen
• System.Text.Json Source Generation aktivieren wo wir JSON serialisieren

Phase 3: CI-Integration

• Trimming-Warnings als Errors in CI (zumindest für eigene Projekte)
• Eventuell Trimming-Test: dotnet publish -p:PublishTrimmed=true als CI-Step

Abhängigkeiten

• feat(sdk): Source Generator für automatische Config-Registrierung #38 (Source Generator für Config) muss zuerst fertig sein — eliminiert den größten Reflection-Blocker in Plugins
• feat(cli): Embedded AOT Build — statisch gelinkte Executable ohne Runtime-Plugin-Loading #40 (Embedded AOT Build) ist das Langzeit-Ziel, für das trimmbare Plugins eine Voraussetzung sind

Abgrenzung

• Der Plugin-Loader (Assembly.LoadFrom(), Reflection Discovery) ist NICHT Teil dieses Issues — der bleibt dynamisch
• AOT-Publishing des gesamten CLI ist NICHT das Ziel hier — nur die Plugins selbst sollen trim-safe sein
• Externe Plugin-Autoren profitieren automatisch wenn das Sdk trim-annotiert ist

[kirkone]

Phase 1 completed in 38b15c3

Trimming Analyzers

• IsTrimmable=true + EnableTrimAnalyzer=true on Sdk and all Plugin projects
• Core/Features/Commands/Cli excluded — intentional reflection use for plugin loading
• Generated config registration: #pragma disable IL2026 (BindConfiguration uses reflection)

JSON Source Generation (4 contexts)

Sdk:

• ThemeJsonContext for ThemeJsonConfig deserialization in embedded theme loading

Statistics Plugin:

• StatisticsJsonContext for SiteStatistics serialization with snake_case naming

Calendar Plugin:

• CalendarJsonContext for CalendarData serialization

OneDrive Plugin:

• OneDriveJsonContext for Badger API request/response types
• Replaced anonymous type new { appId = ... } with named BadgerTokenRequest
• Replaced ReadFromJsonAsync<JsonDocument> with JsonDocument.ParseAsync (trim-safe)

Result

0 IL trimming warnings across Sdk + all 6 Plugins.

Plugins without JSON serialization (Compress, Serve, Source.Calendar) were already clean.