Sie können PDFs, Office‑Dateien, CAD‑Zeichnungen, E‑Mails und Bilder im Browser ohne die Installation veralteter Plugins anzeigen. Für Windows‑basierte .NET‑Anwendungen bietet Doconut Viewer die serverseitige Dokumentenverarbeitung, während die Benutzer innerhalb der Business‑Anwendung bleiben.

Modernes plugin‑freies Dokumenten‑Viewing in einer Windows‑Browser‑Anwendung

In den folgenden Abschnitten werden wir untersuchen, warum das Entfernen veralteter Plugins wichtig ist, einen ASP.NET‑Core‑Integrations‑Workflow skizzieren und Drag‑and‑Drop‑Uploads sowie die Blazor‑Integration besprechen, ohne auf nicht verifizierten SDK‑Code zu setzen.

Null‑Plugins: Warum sie ein Wendepunkt für .NET‑Web‑Apps sind

Reibung durch „Zuerst‑installieren“ beseitigen

Traditionelle Betrachter klammern sich an ActiveX, Java oder Flash. Diese erfordern Berechtigungen, lösen Sicherheitswarnungen aus und funktionieren in modernen Browsern nicht mehr. Doconut umgeht das, indem es auf dem Server rendert und dem Browser normales HTML und Bilder sendet – nichts, das auf dem Client installiert werden muss, keine Eingabeaufforderungen, keine IT‑Tickets.

Diese Unterscheidung ist für den Rest dieses Artikels wichtig, daher sollte man es klarstellen: Das Parsen und Rasterisieren erfolgt auf Ihrem Server, nicht im Browser des Benutzers. Plugin‑frei bedeutet, dass der Client nichts benötigt; es bedeutet nicht, dass die Arbeit in JavaScript verlagert wurde.

Den Browser‑Sandbox intakt halten

Da kein externes Plugin geladen wird, bleibt der Browser‑Sandbox unberührt. Noch besser: Der Rechner des Benutzers erhält das Ausgangsdokument nie – er bekommt gerenderte Seiten – sodass ein bösartiges PDF dort nichts ausführen kann.

Was dies nicht tut, ist die Angriffsfläche zu entfernen; sie wird auf Ihren Server verlagert, wo ein Parser untrusted Eingaben verarbeitet. Führen Sie ihn mit minimalen Rechten aus, halten Sie ihn gepatcht und validieren Sie Uploads. Transport‑Sicherheit, Verschlüsselung im Ruhezustand und Aufbewahrung sind von Ihrer Anwendung zu implementieren – das SDK liefert sie nicht.

Zukunftssicher über Browser und Geräte hinweg

Da der Browser nur Standard‑HTML und Bilder anzeigen muss, gibt es kaum etwas, das durch ein Browser‑Update kaputt gehen kann. Chrome, Edge, Safari oder ein mobiler WebView verhalten sich alle gleich, ohne „Plugin fehlt“-Warnungen und ohne versionsspezifische Workarounds – und ein leistungsschwaches Gerät ist kein Nachteil, da es das Rendering nicht übernimmt.

Einbetten des plugin‑freien Viewers von Doconut App in ASP.NET Core

Um den Viewer zu integrieren, erzeugen Sie eine kurzlebige, signierte URL für das Dokument auf dem Server und übergeben sie an den Client. Der Server rendert das Dokument und streamt die Seiten über HTTPS in ein Container‑Element auf der Seite.

Server‑seitiger Workflow (konzeptionell)

Empfangen Sie eine Anforderung für ein Dokument.
Rufen Sie die Datei aus Ihrem Speicher ab (SQL, Blob usw.).
Erstellen Sie eine zeitlich begrenzte, signierte URL, die auf die verschlüsselte Datei verweist.
Geben Sie diese URL an die Razor‑View zurück.

Razor‑View (konzeptionell)

Lassen Sie die View für Layout und autorisierten Viewer‑Zustand verantwortlich sein, während der Server das Dokument abruft und verarbeitet. Verwenden Sie ausschließlich die Client‑Ressourcen und die Initialisierungssequenz, die für die installierte Doconut‑Version dokumentiert sind.

