Die richtige Doconut SDK auswählen: .NET Standard 2.1, .NET 6 oder .NET 8
Beginnen Sie mit dem Anwendungshost
Die Auswahl eines Doconut-Pakets beginnt mit dem Projekt, das es ausführt. Eine neue .NET 8-Webanwendung, ein etabliertes .NET 6‑Service und ein bibliothekskompatibler ASP.NET‑Core‑Host können alle eingebettete Dokumentenansicht benötigen, aber ihre Framework‑Beschränkungen und Upgrade‑Pläne unterscheiden sich.
Doconut bietet aktuelle SDK-Pfade für .NET 8, .NET 6 und kompatible Hosts, die das neue .NET Standard 2.1‑Paket nutzen. Die richtige Wahl ist in der Regel das Paket, das direkt zum Host passt und für das Team, das die Anwendung wartet, die wenigste Framework‑Mehrdeutigkeit hinterlässt.
Die Doconut Viewer SDK Übersicht ist der Ausgangspunkt für die Produktfunktionen. Verwenden Sie die frameworkspezifische Dokumentation, um die Paketauswahl zu treffen.
Was die drei Bezeichnungen bedeuten
.NET 8 und .NET 6 sind Anwendungsziele. Eine Webanwendung kann eines dieser Laufzeitumgebungen anvisieren und das passende Doconut-Paket auswählen.
.NET Standard 2.1 ist anders: Es definiert einen Bibliotheks‑API‑Vertrag, den kompatible .NET-Hosts nutzen können. Doconut 26.8.0 führt die aktuelle Doconut.NETStandard‑Generation für Anwendungen ein, die .NET Core 3.0 oder höher anvisieren, einschließlich .NET 5 bis .NET 8. Sie kann nicht von .NET Framework verwendet werden.
Diese Unterscheidung hält die Entscheidung fundiert. Wählen Sie .NET Standard 2.1 nicht, weil es allgemeiner klingt; wählen Sie es, wenn sein Vertrag zur Host‑ und Lösungsstruktur passt.
Praktische Auswahl‑Tabelle
| Anwendungssituation | Doconut-Pfad zur Bewertung | Warum |
|---|---|---|
| Neue Anwendung, die .NET 8 anvisiert | Doconut.NET8 | Direkte Übereinstimmung für die aktuelle .NET‑Entwicklung und den vollständigen .NET 8‑Dokumentationspfad. |
| Bestehende Anwendung, die auf .NET 6 bleiben muss | Doconut.NET6 | Behält das Host‑Ziel bei und bietet gleichzeitig die aktuelle Dependency‑Injection, Middleware, Async‑Session und optionales verteiltes Modell. |
| Kompatibler ASP.NET‑Core‑Host, bei dem der .NET‑Standard‑Vertrag erforderlich ist | Doconut.NETStandard 26.8.0+ | Zielt auf .NET Standard 2.1 ab und stellt die aktuelle Doconut‑Integration für unterstützte Hosts bereit. |
| Bestehende Doconut.NETStandard 26.7.0‑ oder frühere Integration | Planen Sie eine Migration, bevor Sie 26.8.0+ auswählen | Die Paket‑ID bleibt gleich, aber Ziel und API‑Generation ändern sich. |
| Anwendung, die .NET Framework anvisiert | Doconut.NETFramework | .NET Framework kann .NET Standard 2.1 nicht nutzen. |
Diese Tabelle verengt die erste Entscheidung. Lizenzierung, optionale Plugins, Dokumentformate, Bereitstellungsdesign und Upgrade‑Aufwand müssen weiterhin separat validiert werden.
Doconut.NET8 für neue .NET 8‑Anwendungen wählen
Für eine neue .NET 8-Anwendung ist das dedizierte Paket die klarste Wahl zur Bewertung. Die .NET 8 Viewer Seite beschreibt das aktuelle Modell, das auf Dependency Injection, middleware‑bereitgestellten Ressourcen, asynchronen Dokumentensitzungen und optionalen verteilten Workflows basiert.
Eine direkte Laufzeit‑Übereinstimmung erleichtert zudem das Folgen der Dokumentation. Installation, Konfiguration, Fehlersuche, Plugins und Beispiele können alle innerhalb eines frameworkspezifischen Pfads bewertet werden.
Vor der Einführung sollten Sie die Dokumentformate und optionalen Funktionen testen, die das Produkt tatsächlich benötigt. Eine Paket‑Übereinstimmung ersetzt nicht die anwendungsspezifischen Entscheidungen zu Authentifizierung, Autorisierung, Speicherung, Aufbewahrung, Überwachung und Ressourcenlimits.
Wählen Sie Doconut.NET6, wenn der Host auf .NET 6 bleiben muss
Eine etablierte Anwendung kann Abhängigkeiten oder Support‑Verpflichtungen haben, die sie auf .NET 6 halten. Der aktualisierte .NET 6 Viewer ermöglicht es der Anwendung, dieses Ziel beizubehalten, während sie zu Doconut’s aktueller Integrationsarchitektur wechselt.
Dies ist nützlich, wenn ein Laufzeit‑Upgrade und eine Dokument‑Viewer‑Migration nicht im selben Release stattfinden sollen. Das Team kann die Viewer‑Registrierung, die Ressourcenbereitstellung, das asynchrone Öffnen und Dokumentensitzungen modernisieren, während das Host‑Framework stabil bleibt.
Prüfen Sie, ob das bestehende Projekt die klassische oder die aktualisierte Doconut .NET 6‑Integration verwendet. Nur die Paketnamen geben möglicherweise nicht die Generation preis. Die offizielle Migrationsdokumentation identifiziert die API‑Signaturen und Hosting‑Muster, die sie unterscheiden.
Wählen Sie Doconut.NETStandard, wenn der Vertrag zur Lösung passt
Der neue .NET Standard 2.1 Installationsleitfaden definiert die Kompatibilitätsgrenze. Er unterstützt .NET Core 3.0 und spätere Hosts, einschließlich .NET 5, 6, 7 und 8, und schließt .NET Framework aus.
Dieser Pfad kann sinnvoll sein, wenn die Lösung speziell den .NET Standard‑Bibliotheksvertrag erfordert. Die Versionsauswahl ist kritisch: Doconut.NETStandard 26.7.0 und früher zielt auf .NET Standard 2.0 ab und verwendet die vorherige Integration, während 26.8.0 und später auf .NET Standard 2.1 mit der aktuellen API abzielt.
Wenn die Anwendung bereits die ältere Paketgeneration verwendet, konsultieren Sie den .NET Standard Migrationsleitfaden, bevor Sie ein Update durchführen. Die Änderung betrifft mehr als die Kompilierung: Startvorgang, Viewer‑Lebensdauer, Ressourcenrouting, Dokumentenöffnung, Lizenzierung, Plugins und verteilte Veröffentlichung können Aufmerksamkeit erfordern.
Vergleichen Sie die vollständige Anwendungswirkung
Ein kleiner Machbarkeitsnachweis sollte mehr beantworten als „installiert das Paket?“. Bewerten Sie:
- Host‑Kompatibilität: Bestätigen Sie das Anwendungsziel und jedes Projekt, das das Viewer‑Paket referenziert.
- Integrationsgeneration: Identifizieren Sie aktuelle oder klassische Registrierung, Viewer‑Erstellung und Dokumentenöffnungs‑Muster.
- Dokumentabdeckung: Testen Sie repräsentative PDF-, Office-, CAD-, Bild-, E‑Mail- oder medizinische Dateien, die vom Produkt benötigt werden.
- Plugin‑Bedarf: Validieren Sie die Funktionen Suche, Annotation, Konverter oder DICOM einzeln, wenn sie zum Workflow gehören.
- Betriebsmodell: Testen Sie Sitzungsdauer, Caching, Ressourcenbereitstellung, Aufräumen und jedes Single‑Node‑ oder verteilte Design.
- Upgrade‑Aufwand: Trennen Sie Framework‑Änderungen von Doconut‑Änderungen, damit Fehler leichter zu diagnostizieren sind.
- Anwendungskontrollen: Überprüfen Sie Zugriff, Speicherung, Aufbewahrung und Lieferverhalten im umgebenden System.
Notieren Sie die Paketversion und das Framework‑Ziel zusammen mit jedem Ergebnis. Das verhindert, dass ein erfolgreicher Test gegen einen SDK‑Pfad fälschlicherweise als Beweis für einen anderen interpretiert wird.
Machen Sie die Framework‑Wahl explizit
Eine gute Architekturnotiz kann kurz sein: Geben Sie das Anwendungsziel, das ausgewählte Doconut‑Paket und die Version, erforderliche Plugins, das Bereitstellungsmodell und den während der Implementierung genutzten Dokumentationspfad an. Diese Entscheidungsaufzeichnung hilft späteren Upgrades, aus Fakten statt aus Paket‑Namens‑Annahmen zu starten.
Für neue .NET 8‑Entwicklungen beginnen Sie mit dem dedizierten .NET 8‑SDK. Für eine Anwendung, die bei .NET 6 bleibt, evaluieren Sie das aktualisierte .NET 6‑Paket. Verwenden Sie Doconut.NETStandard 26.8.0+, wenn der .NET Standard 2.1‑Vertrag die richtige Passung für einen kompatiblen Host ist, und halten Sie .NET‑Framework‑Anwendungen auf ihrem dedizierten Paketpfad.
Überprüfen Sie das Doconut-Dokumentations‑Hub und eine Testversion herunterladen, um den ausgewählten Pfad mit Ihrer eigenen Anwendung und Ihren Dokumenten zu testen.