Vorherige Integration

Verwenden Sie diesen Abschnitt, wenn eine bestehende .NET Standard-Anwendung Viewer noch manuell erstellt, Optionen an die Middleware übergibt, eine Webfarm über einen gemeinsamen Ordner koordiniert oder die Viewer‑Skripte in die Anwendung kopiert. Diese Architektur bleibt für Kunden, die nicht migriert sind, dokumentiert.

Die Paketversion identifiziert die Generation

Die Paket-ID allein reicht nicht. Beide Generationen werden als Doconut.NETStandard veröffentlicht:

Überprüfen Sie die Version in der Projektdatei, der Sperrdatei oder dem zwischengespeicherten .nupkg, bevor Sie ein Handbuch auswählen. Ein Paketverweis, der nur Doconut.NETStandard enthält, sagt Ihnen nichts darüber, gegen welche API der Code geschrieben wurde.

Identifizieren der vorherigen Integration

Die Anwendung verwendet die vorherige Integration, wenn sie eine oder mehrere dieser Signaturen enthält:

var viewer = new Viewer(_cache, _accessor);
var viewer = new Viewer(_cache, _accessor, licenseFilePath);

var token = viewer.OpenDocument(path, config, documentOptions);
viewer.InitCache();

appBranch.UseDoconut(new DoconutOptions { UnSafeMode = false, ShowDoconutInfo = false });

appBranch.UseDoconutWebFarm(new WebFarmOptions { Path = sharedFolder });

Viewer.DoconutLicense(licenseStream);
Viewer.SetLicensePlugin(pluginLicenseStream);

var converter = viewer.Converter.GetConverter();

Sein using-Block ist ein weiteres zuverlässiges Signal – die Konfigurationstypen waren über mehrere Namespaces verteilt:

using Doconut.Configs;
using Doconut.Configs.View;
using Doconut.Configs.Cloud;
using Doconut.Models;

Frühere Seiten laden häufig auch anwendungsverwaltete Kopien von:

docViewer.js
documentLinks.js
docViewer.UI.js

und deklarieren Viewer‑Callbacks als globale Variablen, die nach der Container‑ID benannt sind, wie z. B. ctlDoc_OnViewerReady().

Die aktuelle Integration wird stattdessen durch AddDoconut(), UseDoconutResources(), UseDoconut() ohne Argumente, ein injiziertes Viewer, OpenDocumentAsync() und den abgeflachten Doconut‑Namespace identifiziert.

Öffnen des erhaltenen Handbuchs

Das übersetzte historische Handbuch befindet sich weiterhin unter Legacy .NET Standard-Setup. Seine URL wurde nicht weitergeleitet oder ersetzt, weil es eine reale Integrationsgeneration beschreibt, die bestehende Anwendungen noch verwenden.

Kombinieren Sie keine Snippets aus diesem Handbuch mit der aktuellen AddDoconut()‑Dokumentation. Viewer‑Konstruktion, Middleware‑Routing, Lizenzen, Ressourcen, Konvertierung, Web‑Farm‑Koordination und Sitzungs‑Eigentum sind alle unterschiedlich.

Planung einer Migration

Verwenden Sie Migration zu .NET Standard 2.1 für die verifizierte Zuordnung von manueller Konstruktion und synchronem Dokumenten‑Öffnen zu DI, aktueller Middleware, asynchronen Sitzungen, generierten Ressourcen, verteilter Veröffentlichung und funktionsgesteuerten Plugins.

Zwei Dinge verdienen vor dem Start Aufmerksamkeit:

• Das Host‑Framework. netstandard2.1 erfordert .NET Core 3.0 oder höher. Ein .NET Framework‑Host kann das aktuelle Paket überhaupt nicht nutzen.
• Die clientseitigen Änderungen. Zwei davon schlagen stillschweigend fehl – der Server funktioniert weiter und die Browser‑Konsole bleibt leer. Sie werden im Migrationsleitfaden behandelt.

Bewahren Sie die vorherige Bereitstellung unverändert, bis die aktuelle Anwendung ihre Dokument-, Lizenz-, Such-, Annotations-, Konverter-, DICOM-, Sicherheits- und Rollback‑Tests bestanden hat.