Wenn die Seite geladen wird, fordert der Client das Dokument über seine signierte URL an und zeigt die vom Server zurückgelieferten Seiten an. Kein ActiveX, Java oder Flash.

Warum das wichtig ist

Null‑Plugins: Der Client benötigt nur einen Browser und nichts weiter.
Die Quelldatei erreicht den Benutzer nie: Er erhält gerenderte Seiten, sodass keine lokale Kopie zum Weiterleiten, Zwischenspeichern oder Leaken existiert.
Sicherheit liegt in Ihrer Verantwortung: Die kurzlebige, signierte URL ist Code, den Sie schreiben. Der Viewer erzwingt dies nicht für Sie, also integrieren Sie es in das Design und nicht als Annahme.
Paging: Seiten werden bei Bedarf geliefert, nicht alle auf einmal, was ein langes PDF oder eine umfangreiche Zeichnung nutzbar macht.

Rendering unterstützter Formate ohne Plugins

Die Engine des SDK verarbeitet 75 Dateierweiterungen aus 18 Familien — PDF, DOCX, XLSX, PPTX, DWG, DXF, PSD, VSDX, MPP, EML, MSG, EPUB, TIFF, PNG, JPEG und den Rest, einschließlich DICOM über sein separat lizenziertes Plugin. Die kostenlosen Viewer unter doconut.app akzeptieren 73 davon: alles außer .dcm und .ima.

Die Engine identifiziert die Datei anhand ihres Inhalts und nicht anhand ihrer Erweiterung, was wichtiger ist, als es klingt — viele Dateien mit der Endung .xls sind tatsächlich HTML‑Tabellen oder CSV.

Ein Hinweis zur Treue, da „pixel‑perfect“ ein Versprechen ist, das kein Renderer halten kann: Dokumente, die Ressourcen referenzieren, die sie nicht enthalten, weichen von dem ab, was ihr Autor gesehen hat. Schriften, die nie eingebettet wurden, werden ersetzt, und externe Referenzen eines DWG sind nicht im DWG enthalten.

Drag‑and‑Drop‑Upload mit sofortiger, plugin‑freier Darstellung

Unternehmen möchten, dass Nutzer Dateien direkt in der Anwendung vorab sehen. Sie können eine Drag‑and‑Drop‑Zone hinzufügen, die ein Dokument hochlädt, eine signierte Ansicht‑URL erzeugt und das Ergebnis ohne Plugin auf dem Client anzeigt. Der gesamte Vorgang bleibt in Ihrem .NET‑Backend — was Ihnen ermöglicht, Prüfpfade zu führen, da das Logging von Ihnen geschrieben wird.

Client‑seitiger Ablauf (konzeptionell)

Benutzer zieht eine Datei in einen festgelegten Bereich.
JavaScript sendet die Datei an einen ASP.NET‑Core‑Endpunkt.
Der Endpunkt speichert die Datei sicher und gibt eine signierte Ansicht‑URL zurück.
Die Seite fügt ein <div> mit data‑doc‑url ein, das auf diese URL verweist.
Doconut App‑Skript rendert das Dokument sofort.

Die Darstellung erfolgt auf Ihrem Server, planen Sie also entsprechend: Hier werden CPU und Arbeitsspeicher beansprucht, und die Skalierung richtet sich nach gleichzeitigen Viewern statt nach Benutzern. Prüfen Sie, wo das SDK temporäre Renderausgaben schreibt, und stellen Sie sicher, dass diese bereinigt werden — verwaiste Dateien in einem temporären Verzeichnis sind der am häufigsten übersehene Teil einer Integration.

Konsistentes Anzeigen in Windows‑basierten Workflows

Ein Browser‑Viewer kann einen konsistenten Einstiegspunkt für Nutzer einer internen Windows‑Anwendung bieten, ohne separate Desktop‑Dokumentprogramme zu benötigen. Teams sollten unterstützte Browser, Bildschirmgrößen, Eingabemethoden, Dokumentenkomplexität und Barrierefreiheitsanforderungen testen, anstatt identisches Verhalten in jeder Umgebung anzunehmen.

