Plugin-System

Der Kern von Doconut bleibt schlank; optionale Funktionalität wird als Plugins bereitgestellt — separate NuGet‑Pakete, die Viewer oder Dienste beitragen und durch Ihre Lizenz aktiviert werden. Diese Seite erklärt das Registrierungsmodell, wie das Lizenz‑Gating zur Laufzeit funktioniert und wie Sie Ihren eigenen Viewer einbinden.

Dieses Modell ist in dieser Version neu. Die vorherige .NET Standard‑Bibliothek hatte keinen Plugin Register: Konvertierung lebte im Viewer selbst und Plugin‑Lizenzen wurden über statische Viewer.SetLicensePlugin(...)‑Aufrufe installiert. Keines davon ist hier ein Registrierungsmechanismus.

Registrieren eines Plugins

Jedes Plugin‑Paket stellt eine Plugin‑Klasse bereit. Sie registrieren sie einmalig beim Start:

builder.Services.AddDoconut(options =>
{
    options.AddPlugin<Doconut.Plugins.Converter.ConverterPlugin>();
    options.AddPlugin<Doconut.Plugins.Dicom.DicomPlugin>();
});

AddPlugin<TPlugin>() instanziiert das Plugin und ruft dessen Register‑Callback im Plugin‑Register auf, das auf DoconutOptions gehalten wird. Alles, was ein Plugin beiträgt, ist mit der erforderlichen Fähigkeit des Plugins gekennzeichnet. AddDoconut() validiert registrierte Plugins sofort: Eine fehlende Lizenz, eine veraltete TRIAL‑Datei oder eine bezahlte Lizenz ohne die Fähigkeit lässt den Start mit InvalidOperationException fehlschlagen. Eine Temporäre/Demo‑Registrierung bleibt über das Ablaufdatum erhalten, aber ihre Laufzeit‑Fähigkeiten werden nach dem Ablaufdatum widerrufen.

Der Vertrag

Ein Plugin implementiert ein bewusst kleines Interface:

public interface IDoconutPlugin
{
    string Name { get; }                          // z.B. "Doconut DICOM Viewer"
    LicenseCapability RequiredCapability { get; } // das Lizenztor
    void Register(IDoconutPluginBuilder builder); // Beitragen zu Viewern/Diensten
}

Innerhalb von Register akzeptiert der Builder zwei Arten von Beiträgen:

• builder.RegisterViewer(extension, factory) — ein Viewer für eine Dateierweiterung; die Fabrik gibt ein IFormatViewer zurück (das DICOM‑Plugin registriert .dcm und .ima auf diese Weise),
• builder.RegisterService<TContract>(() => …) — ein typisierter Service, den andere Teile der Pipeline nachschlagen können.

Fähigkeiten und Gating

Fähigkeiten sind die Lizenz‑Einheiten. Converter und Dicom werden als opt‑in‑Plugins bereitgestellt; Search und Annotation sind integrierte Funktionen, die auf dieselbe Weise beschränkt werden. Der Basis‑Viewer ist nicht eine Fähigkeit — er ist die Voraussetzung, die als IsViewerLicensed im Lizenz‑Service bereitgestellt wird.

Die Start‑Validierung verhindert normalerweise, dass ein nicht lizenziertes Plugin in die Anforderungspipeline gelangt. Die Viewer‑Fabrik wendet außerdem zwei defensive Laufzeitregeln an, die wichtig sind, wenn sich das Anrecht nach dem Start ändert:

• Plugin überschreibt einen integrierten Viewer (ein Plugin beansprucht eine Erweiterung, die das integrierte Register ebenfalls verarbeitet): Ist die Fähigkeit lizenziert, gewinnt der Plugin‑Viewer; ohne sie fällt Doconut stillschweigend auf den integrierten Viewer zurück. Benutzer sehen ihr Dokument weiterhin — sie erhalten jedoch nicht die Plugin‑Funktion.
• Nur‑Plugin‑Format (z. B. .dcm — DICOM hat keinen integrierten Viewer): Ohne die Fähigkeit schlägt der Öffnungsaufruf hart fehl:

LicenseException: This document type requires the 'Dicom' plugin license.

Eine aktive Temporäre Lizenz gewährt jede Fähigkeit (mit sauberer, nicht wasserzeichen­behafteter Basisansicht). Dies ist eine klassische Quelle für Überraschungen beim Go‑Live: Das Registrieren derselben Plugins mit einer gekauften Lizenz, die eine ihrer Fähigkeiten weglässt, lässt AddDoconut() beim Start fehlschlagen. Vergleichen Sie IsCapabilityGranted(...) mit Ihrem Plan, bevor Sie bereitstellen. Das Gegenstück: Mit keiner Lizenz überhaupt wird nichts gewährt — eine fehlende Lizenz ist keine Temporäre Lizenz.

Das gleiche Gating erscheint clientseitig: Viewer.ReferenceScripts() und ReferenceCss() erzeugen die Skript-/Style‑Bundles für die lizenzgesteuerten Funktionen (Suche, Annotation, …) nur wenn die Lizenz sie aktiviert, sodass die UI des Widgets konsistent bleibt mit dem, was der Server tatsächlich tut.

Funktions‑ und Plugin‑Übersicht

Die Produkt‑UI verwendet „Plugin“ als breiten Funktionsbegriff, aber die Server‑Registrierung unterscheidet sich:

Annotation und die normale Suche verwenden nicht AddPlugin<TPlugin>(); ihre Bundles werden erzeugt nur wenn die Lizenz die entsprechende Fähigkeit gewährt. Converter und DICOM sind die veröffentlichten opt‑in IDoconutPlugin‑Implementierungen für dieses Dokumentationsset.

Die genehmigten .NET Standard‑Artefakte enthalten Doconut.NETStandard.Converter und Doconut.NETStandard.Dicom in derselben Version wie das Kernpaket.

Veröffentliche Plugin‑Pakete

Jedes hat eine eigene Seite unter Plugins mit seiner Konfiguration und Nutzung.

Benutzerdefinierte Viewer — Ihr eigener Format‑Handler

Sie können einen Viewer in die Pipeline einbinden, ohne ein Plugin‑Paket zu schreiben, direkt von Program.cs:

builder.Services.AddDoconut(options =>
{
    options.RegisterViewer(
        ".myext",
        () => new MyCustomViewer(),               // implementiert IFormatViewer
        () => new ImageConfig { ImageResolution = 150 }); // optionale Standardkonfiguration
});

Benutzerdefinierte Viewer haben Vorrang vor allen — integrierten und Plugin‑Viewern gleichermaßen — und sind nicht lizenzgesteuert (sie sind Ihr Code). Die Fabrik greift auf ein ImageConfig zurück, wenn Sie keine Standard‑Konfiguration bereitstellen.

Fazit

• Plugins werden explizit registriert und ihr LicenseCapability wird während AddDoconut() validiert — fehlende oder unzureichende nicht‑temporäre Berechtigung schlägt schnell fehl.
• Override‑Style‑Plugins degradieren elegant; nur‑Plugin‑Formate schlagen mit einem LicenseException fehl.
• Eine aktive Temporäre Lizenz schaltet alles frei; die Produktionslizenz schaltet das frei, was Sie gekauft haben. Überprüfen Sie dies mit IDoconutLicenseService vor dem Ausliefern.