Sie können einen plugin‑freien Dokumentenbetrachter in eine ASP.NET Core-, MVC- oder WebForms-Anwendung einbetten, ohne dass ein einziger Benutzer etwas installieren muss.
Unternehmen, die Verträge, Zeichnungen oder Design‑Assets bereitstellen, benötigen einen Betrachter, der Unternehmens‑Sicherheitsrichtlinien respektiert und niemals Benutzer zwingt, veraltete Browser‑Plugins zu installieren. Doconut bietet ein .NET‑Dokumentenbetrachter‑SDK für browserbasierte PDF‑, Office‑, CAD‑, E‑Mail‑ und Bild‑Workflows. Es ist kein gehosteter Dienst, den Sie aufrufen: Sie installieren es in Ihre eigene Anwendung, und es rendert dort. Dieser Beitrag skizziert die Integrationsentscheidungen, ohne sich auf versionsspezifischen Beispielcode zu stützen.

Eine Klarstellung zuerst, weil die beiden Produkte leicht zu verwechseln sind. Doconut.app ist der kostenlose Web‑Betrachter – eine Datei, die in einem Browser‑Tab geöffnet und anschließend gelöscht wird. Es ist nichts, das Sie einbetten. Was Sie einbetten, ist Doconut Viewer, das SDK, und alles unten bezieht sich darauf.

Eingebetteter Dokumentenbetrachter, verbunden mit einem kontrollierten ASP.NET‑Backend

1. Warum Sicherheit und plugin‑freies Rendering für .NET‑Web‑Apps wichtig sind

Moderne Unternehmen behandeln jedes Dokument als potenziellen Datenverlust. Wenn Sie einen Betrachter einbetten, der auf ActiveX, Flash oder einem nativen Client basiert, übernehmen Sie drei Risiken:

Risiko	Auswirkung auf Ihre .NET‑Anwendung	Wie Doconut App das Problem löst
Plugin‑Abhängigkeit	Benutzer müssen ein Browser‑Plugin installieren oder aktivieren, was zu Support‑Tickets und Compliance‑Problemen führt.	Doconut läuft vollständig in HTML5/Canvas und erfordert keine Plugins.
Unverschlüsselter Transport	Dateien werden über HTTP übertragen oder im Klartext gespeichert, was gegen DSGVO, HIPAA oder interne Richtlinien verstößt.	Das SDK läuft innerhalb Ihrer Anwendung, sodass Transport und Speicherung unter der bereits durchgesetzten TLS‑ und Verschlüsselungsrichtlinie bleiben. Doconut fügt keinen zusätzlichen Hop hinzu.
Unkontrollierter Lebenszyklus	Dateien können auf dem Server verweilen und die Angriffsfläche vergrößern.	Die Aufbewahrung liegt in Ihrer Hand, weil die Dokumente Ihre Umgebung nie verlassen. Temporäre Render‑Ausgaben werden dort geschrieben, wo Sie es konfigurieren, und nach Ihrem Zeitplan gelöscht.

Der architektonische Fakt, der zählt, ist, dass das SDK in Ihrer eigenen Umgebung installiert wird und keinerlei Aufrufe an Doconut‑Server tätigt. Es wird nichts zu uns hochgeladen, sodass kein Drittanbieter‑Prozessor in einer Daten‑Map auftaucht und keine Anbieter‑Aufbewahrungs‑Richtlinie mit Ihrer eigenen abgeglichen werden muss.

2. .NET‑Projekt vorbereiten

Verwenden Sie das Paket, die Dokumentation und die Beispiele, die zur gewählten Doconut‑Version des Projekts passen. Die offizielle Doconut‑Downloadseite ist der verlässliche Ausgangspunkt.

Vor der Integration bestätigen Sie die Ziel‑.NET‑Runtime, notieren die Paket‑Version, halten Lizenz‑Konfigurationen außerhalb der Versionskontrolle und beginnen mit repräsentativen Dokumenten. ASP.NET Core, MVC und WebForms besitzen unterschiedliche Anwendungs‑Lebenszyklen, sodass ihre Einrichtung nicht als identisch behandelt werden sollte.

3. Aufbau eines sicheren Upload‑Endpunkts – AES‑256, SSL und automatisches Löschen

Das SDK kann ein Dokument von einem physischen Pfad, einem Stream, einem Byte‑Array, einer Datenbank, einer URL, einem Intranet‑Standort oder einem Cloud‑Anbieter wie S3, Azure Storage, Google Cloud oder Dropbox lesen. Was es niemals lesen sollte, ist ein vom Browser gewählter Pfad. Platzieren Sie eine Autorisierungsprüfung zwischen der Anfrage und dem Dokument, egal woher es stammt. Nachfolgend finden Sie eine gängige Form dieses Endpunkts in ASP.NET Core; dieselben Ideen gelten für MVC und WebForms.

Server‑seitiger Workflow

