Installation

Doconut.NETFramework hostet den Doconut-Viewer in einer klassischen ASP.NET-Anwendung auf .NET Framework 4.7.2 — IIS oder IIS Express, MVC 5 oder Web Forms. Die Einrichtung besteht aus drei Teilen: dem NuGet-Paket, zwei Registrierungen in Web.config und einem Aufruf in Global.asax. Diese Seite behandelt alle drei; Schnellstart legt dann ein Dokument auf einer Seite ab.

Voraussetzungen

• Das Webprojekt zielt auf .NET Framework 4.7.2 oder höher ab. Ein 4.7-Projekt kann dieses Paket nicht verwenden; richten Sie es zuerst neu aus.
• Die Site läuft in der integrierten Pipeline (Standard für IIS- und IIS Express-Anwendungspools).

Diese Seite behandelt Doconut.NETFramework 26.9.0 und neuer. Versionen 26.8.0 und früher zielten auf .NET Framework 4.7 mit einer anderen API; diese Linie ist eingestellt. Das Aktualisieren einer bestehenden Anwendung über diese Grenze hinweg wird in Migration behandelt.

Paket installieren

Aus der Package Manager Console:

Install-Package Doconut.NETFramework

Oder in einem SDK‑basierten Projekt:

dotnet add package Doconut.NETFramework

Die Rendering‑Engine ist im Paket eingebettet: Es gibt keine separate Engine‑Assembly zum Referenzieren, Kopieren oder Bereitstellen. Optionale Funktionen werden als eigene Pakete ausgeliefert — zum Beispiel Doconut.NETFramework.Converter und Doconut.NETFramework.Dicom — und jedes benötigt eine Lizenz, die es gewährt (siehe Plug-in-System).

Web.config konfigurieren

Doconut bedient zwei Arten von Anfragen, und IIS leitet beide über Web.config weiter:

