Eingebettete Dokumentanzeige sollte sich wie ein Teil der Anwendung anfühlen und nicht wie eine Übergabe an eine alte Browsererweiterung oder ein lokal installiertes Desktop‑Programm. Für Windows‑basierte ASP.NET‑ und .NET‑Projekte stellt Doconut ein Dokument‑Viewer‑SDK bereit, das Geschäfts‑Dokumente innerhalb Ihrer Webanwendung rendern kann.

Dieser Leitfaden erklärt die Architektur einer plugin‑freien Anzeigeerfahrung, ohne undokumentierten Doconut‑Quellcode zu präsentieren.

Dokumente, die durch einen .NET-Renderdienst in einen plugin-freien eingebetteten Betrachter geleitet werden

Was “Plugin-frei” bedeutet

Ein plugin‑freier Viewer verlangt nicht, dass der Endbenutzer Technologien wie ActiveX, Flash, Silverlight oder eine benutzerdefinierte Browsererweiterung installiert, bevor ein Dokument geöffnet wird.

Das reduziert mehrere Reibungsquellen:

Benutzer benötigen keine lokalen Installationsberechtigungen.
IT‑Teams müssen kein clientseitiges Plugin verteilen und aktualisieren.
Die Anwendung hält den Anzeige‑Workflow innerhalb ihrer eigenen Oberfläche.
Legacy‑Plugin‑Abhängigkeiten werden nicht zur Voraussetzung für das Öffnen einer Datei.

Plugin‑frei bedeutet nicht abhängigkeitsfrei. Der Server benötigt weiterhin das richtige SDK, die Laufzeit, Schriftarten, Speicherzugriff, Konfiguration und Lizenz. Die Anwendung bleibt zudem für Authentifizierung, Autorisierung, Aufbewahrung und Überwachung verantwortlich.

Warum serverseitiges Dokument‑Rendering hilft

Geschäftsdokumente sind komplexer als gewöhnlicher Webinhalt. Office‑Dateien, CAD‑Zeichnungen, E‑Mail‑Nachrichten und hochauflösende Bilder erfordern jeweils eine formatbewusste Verarbeitung.

Eine serverseitige .NET‑Komponente kann diese Verarbeitung übernehmen, während die Webanwendung die resultierende Anzeigeerfahrung präsentiert. Dadurch wird vermieden, dass jeder Benutzer die ursprüngliche Authoring‑Software installieren muss.

Doconut ist für diese Rolle konzipiert. Die aktuelle Produktinformation beschreibt die Unterstützung von Dokumenttypen einschließlich PDF, Office‑Dokumenten, CAD‑Zeichnungen, E‑Mail‑Dateien und Bildern. Prüfen Sie die genauen Formate und Funktionen, die Ihre Anwendung benötigt, auf der Doconut‑Viewer‑Seite.

Planen Sie den Anzeige‑Workflow

Eine sichere Dokumentanforderung folgt üblicherweise diesen Schritten:

Der Benutzer wählt ein Dokument anhand einer Anwendungs‑Kennung aus.
ASP.NET authentifiziert die Anforderung.
Der Server prüft den Zugriff auf dieses spezifische Dokument.
Die Anwendung ermittelt den geschützten Speicherort.
Das Dokument wird an die Anzeige‑Schicht über die unterstützte Integrationsmethode übergeben.
Die Anwendung protokolliert das Ergebnis und gibt temporäre Ressourcen frei.

Der Client sollte niemals Speicheranmeldeinformationen, uneingeschränkte Serverpfade oder mehr Dokumentinformationen erhalten, als die autorisierte Sitzung erfordert.

Verwenden Sie standardmäßige ASP.NET‑Sicherheitsgrenzen

Die Anzeige‑Seite sollte wie jede andere sensible Ressource geschützt werden.

Standard‑.NET‑Mechanismen können umfassen:

Authentifizierungs‑Middleware
Das [Authorize]‑Attribut
Autorisation‑Richtlinien und Claims
Ressourcenbasierte Autorisierung
Dependency Injection für Speicher‑ und Anzeige‑Dienste
Strukturiertes Logging mit Filterung sensibler Daten

Autorisation muss auf dem Server ausgewertet werden. Das Verstecken einer Toolbar‑Aktion oder Route in der Benutzeroberfläche verhindert nicht, dass ein entschlossener Client sie direkt anfordert.

Halten Sie SDK‑Zugriff hinter einem Anwendungs‑Service

Vermeiden Sie es, viewer‑spezifische Aufrufe über Controller und Seiten zu verteilen. Ein dedizierter Anwendungs‑Service kann:

Autorisierten Dokument‑Kennungen auflösen
Einen kontrollierten Stream öffnen
Konfiguration für die installierte SDK‑Version anwenden
Datei‑ und Stream‑Ressourcen freigeben
Technische Fehler in sichere Anwendungsfehler umwandeln
Zeitmessungen und bereinigte Diagnosen protokollieren

Diese Grenze erleichtert das Testen der Anwendung und reduziert die Auswirkungen zukünftiger SDK‑Updates.

Verwenden Sie die offiziellen Doconut‑Download‑ und Dokumentationsressourcen für die Paketinstallation und versionsspezifische API‑Anleitungen.

Erstellen Sie einen nützlichen Viewer‑Host

