Doconut wird registriert wie alles andere in ASP.NET Core: ein Service im Container und Middleware in der Pipeline. Es erbt Ihre Authentifizierung, Ihr Logging, Ihren DI‑Graphen und Ihre Bereitstellungsgeschichte, weil es innerhalb davon läuft und nicht daneben.
Das Problem
Die meisten Dokumentenbetrachter kommen als separater Service. Das bedeutet eine zweite Bereitstellungseinheit, ein zweites Satz von Anmeldeinformationen, einen Netzwerk-Hops, den Ihre Dokumente nun durchlaufen, und ein zweites Thema, über das man um 2 Uhr morgens jemanden benachrichtigen muss.
Doconut ist eine Bibliothek. AddDoconut() fügt sie Ihrer Service‑Collection hinzu; UseDoconut() fügt sie Ihrer Pipeline hinzu. Sie läuft unter Ihrer Prozessidentität, sieht Ihre Konfiguration, schreibt in Ihren Logger und wird von dem, was Ihre Anwendung bereits bereitstellt, bereitgestellt.
Die praktische Konsequenz ist, dass die Autorisierung dort bleibt, wo sie hingehört. Sie rufen OpenDocumentAsync() nach Ihrer eigenen Berechtigungsprüfung auf, und der Betrachter kann nur das rendern, was Sie ihm übergeben haben.
Funktionen
Der Betrachter ist nicht an einen Hosting‑Stil gebunden. Rendern Sie das Mount‑Div aus einer Razor‑View oder einer statischen Seite und öffnen Sie das Dokument aus einer Controller‑Aktion, einem Page‑Handler oder einem zugeordneten Endpunkt.
Da die Endpunkte in Ihrer Pipeline leben, funktioniert [Authorize] wie immer. Es gibt kein zweites Identitätssystem, mit dem man federieren müsste.
Die Dokumentensicherheit basiert auf dem ASP.NET‑Sitzungszustand, weshalb UseSession() vor UseDoconut() registriert werden muss. Das bedeutet, dass die Vorstellung des Betrachters, wer Sie sind, dieselbe ist wie die der Anwendung.
Mehrere Knoten hinter einem Load Balancer teilen den Render‑Cache, sodass eine auf einem Knoten gestartete Sitzung weiter funktioniert, wenn die nächste Anfrage woanders landet.
IIS, Kestrel oder ein Container‑Image, das Sie selbst erstellen. An der Integration ändert sich nichts zwischen ihnen, außer wo die Lizenzdatei eingebunden wird.
Mit dem Converter‑Plugin läuft DocumentConverter.ConvertAsync() im selben Prozess – kein zweiter Service, kein temporäres Hochladen, keine Rundreise.
Integration
UserMayRead und ResolvePath sind Ihr eigener Code. Das ist der Punkt: Doconut erfährt nie, welche Dokumente existieren oder wer sie sehen darf.
Unterstützte Plattformen
// Program.cs
builder.Services.AddDoconut(options =>
{
options.LicensePath = "Doconut.Viewer.lic";
});
builder.Services.AddSession(); // document security rides on session state
var app = builder.Build();
app.UseSession(); // call UseSession() before UseDoconut()
app.UseDoconutResources(); // must be registered before UseDoconut()
app.UseDoconut();
// Open the document server-side, behind your own authorization
app.MapPost("/api/open", async (Viewer viewer, HttpContext ctx, string documentId) =>
{
if (!await ctx.UserMayRead(documentId))
return Results.Forbid();
// The token is opaque — hand it to the widget, never log or persist it.
string token = await viewer.OpenDocumentAsync(ResolvePath(documentId));
return Results.Ok(new { token });
}).RequireAuthorization();Details
Ja. Beide werden unterstützt und verwenden dieselbe DI‑plus‑Middleware‑Architektur. Es gibt für jede Version eigene Seiten, falls Sie versionsspezifische Details benötigen.
Nein, und das ist beabsichtigt. Die Integration besteht immer aus Middleware plus dem JavaScript‑Widget, wodurch dieselbe Integration über Razor Pages, MVC, Web Forms und Blazor hinweg gültig bleibt, anstatt sich in vier Teile zu fragmentieren.
Web‑Farm‑ und verteilte Bereitstellungen werden über einen gemeinsamen Render‑Cache unterstützt. Ein auf einem Knoten geöffnetes Dokument bleibt lesbar, wenn nachfolgende Anfragen einen anderen Knoten erreichen.
Nein. Das Rendering ist nativ – es gibt keine Office‑Interop, kein headless Word und keine COM‑Automatisierung, die betreut werden muss.
Blazor
Serverseitiges Rendering mit einem Widget, das sauber in den Blazor-Interop-Lebenszyklus eingebunden wird — Server und WebAssembly werden beide unterstützt.
BlazorWord
Natives DOC/DOCX/RTF/ODT-Rendering ohne Office-Installation, ohne COM-Interop und ohne serverseitige Automatisierung.
WordEine temporäre Lizenz lässt sich in wenigen Minuten anfordern und läuft vollständig auf Ihrem eigenen Rechner. Die wichtigen Dateien sind bereits die, die Ihren aktuellen Viewer zum Absturz bringen.