• DocImage.axd — die Seite des Viewers, Miniaturbild, Suche und Annotations-Endpunkt, bereitgestellt von Doconut.DocImageHandler.
• /doconut-res/* — die eigenen Skripte, Stylesheets und Icons des Viewers, eingebettet in die Assembly und bereitgestellt von Doconut.DoconutResourceModule.

Fügen Sie beide hinzu, zusammen mit den Einstellungen, von denen sie abhängen:

<configuration>
  <system.web>
    <!-- MVC 5 only: Razor compiles views at run time and needs the netstandard facade. -->
    <compilation targetFramework="4.7.2">
      <assemblies>
        <add assembly="netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" />
      </assemblies>
    </compilation>
    <!-- maxRequestLength is in KILOBYTES: 200 MB. -->
    <httpRuntime targetFramework="4.7.2" maxRequestLength="204800" />
    <!-- Read .cshtml and .aspx files as UTF-8, not as the server's ANSI code page. -->
    <globalization fileEncoding="utf-8" requestEncoding="utf-8" responseEncoding="utf-8" />
  </system.web>
  <system.webServer>
    <security>
      <requestFiltering>
        <!-- maxAllowedContentLength is in BYTES: the same 200 MB. -->
        <requestLimits maxAllowedContentLength="209715200" />
      </requestFiltering>
    </security>
    <modules runAllManagedModulesForAllRequests="true">
      <add name="DoconutResourceModule" type="Doconut.DoconutResourceModule, Doconut" />
    </modules>
    <handlers>
      <add name="DocImage" verb="GET,HEAD,POST" path="DocImage.axd"
           type="Doconut.DocImageHandler, Doconut" />
    </handlers>
  </system.webServer>
</configuration>

Jede Zeile verhindert einen Fehler, der keine Ausnahme auslöst:

• verb="GET,HEAD,POST" — HEAD beibehalten. Der Viewer sendet eine HEAD‑Anfrage für Seite 1, um animierte Bilder zu erkennen. Ohne dieses Verb antwortet IIS mit 404, bevor der Handler ausgeführt wird: Dokumente werden zwar angezeigt, aber die Animationserkennung funktioniert nie und die Browser‑Konsole füllt sich mit 404‑Fehlern.
• runAllManagedModulesForAllRequests="true" — /doconut-res/*.js, .css und .png sehen aus wie statische Dateien, und IIS würde sie an seinen statischen Datei‑Handler übergeben, bevor das Ressourcen‑Modul sie sieht. Das Ergebnis ist ein Viewer ohne Skripte oder Icons.
• <globalization fileEncoding="utf-8"> — Seiten‑Dateien, die als UTF‑8 ohne Byte‑Order‑Mark gespeichert sind, werden sonst mit der ANSI‑Code‑Seite des Servers gelesen, sodass jedes Nicht‑ASCII‑Zeichen doppelt kodiert im Browser ankommt (ein Gedankenstrich erscheint als —). Die Datei ist auf dem Datenträger korrekt, und die Seite deklariert weiterhin <meta charset="utf-8">.
• Die netstandard‑Assembly (MVC 5) — Razor kompiliert Views, wenn sie erstmals angefordert werden, mit einer eigenen Referenzliste, die diese Fassade nicht enthält. Eine View, die etwas Dynamisches über einen einfachen Member‑Zugriff hinaus tut, schlägt dann mit CS0012 fehl und liefert ein leeres 500, und nur die Seiten, die dies auslösen, schlagen fehl. Der Compiler‑Fehler erscheint nur im Windows‑Ereignis‑Log (Quelle ASP.NET). Web‑Forms‑Anwendungen benötigen diese Zeile nicht.
• Upload‑Grenzen — ASP.NET liest den gesamten Anforderungskörper, bevor ein Handler ausgeführt wird, sodass ein Upload über diesen Grenzen von IIS mit einer eigenen Fehlermeldungsseite abgelehnt wird. Halten Sie maxRequestLength (Kilobytes) und maxAllowedContentLength (Bytes) synchron und über dem größten Datei‑Upload Ihrer Benutzer.

Zwei weitere Einstellungen sind wichtig, und beide sind in der Regel bereits korrekt:

• Session‑State bleibt aktiv. Standardmäßig wird eine Seite nur an die ASP.NET‑Session ausgeliefert, die das Dokument geöffnet hat, daher darf die Site nicht <sessionState mode="Off" /> setzen. Siehe Sitzungen & Sicherheit.
• Binding‑Redirects. Behalten Sie die <runtime>‑Binding‑Redirects, die NuGet in Web.config schreibt. In einem SDK‑basierten Projekt kopieren Sie sie aus der erzeugten bin\<YourApp>.dll.config, da klassisches ASP.NET Redirects nur aus Web.config liest. Ein Redirect, der eine Version nennt, die im bin\‑Verzeichnis fehlt, stoppt die gesamte Anwendung beim Start mit einem leeren 500.

Doconut in Global.asax registrieren

Es gibt keinen Builder und keine Middleware‑Pipeline in System.Web. Doconut wird einmal pro Worker‑Prozess durch DoconutHost.Initialize in Application_Start zusammengesetzt und durch DoconutHost.Shutdown in Application_End wieder freigegeben:

// Global.asax.cs
protected void Application_Start()
{
    Doconut.DoconutHost.Initialize(options =>
    {
        options.LicensePath = HostingEnvironment.MapPath("~/wwwroot/Doconut.Viewer.lic");
    });
}

protected void Application_End()
{
    Doconut.DoconutHost.Shutdown();
}

DoconutHost.Initialize erstellt die Dienste, den Handler, das Ressourcenmodul und den von Ihnen genutzten eigenen Code. Ihr Code greift über DoconutHost.Services darauf zu (siehe DoconutHost). Nur der erste Aufruf konfiguriert etwas; ein zweiter Aufruf wird ignoriert. In einer MVC‑Anwendung sollten die beiden Doconut‑Pfade zudem aus dem Routing ausgeschlossen werden — Schnellstart zeigt das vollständige Application_Start.

Alle Optionen

DoconutOptions akzeptiert die folgenden einstellbaren Eigenschaften. Jede ist optional.

Wenn mehr als eine Lizenzquelle angegeben ist, hat LicenseStream Vorrang vor LicenseContent, das Vorrang vor LicensePath hat, das wiederum Vorrang vor der automatischen Erkennung hat — siehe Lizenz‑Einrichtung.

Doconut.DoconutHost.Initialize(options =>
{
    options.LicensePath     = HostingEnvironment.MapPath("~/wwwroot/Doconut.Viewer.lic");
    options.ResourcesPath   = "/doconut-res"; // wo die JS/CSS/Bilder des Viewers bereitgestellt werden
    options.UnsafeMode      = false;          // Sitzungs­sicherheit beibehalten
    options.ShowDoconutInfo = false;
});
// Der Seitenendpunkt ist hier keine Option: Er ist der in Web.config deklarierte DocImage.axd‑Handler.

Nächste Schritte

• Schnellstart — öffnen Sie ein Dokument und rendern Sie es im Browser, in MVC 5 oder Web Forms.
• Lizenz‑Einrichtung — wo Doconut nach Ihrer Lizenzdatei sucht.