Erweiterung des Viewers mit Blazor – Alles innerhalb Ihres .NET‑Ökosystems behalten

Wenn Ihr Team einen komponenten‑zentrierten Ansatz bevorzugt, können Sie das client‑seitige Skript des Viewers in eine Blazor‑Komponente einbetten, unter einem der Hosting‑Modelle. Das hält die Integration innerhalb der .NET‑Welt. Beachten Sie, dass das Hosting‑Modell nur beeinflusst, wo Ihr UI‑Code ausgeführt wird — die Dokumenten‑Darstellung bleibt in jedem Fall auf dem Server.

Blazor‑Komponenten‑Übersicht (konzeptionell)

Injizieren Sie einen Service, der für eine gegebene Datei‑ID eine sichere Ansicht‑URL erzeugen kann.
Bei der Initialisierung fordern Sie die URL vom Service an.
Nachdem die Komponente gerendert wurde, initialisieren Sie den Viewer mittels der unterstützten Integrations‑API für die installierte Doconut‑Version.

Die Blazor‑Komponente kann den Viewer‑Zustand koordinieren, während das Backend für den Dokumenten‑Zugriff und die Verarbeitung verantwortlich bleibt. Dadurch bleibt der Workflow innerhalb der .NET‑Anwendung, ohne Annahmen über eine globale JavaScript‑API zu veröffentlichen.

Wichtige Erkenntnisse

Keine Plugins beseitigen Installationshürden, Sicherheitswarnungen und Kompatibilitätsprobleme.
Das SDK rendert 75 Erweiterungen — PDF, Office, CAD, E‑Mail und Bilder — auf dem Server, nicht im Browser.
Integration: Erzeugen Sie serverseitig eine signierte Ansicht‑URL und zeigen Sie die zurückgegebenen Seiten in einem Container an.
Drag‑and‑Drop‑Upload plus In‑Place‑Vorschau hält die Nutzer im Arbeitsfluss.
Es verhält sich gleich auf Desktop, Tablet und Mobilgeräten, weil der Browser nur standardisierte Ausgaben anzeigt.
Blazor‑Entwickler können den Viewer in einer .NET‑Komponente einbetten.
Sicherheit ist architektonisch und nicht nur eine Feature‑Liste: Die Quelldatei erreicht den Client nie, und das Dokument verlässt Ihre Infrastruktur nicht. Verschlüsselung im Ruhezustand, Ablauf von signierten URLs und Prüfprotokollierung liegen in Ihrer Verantwortung — und Doconut verfügt über keine ISO‑27001-, SOC‑2- oder HIPAA‑Zertifizierung, auf die Sie sich stützen könnten.

Häufige Fragen

Q: Muss ich etwas auf den Client‑Rechnern installieren?
A: Nein. Der Doconut App Viewer läuft vollständig im Browser mit HTML5 und JavaScript. Benutzer benötigen nur einen modernen Browser — keine ActiveX-, Java- oder Flash-Installationen sind erforderlich.

Q: Wie geht er mit großen Dateien um?
A: Seiten werden bei Bedarf gerendert und ausgeliefert, sodass ein Leser zu einer Seite springen kann, ohne auf das gesamte Dokument warten zu müssen. Beachten Sie, dass dies Ihr Server erledigt — testen Sie mit Ihren größten realen Dateien, um die Größe zu bestimmen. Auf der kostenlosen Seite bei doconut.app ist das Limit unsererseits und gilt pro Format: 25 MB für ein PDF, 10 MB für eine CAD‑Zeichnung.

Starten Sie noch heute mit Doconut App

Bereit, veraltete Plugins aus Ihrer Windows‑basierten .NET‑Anwendung zu entfernen? Evaluieren Sie das Doconut SDK mit den Browsern, Dokumentformaten und Workloads, die in Ihrer Organisation verwendet werden.