Previous integration

Use this section when an existing .NET Standard application still constructs Viewer manually, passes options to the middleware, coordinates a web farm through a shared folder, or copies the viewer scripts into the application. That architecture remains documented for customers who have not migrated.

The package version identifies the generation

The package ID alone is not enough. Both generations publish as Doconut.NETStandard:

Check the version in the project file, the lock file, or the cached .nupkg before you choose a manual. A package reference that just says Doconut.NETStandard tells you nothing about which API the code is written against.

Identify the previous integration

The application is using the previous integration when it contains one or more of these signatures:

var viewer = new Viewer(_cache, _accessor);
var viewer = new Viewer(_cache, _accessor, licenseFilePath);

var token = viewer.OpenDocument(path, config, documentOptions);
viewer.InitCache();

appBranch.UseDoconut(new DoconutOptions { UnSafeMode = false, ShowDoconutInfo = false });

appBranch.UseDoconutWebFarm(new WebFarmOptions { Path = sharedFolder });

Viewer.DoconutLicense(licenseStream);
Viewer.SetLicensePlugin(pluginLicenseStream);

var converter = viewer.Converter.GetConverter();

Its using block is another reliable signal — the configuration types were spread across several namespaces:

using Doconut.Configs;
using Doconut.Configs.View;
using Doconut.Configs.Cloud;
using Doconut.Models;

Previous pages also commonly load application-managed copies of:

docViewer.js
documentLinks.js
docViewer.UI.js

and declare viewer callbacks as globals named after the container id, such as ctlDoc_OnViewerReady().

The current integration is instead identified by AddDoconut(), UseDoconutResources(), UseDoconut() with no arguments, an injected Viewer, OpenDocumentAsync(), and the flattened Doconut namespace.

Open the preserved manual

The translated historic manual remains at Legacy .NET Standard setup. Its URL has not been redirected or replaced, because it describes a real integration generation that existing applications still use.

Do not combine snippets from that manual with the current AddDoconut() documentation. Viewer construction, middleware routing, licenses, resources, conversion, web-farm coordination, and session ownership are all different.

Plan a migration

Use Migrate to .NET Standard 2.1 for the verified mapping from manual construction and synchronous document opening to DI, current middleware, async sessions, generated resources, distributed publishing, and capability-gated plugins.

Two things deserve attention before you start:

• The host framework. netstandard2.1 requires .NET Core 3.0 or later. A .NET Framework host cannot consume the current package at all.
• The client-side changes. Two of them fail silently — the server keeps working and the browser console stays empty. They are covered in the migration guide.

Keep the previous deployment intact until the current application passes its document, license, Search, Annotation, Converter, DICOM, security, and rollback tests.