Sie haben Dateien auf dieser Seite abgelegt, um sie zu lesen. Irgendwann fragt jemand, ob dasselbe auch innerhalb der Anwendung, an der Sie arbeiten, möglich ist – eine Aktenakte, ein Anspruch, eine Zeichnung, die in Ihrer eigenen Seite geöffnet wird, anstatt heruntergeladen zu werden. Das ist möglich, und die Entscheidung ist einfacher, als sie scheint, weil nur eine Sache wirklich geändert wird.
Die eine Sache, die sich ändert: wohin die Datei geht
Hier laden Sie ein Dokument zu uns hoch, es wird gerendert und beim Schließen gelöscht. Das ist das richtige Vorgehen für eine Datei, die Ihnen einmal zugesandt wurde und die Sie jetzt lesen möchten.
Es ist das falsche Vorgehen für ein Dokument, das Sie nicht verschieben dürfen. Eine Patientenakte, ein unterschriebener Vertrag, eine Zeichnung unter Geheimhaltungsvereinbarung – diese dürfen Ihre Infrastruktur nicht verlassen, und kein Versprechen über die Löschung löst das Problem, weil die Datei bereits übertragen wurde. Das Einbetten des Renderers kehrt das Verfahren um: Das Dokument wird von Ihrem Server innerhalb Ihres Netzwerks geöffnet, und was den Browser erreicht, ist eine Darstellung. Die Datei bewegt sich nie.
Das ist der Grund für das Einbetten. Alles andere ist Detail.
Es ist eine Komponente, kein Widget
Der Teil, den die Leute zuerst missverstehen: Das ist kein JavaScript, das die Datei im Browser öffnet. Es ist eine native .NET-Komponente, die Sie in Ihrem Projekt referenzieren, und das Rendering erfolgt serverseitig. Ihre Seite erhält das Ergebnis.
Zwei Konsequenzen folgen. Die gute: Der Browser installiert nichts – kein Plugin, kein ActiveX, kein Reader – sodass es sowohl auf einem gesperrten Desktop als auch auf einem Telefon gleich funktioniert. Die zu planende: Ihr Server erledigt die Arbeit, sodass ein 200‑seitiges PDF und eine 40 MB‑Zeichnung nicht dieselbe Anfrage sind. Dimensionieren Sie die Maschine für die größte Datei, die Sie akzeptieren, und verweigern Sie alles Größere beim Upload.
Was Sie vor dem Start entscheiden müssen
Drei Fragen, und keine davon betrifft den Betrachter:
- Woher kommen die Dokumente – eine Datenbank, ein Dateifreigabe, Blob‑Speicher?
- Wer darf dieses sehen, und erzwingt die URL des Betrachters das oder geht man einfach davon aus? Ein Rendering‑Endpunkt, der jedem mit der Dokument‑ID antwortet, ist das klassische Sicherheitsloch.
- Was passiert mit den temporären Dateien, die das Rendering erzeugt, und wann.
Beantworten Sie diese und die Integration selbst ist kurz. Lassen Sie sie für später, und Sie werden versuchen, nachträglich Autorisierung auf einen bereits funktionierenden Betrachter anzuwenden, was schlechter ist.
Wo es läuft
.NET Framework 4.0 und höher sowie .NET Standard 2.0 und höher – also WebForms, MVC, ASP.NET Core, Blazor Server und Linux‑Container. Office muss nicht auf dem Server installiert sein; der Renderer liest die Formate direkt.
Wenn Sie heute nur eine Datei lesen wollten, ist das, wofür der PDF‑Betrachter und die übrigen Betrachter hier gedacht sind. Wenn es die Anwendung ist, an die Sie denken, finden Sie die Komponente, ihre Pakete und ihre API‑Dokumentation unter Doconut.com.