Akzeptieren der hochgeladenen Datei – Verwenden Sie das Standard-IFormFile (oder HttpPostedFile in WebForms), um das Dokument vom Client zu empfangen.
Verschlüsseln der Datei mit AES‑256 – Vor dem Persistieren des Streams verschlüsseln Sie ihn mit einer bewährten Bibliothek wie System.Security.Cryptography.Aes. Speichern Sie das verschlüsselte Blob an einem sicheren Ort (z. B. Azure Blob Storage mit aktivierter serverseitiger Verschlüsselung oder ein S3‑Bucket mit SSE‑AES256).
Erzeugen einer kurzlebigen signierten URL – Erstellen Sie eine URL, die für einige Minuten gültig ist (z. B. 5 Minuten). Die URL sollte HTTPS sein und ein kryptografisches Token enthalten, das Doconut validieren kann. Die meisten Cloud‑Speicheranbieter bieten eine „pre‑signed URL“-Funktion, die diesen Bedarf deckt.
Rückgabe der signierten URL an den Client – Senden Sie eine JSON‑Antwort, die die URL enthält. Der Client übergibt diese URL an den Doconut‑Viewer.
Planen der automatischen Löschung – Nachdem die signierte URL abgelaufen ist, entfernt ein Hintergrundjob (Hangfire, Azure Functions usw.) das verschlüsselte Blob und stellt sicher, dass die Datei nicht mehr auf dem Server verbleibt.

MVC / WebForms Äquivalente

MVC – Platzieren Sie die gleiche Logik in einer regulären Controller‑Aktion und geben Sie JsonResult zurück.
WebForms – Implementieren Sie einen .ashx‑Handler oder eine Seitenmethode, die dieselben Schritte ausführt: Request.Files[0] empfangen, verschlüsseln, eine pre‑signed URL erzeugen und die JSON‑Antwort schreiben.

Der einzige Unterschied liegt in der Routing‑Syntax; der Sicherheits‑Workflow bleibt identisch.

4. Rendern des Dokuments über das installierte SDK

Behalten Sie den Dokumentzugriff auf dem Server und erzwingen Sie die Autorisierung, bevor Sie eine Datei oder einen Stream verarbeiten. Die genaue Rendering‑ und UI‑Initialisierungssequenz ist versionsspezifisch; folgen Sie der offiziellen Dokumentation, die mit dem installierten Build geliefert wird, anstatt eine nicht verifizierte globale JavaScript‑API zu kopieren.

Warum das für jede .NET‑Variante funktioniert

ASP.NET Core Razor – Die Initialisierung befindet sich in derselben View, die das Upload‑Formular hostet, sodass es nur eine Seite zu berücksichtigen gibt.
MVC – Verwenden Sie @section Scripts, um das gleiche Snippet einzufügen; der Controller gibt JSON zurück, das das $.ajax von MVC verarbeiten kann.
WebForms – Registrieren Sie das Skript mit ClientScript.RegisterStartupScript, nachdem der Upload abgeschlossen ist, und rufen Sie dann launchViewer auf dieselbe Weise auf.

Das Rendering erfolgt auf Ihrem Server, und das ist der Sinn dabei: Der Browser erhält gerenderte Seiten anstelle des Quelldokuments, weshalb ein DWG oder ein PSD auf einem Rechner geöffnet werden kann, der weder AutoCAD noch Photoshop hat. Dimensionieren Sie den Server entsprechend – ein gescannter 300‑Seiten‑PDF ist echte Arbeit, und jetzt übernimmt diese Aufgabe Ihre Ebene.

5. Anpassen des Viewers an Ihr Portal

Unternehmen benötigen den Viewer in der Regel so, dass er wie ein Teil des Produkts aussieht, in das er eingebettet ist, und nicht wie ein Fenster in ein fremdes System. Das Aussehen des Viewers und die Menge der bereitgestellten Steuerelemente sind konfigurierbar, und welche Optionen verfügbar sind, hängt vom installierten Build ab.

Entnehmen Sie die Optionsnamen der Dokumentation, die mit Ihrer Version geliefert wird, und nicht einem Blog‑Beitrag. Viewer‑Konfigurationsoberflächen sind genau die Art von Dingen, die zwischen Releases umbenannt werden, und ein aus einem Artikel, der zwei Versionen alt ist, kopiertes Snippet schlägt fehl und wirkt wie ein Lizenzproblem.

Die Entscheidung, die Sie treffen sollten, bevor Sie die Dokumentation öffnen, ist, welche Steuerelemente jede Rolle sehen soll. Ob ein Benutzer drucken, herunterladen oder nur durch ein Dokument blättern darf, ist eine Berechtigungsfrage, deren Antwort Ihre Anwendung bereits kennt. Konfigurieren Sie den Viewer anhand dieser Antwort, anstatt jedes Steuerelement freizugeben und zu hoffen, dass niemand darauf klickt.

6. Leistung und Skalierbarkeit – die Erfahrung flüssig halten

