Das Hinzufügen einer Dokumentenanzeige zu einer Business‑Anwendung erfordert mehr als das Einbetten einer PDF in ein iframe. Office‑Dateien, CAD‑Zeichnungen, E‑Mail‑Dateien und Bilder benötigen unterschiedliche Rendering‑Fähigkeiten, während die Anwendung weiterhin Authentifizierung, Speicherung, Autorisierung und Aufbewahrung steuern muss.
Doconut ist ein .NET‑Dokumenten‑Viewer‑SDK, das entwickelt wurde, um Dokumenten‑Rendering und Interaktion in Web‑Anwendungen einzubetten. Anstatt ein nicht verifiziertes Quellcode‑Rezept zu präsentieren, erklärt dieser Leitfaden die Integrationsentscheidungen, die Ihr Team treffen sollte, und identifiziert die gängigen .NET‑Komponenten, die das SDK typischerweise umgeben.
Warum ein eingebetteter Betrachter sich von einem Dateidownload unterscheidet
Ein Download‑Endpunkt überträgt die Originaldatei und überlässt das Anzeigeerlebnis Software außerhalb Ihrer Anwendung. Ein eingebetteter Betrachter hält den Benutzer innerhalb Ihres Produkts und kann einen konsistenten Ort für Navigation, Suche, Überprüfung und andere aktivierte Funktionen bieten.
Die Eigenentwicklung der Rendering‑Schicht ist schwierig, weil jedes Format eigene Regeln hat:
- PDF‑Dateien können eingebettete Schriftarten, Anmerkungen, Formulare und sehr große Seitenmengen enthalten.
- Word‑, Excel‑ und PowerPoint‑Dateien erfordern sorgfältige Layout‑ und Schriftarten‑Handhabung.
- CAD‑Zeichnungen benötigen genaue Skalierung, Ebenen und detaillierten Zoom.
- E‑Mail‑ und Bildformate bringen Anhänge, Metadaten, Farb‑ und Auflösungsaspekte mit sich.
Ein dediziertes SDK ermöglicht es dem Anwendungsteam, sich auf Zugriffskontrolle, Workflows und Benutzererlebnis zu konzentrieren, anstatt für jedes unterstützte Format einen separaten Renderer zu warten.
Schritt 1: Die erforderlichen Formate und Funktionen bestätigen
Beginnen Sie mit einer realen Bestandsaufnahme der Dateien, die Ihre Nutzer öffnen. Trennen Sie wesentliche Formate von gelegentlichen und erfassen Sie repräsentative Beispiele für Tests.
Ihre Checkliste könnte enthalten:
- PDF‑ und XPS‑Dokumente
- Textverarbeitungs‑Dokumente
- Tabellenkalkulationen
- Präsentationen
- CAD‑Zeichnungen
- E‑Mail‑Dateien
- Gängige Bildformate
Identifizieren Sie dann die Funktionen, die für jeden Workflow wichtig sind. Anzeige, Textsuche, Anmerkungen, Druck und Konvertierung sind unterschiedliche Fähigkeiten und können verschiedene Doconut‑Komponenten oder Lizenzen erfordern.
Überprüfen Sie den aktuellen Produktumfang auf der verifizierten Doconut Viewer‑Seite, bevor Sie sich auf ein Format oder eine Funktion festlegen. Produktfähigkeiten können sich ändern, daher sollten Ihre Akzeptanztests die endgültige Autorität für die Dokumente darstellen, die Ihre Kunden tatsächlich verwenden.
Schritt 2: Festlegen, wo Dokumente in die Anwendung gelangen
Eine ASP.NET‑Anwendung kann Dokumente aus mehreren kontrollierten Quellen erhalten:
- Ein Upload, verarbeitet als ASP.NET Core
IFormFile - Ein geschützter Dateispeicherort
- Eine Datenbank oder ein Dokumenten‑Management‑Repository
- Objektspeicher, auf den der Server zugreift
- Ein interner Service, der einen
Streamzurückgibt
Der Anzeige‑Workflow sollte eine server‑autorisierte Dokumentreferenz verwenden. Legen Sie keine Speicher‑Anmeldeinformationen, uneingeschränkten Dateipfade oder permanente öffentliche URLs im clientseitigen Markup ab.
Wenn Nutzer Dateien hochladen, validieren Sie diese vor dem Rendering. Prüfen Sie Dateigröße, Erweiterung, Dateisignatur und etwaige geschäftsspezifische Einschränkungen. Speichern Sie die vom Server generierte Kennung, anstatt den ursprünglichen Dateinamen als Pfad zu vertrauen.
Schritt 3: Authentifizierung und Autorisierung definieren
Die Anwendung – nicht die Viewer‑UI – sollte entscheiden, wer ein Dokument öffnen darf.
In ASP.NET Core können Standardmechanismen wie Authentifizierungs‑Middleware, das [Authorize]‑Attribut, Richtlinien, Claims und ressourcenbasierte Autorisierung den Endpunkt schützen, der eine Ansichtssitzung startet. Die Autorisierungsentscheidung sollte sowohl den aktuellen Benutzer als auch das angeforderte Dokument berücksichtigen.
Ein sicherer Anforderungsablauf sieht folgendermaßen aus:
- Der Benutzer fordert ein Dokument mittels einer anwendungsseitigen Kennung an.
- Der Server authentifiziert den Benutzer.
- Der Server prüft, ob der Benutzer auf dieses spezielle Dokument zugreifen darf.
- Der Server ermittelt den geschützten Speicherort.
- Der Viewer erhält nur die Informationen, die für diese autorisierte Sitzung nötig sind.
Gehen Sie niemals davon aus, dass das Verstecken eines Toolbar‑Buttons eine Autorisierungskontrolle darstellt. Serverseitige Zugriffsprüfungen bleiben notwendig, selbst wenn Download‑ oder Druck‑Steuerelemente nicht angezeigt werden.
Schritt 4: Doconut über die offiziellen Integrationsressourcen hinzufügen
Verwenden Sie das aktuelle Paket und die Installationsanweisungen, die von Doconut bereitgestellt werden. Die verifizierte Doconut‑Download‑Seite bietet Zugriff auf NuGet‑Integrationsressourcen, Dokumentation, Beispiele und Demos.
Die genaue Einrichtung kann abhängen von:
- Ihrem ASP.NET‑ oder .NET‑Anwendungstyp
- Dem ausgewählten Doconut‑Produkt und Plugins
- Der Doconut‑Version
- Ihrer Lizenz
- Den Dokumentenformaten und Funktionen, die Sie aktivieren
- Ihrer Windows‑Server‑Konfiguration
Befolgen Sie die Dokumentation, die zur installierten Version passt. Vermeiden Sie das Kopieren von Initialisierungsschnipseln aus unverwandten Blog‑Posts, da Namespaces, Konfiguration, Asset‑Pfade und APIs zwischen Versionen variieren können.
Schritt 5: Einen dedizierten Viewing‑Boundary erstellen
Halten Sie die Dokumentenanzeige hinter einem kleinen Anwendungs‑Service, anstatt SDK‑Funktionalität über Controller und UI‑Komponenten zu verstreuen.
Dieser Service kann verantwortlich sein für:
- Auflösen einer autorisierten Dokumenten‑Kennung
- Öffnen des Dokuments als kontrollierten
Stream, wenn nötig - Bereitstellung der erforderlichen Anzeige‑Konfiguration
- Freigabe von Datei‑ und Stream‑Ressourcen
- Übersetzung technischer Fehler in sichere Anwendungs‑Fehlermeldungen
- Aufzeichnung betrieblicher Metriken, ohne Dokumenteninhalte zu protokollieren
Dieser Boundary erleichtert Upgrades und reduziert das Risiko, Speicher‑Details an die Präsentationsschicht zu leaken. Er bietet zudem Tests einen klaren Ort, um eine sichere Implementierung zu substituieren.
Schritt 6: Die Viewer‑Seite entwerfen
Der Viewer sollte genug Platz bieten, um nützlich zu sein. Eine schmale Karte, umgeben von nicht verwandten Steuerelementen, macht große Tabellenkalkulationen und CAD‑Zeichnungen schwer zu inspizieren.
Planen Sie die Seite um:
- Eine stabile Viewer‑Höhe
- Klare Lade‑, Leere‑ und Fehlermeldungs‑Zustände
- Einen prägnanten Dokumententitel
- Tastatur‑zugängliche umgebende Steuerelemente
- Ein Layout, das wichtige Viewer‑Steuerelemente nicht verbirgt
- Einen eindeutigen Weg, zum übergeordneten Workflow zurückzukehren
Testen Sie mit langen Dateinamen, großen Seitenzahlen, breiten Tabellen, detailreichen Zeichnungen und Dokumenten, die nicht rendern können. Der Fehlermeldungs‑Zustand darf keine Server‑Pfade, Ausnahme‑Traces oder Speicher‑URLs preisgeben.
Schritt 7: Dateien und temporäre Daten verwalten
Definieren Sie vor dem Rollout eine Aufbewahrungsrichtlinie. Betrachten Sie die Originaldatei, temporäre Rendering‑Daten, Caches, Exporte, Anmerkungen und Protokolle separat.
Nützliche Schutzmaßnahmen umfassen:
- Ein dediziertes temporäres Verzeichnis mit eingeschränkten Berechtigungen
- Eindeutig vom Server generierte Namen
- Aufräumen nach abgeschlossenen und fehlgeschlagenen Sitzungen
- Einen geplanten Prozess für verwaiste temporäre Dateien
- Speicher‑Quoten und Monitoring
- Verschlüsselung im Ruhezustand, sofern Ihre Sicherheitsrichtlinie dies verlangt
Machen Sie das Aufräumen beobachtbar. Wenn das Löschen stillschweigend fehlschlägt, können temporäre Dateien ansammeln und sowohl betriebliche als auch sicherheitsrelevante Probleme verursachen.
Schritt 8: Produktions‑Sicherheitsmaßnahmen konfigurieren
Dokumenten‑Rendering kann CPU, Arbeitsspeicher und temporären Festplattenspeicher beanspruchen. Schützen Sie die Anwendung mit expliziten Limits:
- Maximale Upload‑Größe
- Maximale gleichzeitige Rendering‑Jobs
- Anfragen‑ und Verarbeitungs‑Timeouts
- Warteschlangen‑Limits, wenn Rendering asynchron erfolgt
- Temporäre Speicher‑Quoten
- Gesundheits‑Checks und strukturierte Fehler‑Überwachung
Bei großen oder unvorhersehbaren Workloads sollten Sie das Rendering von latenzsensiblen Anwendungs‑Prozessen isolieren. Messen Sie mit kundenähnlichen Dokumenten statt ausschließlich mit kleinen Testdateien.
Schritt 9: Den kompletten Workflow testen
Ein erfolgreicher Integrationstest sollte mehr abdecken als „die erste Seite erschien“.
Testen Sie:
- Jedes erforderliche Dateiformat
- Kleine, große, mehrseitige und beschädigte Dateien
- Dokumente mit ungewöhnlichen Schriftarten
- Passwortgeschützte Dateien, wenn Ihr Workflow sie unterstützt
- Autorisierte und nicht autorisierte Benutzer
- Gleichzeitige Ansichtssitzungen
- Anwendung‑Neustarts und unterbrochene Anfragen
- Aufräumen nach Erfolg und Misserfolg
- Viewer‑Funktionen, die in Ihrer gewählten Produktkonfiguration enthalten sind
Pflegen Sie eine versionierte Sammlung gesäuberten Testdokuments. Führen Sie sie erneut aus, wenn Sie Doconut, .NET, Windows Server, Speicher‑Infrastruktur oder verwandte Abhängigkeiten aktualisieren.
Sicherheits‑Checkliste
Vor der Veröffentlichung prüfen Sie, dass:
- Jede Anzeige‑Anfrage dort, wo nötig, Authentifizierung erfordert.
- Die Autorisierung für das spezifische Dokument geprüft wird.
- Benutzergesteuerte Eingaben nicht zu einem uneingeschränkten Server‑Dateipfad werden können.
- Speicher‑Anmeldeinformationen niemals den Client erreichen.
- Upload‑Grenzen und Validierung aktiviert sind.
- Temporäre Dateien eingeschränkten Zugriff haben und eine getestete Aufräum‑Richtlinie besitzen.
- Protokolle keine Dokumenteninhalte, Geheimnisse oder sensible URLs enthalten.
- Fehlermeldungen, die dem Benutzer gezeigt werden, gesäubert sind.
- SDK‑ und Anwendungs‑Abhängigkeiten einem Update‑Prozess folgen.
Viewer‑Steuerelemente können Ihren Geschäfts‑Workflow unterstützen, aber sie können nicht jede Form der Erfassung verhindern, sobald Informationen einem autorisierten Benutzer sichtbar sind. Nutzen Sie sie zusammen mit Zugriffskontrollen und einer geeigneten Informations‑Schutz‑Richtlinie.
Wo Doconut hineinpasst
Doconut liefert die Dokumenten‑Anzeige‑Funktionalität innerhalb der .NET‑Anwendung, während Ihre Anwendung weiterhin für Identität, Autorisierung, Dateispeicherung, Aufbewahrung, Auditing und den umgebenden Workflow verantwortlich ist.
Diese Aufgabenteilung bietet .NET‑Teams einen praktischen Weg, Geschäftsdokumente zu unterstützen, ohne mehrere Rendering‑Engines von Grund auf zu bauen. Gleichzeitig bleiben produkt‑spezifische Integrationsdetails an die offizielle Dokumentation der eingesetzten Version gebunden.
Entdecken Sie das Doconut .NET Dokumenten‑Viewer‑SDK und nutzen Sie anschließend die offiziellen Download‑ und Dokumentations‑Ressourcen, um es mit Ihren eigenen Dokumenten zu evaluieren.
Fazit
Ein zuverlässiger eingebetteter Dokumenten‑Viewer beginnt mit klaren Format‑Anforderungen und einem sicheren serverseitigen Dokumenten‑Flow. Validieren Sie Eingaben, autorisieren Sie jede Dokumenten‑Anfrage, isolieren Sie den SDK‑Zugriff hinter einem Anwendungs‑Service, planen Sie das Aufräumen temporärer Dateien und testen Sie mit realistischen Dateien.
Mit diesen Grundlagen kann Doconut die Anzeige‑Schicht für Ihre Windows‑basierte .NET‑Webanwendung bereitstellen, während Ihr Team die Kontrolle über die Anwendungsarchitektur und den Dokumenten‑Lebenszyklus behält.