Der von der Anwendung bereitgestellte Viewer‑Container sollte ausreichend Platz für echte Dokumente bieten. Vermeiden Sie schmale Karten und feste Desktop‑Breiten.

.viewer-workspace {
  display: grid;
  grid-template-rows: auto minmax(0, 1fr);
  width: 100%;
  min-height: 36rem;
  height: calc(100dvh - 4rem);
}

.viewer-host {
  min-width: 0;
  min-height: 0;
  overflow: hidden;
}

Dies ist Standard‑CSS für die umgebende Seite, nicht Doconut‑Konfiguration. Zielgerichtete undokumentierte interne Selektoren oder erfundene SDK‑Optionen sollten vermieden werden.

Die Seite sollte außerdem bereitstellen:

Einen klaren Ladezustand
Eine sichere Fehlermeldung
Einen sichtbaren Dokumenttitel
Eine Möglichkeit, zum übergeordneten Workflow zurückzukehren
Barrierefreie Anwendungssteuerungen
Genügend Platz für breite Tabellenkalkulationen und detaillierte Zeichnungen

Validieren Sie Dokumente vor dem Rendering

Wenn Benutzer Dateien hochladen, prüfen Sie:

Dateigröße
Erweiterung und Dateisignatur
Unterstütztes Format
Passwort‑ oder Verschlüsselungsanforderungen
Geschäftsspezifische Einschränkungen
Servergenerierten Speicher‑Namen

Erstellen Sie keine Serverpfade direkt aus dem ursprünglichen Dateinamen. Speichern Sie eine sichere Anwendungs‑Kennung und lösen Sie sie über einen autorisierten serverseitigen Service auf.

Bereiten Sie den Windows‑Server vor

Das Rendering‑Verhalten kann von der Serverumgebung abhängen. Bestätigen Sie:

Unterstützte Windows‑ und .NET‑Versionen
Erforderliche Schriftarten
Temporären Speicherort und Berechtigungen
Verfügbare CPU, Arbeitsspeicher und Festplattenkapazität
Maximale Dokumentgröße und gleichzeitige Sitzungen
Lizenzkonfiguration
Bereinigungs‑Verfahren

Testen Sie repräsentative Kundendokumente in einer Umgebung, die der Produktion entspricht.

Sicherheits‑ und Datenschutz‑Checkliste

Vor der Veröffentlichung:

Anzeige‑Anfragen bei Bedarf authentifizieren.
Den Benutzer für das spezifische Dokument autorisieren.
Speicherpfade und Anmeldeinformationen auf dem Server behalten.
Berechtigungen für temporäre Dateien einschränken.
Aufbewahrung für Originale, temporäre Daten und Exporte festlegen.
Fehler, die Benutzern angezeigt werden, bereinigen.
Dokumentinhalte und Geheimnisse aus Protokollen ausschließen.
Upload‑ und Parallelitäts‑Grenzen anwenden.
SDK und Anwendungsabhängigkeiten aktuell halten.

Behauptungen zur Konformität sollten das vollständig bereitgestellte System und die Prozesse Ihrer Organisation widerspiegeln, nicht nur eine einzelne UI‑Komponente.

Testen Sie mehr als den Happy‑Path

Ihre Testbibliothek sollte enthalten:

Mehrseitige PDFs
Große Tabellenkalkulationen
Detaillierte CAD‑Zeichnungen
Präsentationen mit ungewöhnlichen Schriftarten
E‑Mail‑Dateien mit Anhängen
Große Bilder
Beschädigte und nicht unterstützte Dateien
Unautorisierte Anfragen
Gleichzeitige Anzeige‑Sitzungen
Unterbrochene Anfragen und Anwendungsneustarts

Stellen Sie sicher, dass Fehler keine Serverpfade, Stack‑Traces oder Speicher‑URLs preisgeben.

Wo Doconut passt

Doconut liefert die eingebettete Dokument‑Anzeige‑Funktionalität innerhalb einer .NET‑Webanwendung. Ihre Anwendung stellt die umgebende Sicherheit, den Speicher, den Workflow, das responsive Layout und die betrieblichen Steuerungen bereit.

Diese Trennung ermöglicht es Teams, legacy‑plugin‑abhängige Workflows zu ersetzen, ohne vorzugeben, dass die Dokumentenverarbeitung mühelos oder verantwortungsfrei wird.

Entdecken Sie das verifizierte Doconut .NET‑Dokumenten‑Viewer‑SDK, und nutzen Sie anschließend die offizielle Download‑Seite für die Anleitungen, die zu Ihrer gewählten Version passen.

Fazit

Eine plugin‑freie Dokumentenerfahrung reduziert Installationsfriktionen und hält Benutzer innerhalb Ihrer Anwendung. Implementieren Sie sie auf einem serverautorisierten Dokumenten‑Flow, isolieren Sie den SDK‑Zugriff, stellen Sie einen geräumigen Viewer‑Host bereit und testen Sie reale Dateien unter produktionsähnlicher Last.

Für Windows‑basierte ASP.NET‑ und .NET‑Anwendungen kann Doconut die Dokumenten‑Anzeigeschicht bereitstellen, während Ihr Team die Kontrolle über Anwendung und Dokumenten‑Lebenszyklus behält.