Das Einbetten eines Viewers in ein stark frequentiertes Portal wirft zwei praktische Probleme auf: Ladezeit und parallel laufende Renderings. Doconut App löst beide sofort, aber Sie können die Leistungsgrenzen mit einigen .NET‑spezifischen Tricks weiter verbessern.

Problem	Was zu tun ist
Erste Seitenlatenz	Das automatische Laden von Seiten lässt den Leser Seite 1 sehen, während der Rest noch vorbereitet wird. Aktivieren Sie die statische Dateikomprimierung (`app.UseResponseCompression()`) und cachen Sie die Client‑Assets.
Wiederholte Aufrufe einer Datei	Ein häufig geöffnetes Dokument kann einmal gerendert und aus dem zwischengespeicherten Output bereitgestellt werden, anstatt bei jeder Anfrage neu gerendert zu werden. Die FAQ behandelt die `.DCN`‑Option genau hierfür.
Rendering‑Kosten	Rendering ist Serverarbeit. Die Reduzierung der Bildauflösung, wo die Detailgenauigkeit nicht kritisch ist, ist der größte Hebel und erfordert eine Konfigurationsänderung statt einer Codeänderung.
Parallelität	Überprüfen Sie Timeout‑ und AutoClose‑Einstellungen unter Last und lesen Sie die Web‑Farm‑Beispiele, bevor Sie annehmen, dass ein einzelner Knoten ausreicht. Begrenzen Sie die Rate des Upload‑Endpunkts.

Messen Sie mit Ihren eigenen Dokumenten. Ein 5 MB‑textbasiertes PDF und ein 5 MB‑Scan desselben Berichts verhalten sich völlig unterschiedlich, und nur eines von beiden erscheint in einem synthetischen Benchmark.

Wichtigste Erkenntnisse

Doconut Viewer ist ein plugin‑freies .NET SDK, das mit ASP.NET Core, MVC und WebForms funktioniert. Ihre Benutzer installieren nichts.
Es wird in Ihrer eigenen Umgebung installiert und ruft keine Doconut‑Server auf, sodass Dokumente innerhalb der von Ihnen bereits kontrollierten Grenze bleiben.
Transportverschlüsselung, Verschlüsselung im Ruhezustand und Aufbewahrung können Sie festlegen, da die Datei Ihre Infrastruktur nie verlässt. Doconut wird nicht zu einem Prozessor in Ihrem Datenmodell.
Der SDK‑Katalog umfasst 75 Dateierweiterungen in 18 Familien — PDF, Office, CAD, Visio, Project, E‑Mail, eBook und Bilder, mit DICOM über sein eigenes Plugin.
Das Rendering erfolgt auf dem Server. Das ermöglicht es einem Browser, eine DWG zu öffnen, und ist zudem der zu dimensionierende Punkt.
Welche Steuerelemente ein Benutzer sieht – Drucken, Herunterladen oder nur Blättern – sollte den Berechtigungen entsprechen, die Ihre Anwendung bereits besitzt.
Nehmen Sie Konfigurationsoptionen aus der Dokumentation Ihrer installierten Version, niemals aus einem Artikel.

Häufige Fragen

Q1: Installiere ich etwas auf dem Server?
A: Ja. Doconut Viewer ist ein .NET SDK, das Sie in Ihre Anwendung installieren — beginnen Sie auf der Download‑Seite und verwenden Sie das Paket und die Dokumentation für die von Ihnen ausgewählte Version. Es gibt keinen gehosteten Endpunkt zum Aufrufen, und es wird nichts von einem Doconut CDN bereitgestellt.

Q2: Wer löscht die Datei nach dem Anzeigen?
A: Sie tun es. Da das Dokument und alle temporären Renderausgaben in Ihrer Umgebung leben, ist die Aufbewahrung eine Einstellung in Ihrer Anwendung und nicht ein Versprechen eines Anbieters. Entscheiden Sie, wo temporäre Dateien geschrieben werden und was sie entfernt, bevor Sie in die Produktion gehen.

Q3: Können Benutzer das Dokument drucken?
A: Drucken ist eine Viewer‑Funktion und kann pro Benutzer gewährt oder verweigert werden. Beachten Sie, dass kontrolliertes Drucken Teil des Viewers selbst ist – es ist nicht eines der vier lizenzierten Plugins, nämlich Annotation, Converter, DICOM und Search.

Q4: Kann es ein Dokument in ein anderes Format konvertieren?
A: Das ist das Converter‑Plugin, separat lizenziert. Anzeigen und Konvertieren sind hier unterschiedliche Produkte, und es ist wichtig, klar zu sein, welches der Workflow tatsächlich benötigt.

Bereit, einen null‑Plugin‑Dokument‑Viewer in Ihre .NET‑Anwendung einzubetten? Beginnen Sie auf der Doconut‑Download‑Seite — die Testlizenz ist kostenlos. Und wenn Sie lediglich heute eine Datei öffnen wollten, erledigt das Doconut.app das in einem Browser‑Tab und löscht sie anschließend.