Installation

Add Doconut to your .NET Standard 2.1 project

The base Doconut viewer for .NET Standard ships as one NuGet package that plugs into any ASP.NET Core application. Optional plugins use separate packages. This page installs the base package, confirms your host can consume it, and registers the middleware — the minimum needed before your first render.

Check the host framework first

The library targets netstandard2.1. That is a narrower contract than the previous netstandard2.0 build, and it is the first thing to verify:

HostSupported
.NET Core 3.0 or later, including .NET 5/6/7/8Yes
.NET Framework (any version)No — netstandard2.1 cannot be consumed by .NET Framework

If the application runs on .NET Framework, this is not the right package. Use Doconut.NETFramework, which stays on the previous architecture and receives the same releases. The reference applications shipped with this release target net8.0.

Install the package

bash
dotnet add package Doconut.NETStandard

The unversioned command installs the latest stable release. To reproduce the current 26.8.0 release exactly, pass the version as a separate option:

bash
dotnet add package Doconut.NETStandard --version 26.8.0

Doconut.NETStandard is the package ID. The .26.8.0 suffix belongs to the downloaded Doconut.NETStandard.26.8.0.nupkg filename and is not part of the ID.

The version number is the generation

This matters more here than the package name. Both generations of the .NET Standard library publish under the same package ID, and only the version tells them apart:

VersionTargetAPI
26.7.0 and belownetstandard2.0the previous integration
26.8.0 and abovenetstandard2.1the integration documented here

There is no compatibility shim and no side-by-side package. Bumping the version is the upgrade, and the compiler will report the API differences immediately.

Do not select documentation from the package name alone:

  • new Viewer(_cache, _accessor, …), UnSafeMode, synchronous OpenDocument(...), viewer.InitCache(), UseDoconutWebFarm, and manually copied viewer scripts identify the previous integration;
  • AddDoconut(), UseDoconutResources(), an injected Viewer, and OpenDocumentAsync(...) identify the current integration documented here.

The translated previous setup manual remains available. Use the migration guide to change generations; a package update does not convert startup, viewer lifetime, or browser resources automatically.

Register Doconut

AddDoconut() is the only registration entry point — there is a single overload, and it wires the Viewer service, the license service, and the rendering infrastructure into the DI container.

Two middleware calls complete the setup, and their order matters: UseDoconutResources() must run before UseDoconut(). UseDoconut() is terminal middleware, so calling it first means every request to a /doconut-res asset never reaches the resources handler and 404s. The session wiring is required too — Doconut's default document security validates every page request against ASP.NET session state.

csharp
builder.Services.AddDoconut(options =>
{
    options.LicensePath = "Doconut.Viewer.lic";
});
builder.Services.AddSession(); // Doconut document security rides on ASP.NET session state

app.UseSession();          // call UseSession() before UseDoconut()
app.UseDoconutResources(); // must be registered before UseDoconut()
app.UseDoconut();

Namespaces

The configuration types are no longer spread across four namespaces. In this release almost everything lives in the root Doconut namespace:

csharp
using Doconut;                       // Viewer, DoconutOptions, DocOptions, all format configs
using Doconut.Middleware;            // AddDoconut, UseDoconut, UseDoconutResources
using Doconut.Clouds;                // cloud and file-share configs
using Doconut.Configs.Conversion;    // ConversionTarget

The type names themselves did not change — PdfConfig, WordConfig, ExcelConfig, CssConfig, ScriptConfig and the rest are all still there. If you are moving an existing application, most files need nothing but two deleted using lines; see the migration guide.

All options

DoconutOptions accepts the following settable properties. Every one is optional — the defaults below apply when a property is left unset.

PropertyDefaultDescription
ShowDoconutInfofalseWhen true, a request with no token returns a version banner instead of a 404. Useful as a smoke check; leave off in production.
UnsafeModefalseWhen true, skips the ASP.NET-session security check on page requests. Leave off in production. Note the spelling — the previous library called this UnSafeMode.
MiddlewarePath"/doconut"Coordination value for the page-image endpoint. It is validated, but it does not mount a branch by itself; keep it aligned with the actual UseDoconut() mapping and the client BasePath.
ResourcesPath"/doconut-res"Where the embedded JS/CSS/image resources are served from.
LicensePath"" (empty string)Path to the license file. Empty means fall through to the next source, then auto-search.
LicenseContent"" (empty string)Raw license content — from an environment variable, a secret manager, or a database.
LicenseStreamnullLicense as a stream, read once at startup.
ResetLicensefalseReserved compatibility flag. The license is read during AddDoconut(); restart the app after replacing a license.

License precedence when more than one source is set: LicenseStream beats LicenseContent beats LicensePath beats auto-search — see License Setup.

csharp
builder.Services.AddDoconut(options =>
{
    options.LicensePath     = "Doconut.Viewer.lic";
    options.MiddlewarePath  = "/doconut";     // coordinate with app mapping and client BasePath
    options.ResourcesPath   = "/doconut-res"; // where the viewer's JS/CSS/images are served from
    options.UnsafeMode      = false;          // keep session security on
    options.ShowDoconutInfo = false;
});

Next steps

  • Quick Start — open your first document and render it in the browser.
  • License Setup — where Doconut looks for your license file.

هل كانت هذه الصفحة مفيدة؟