Choosing the Right Doconut SDK: .NET Standard 2.1, .NET 6, or .NET 8
Start with the application host
Choosing a Doconut package begins with the project that will run it. A new .NET 8 web application, an established .NET 6 service, and a library-compatible ASP.NET Core host can all need embedded document viewing, but their framework constraints and upgrade plans differ.
Doconut offers current SDK paths for .NET 8, .NET 6, and compatible hosts that consume the new .NET Standard 2.1 package. The right choice is usually the package that matches the host directly and leaves the least framework ambiguity for the team maintaining the application.
The Doconut Viewer SDK overview is the starting point for product capabilities. Use the framework-specific documentation to make the package decision.
Understand what the three labels mean
.NET 8 and .NET 6 are application targets. A web application can target one of these runtimes and select the matching Doconut package.
.NET Standard 2.1 is different: it defines a library API contract that compatible .NET hosts can consume. Doconut 26.8.0 introduces the current Doconut.NETStandard generation for applications targeting .NET Core 3.0 or later, including .NET 5 through .NET 8. It cannot be consumed by .NET Framework.
That distinction keeps the decision grounded. Do not choose .NET Standard 2.1 because it sounds more general; choose it when its contract is the appropriate fit for the host and solution structure.
A practical selection table
| Application situation | Doconut path to evaluate | Why |
|---|---|---|
| New application targeting .NET 8 | Doconut.NET8 | Direct match for current .NET development and the complete .NET 8 documentation path. |
| Existing application that must remain on .NET 6 | Doconut.NET6 | Keeps the host target while providing the current dependency-injection, middleware, async-session, and optional distributed model. |
| Compatible ASP.NET Core host where the .NET Standard contract is required | Doconut.NETStandard 26.8.0+ | Targets .NET Standard 2.1 and exposes the current Doconut integration for supported hosts. |
| Existing Doconut.NETStandard 26.7.0 or earlier integration | Plan a migration before selecting 26.8.0+ | The package ID stays the same, but the target and API generation change. |
| Application targeting .NET Framework | Doconut.NETFramework | .NET Framework cannot consume .NET Standard 2.1. |
This table narrows the first decision. Licensing, optional plugins, document formats, deployment design, and upgrade effort still need separate validation.
Choose Doconut.NET8 for new .NET 8 applications
For a new .NET 8 application, the dedicated package is the clearest choice to evaluate. The .NET 8 Viewer page describes the current model based on dependency injection, middleware-served resources, asynchronous document sessions, and optional distributed workflows.
A direct runtime match also makes documentation easier to follow. Installation, configuration, troubleshooting, plugins, and samples can all be assessed within one framework-specific path.
Before adoption, test the document formats and optional features the product actually needs. A package match does not replace application-level decisions about authentication, authorization, storage, retention, monitoring, and resource limits.
Choose Doconut.NET6 when the host must stay on .NET 6
An established application may have dependencies or support commitments that keep it on .NET 6. The updated .NET 6 Viewer lets the application retain that target while moving to Doconut’s current integration architecture.
This is useful when a runtime upgrade and a document-viewer migration should not happen in the same release. The team can modernize viewer registration, resource delivery, asynchronous opening, and document sessions while keeping the host framework stable.
Check whether the existing project uses the classic or updated Doconut .NET 6 integration. Package names alone may not reveal the generation. The official migration documentation identifies the API signatures and hosting patterns that distinguish them.
Choose Doconut.NETStandard when the contract fits the solution
The new .NET Standard 2.1 installation guide defines the compatibility boundary. It supports .NET Core 3.0 and later hosts, including .NET 5, 6, 7, and 8, and excludes .NET Framework.
This path can make sense when the solution specifically requires the .NET Standard library contract. Version selection is critical: Doconut.NETStandard 26.7.0 and earlier targets .NET Standard 2.0 and uses the previous integration, while 26.8.0 and later targets .NET Standard 2.1 with the current API.
If the application already uses the older package generation, consult the .NET Standard migration guide before updating. The change affects more than compilation: startup, viewer lifetime, resource routing, document opening, licensing, plugins, and distributed publishing may need attention.
Compare the complete application impact
A small proof of concept should answer more than “does the package install?” Evaluate:
- Host compatibility: Confirm the application target and every project that references the viewer package.
- Integration generation: Identify current or classic registration, viewer creation, and document-opening patterns.
- Document coverage: Test representative PDF, Office, CAD, image, email, or medical files required by the product.
- Plugin needs: Validate Search, Annotation, Converter, or DICOM capabilities individually when they belong to the workflow.
- Operational model: Test session lifetime, caching, resource delivery, cleanup, and any single-node or distributed design.
- Upgrade effort: Separate framework changes from Doconut changes so failures are easier to diagnose.
- Application controls: Verify access, storage, retention, and delivery behavior in the surrounding system.
Record the package version and framework target alongside each result. That prevents a successful test against one SDK path from being mistaken for evidence about another.
Make the framework choice explicit
A good architecture note can be brief: state the application target, selected Doconut package and version, required plugins, deployment model, and the documentation path used during implementation. That decision record helps later upgrades begin from facts rather than package-name assumptions.
For new .NET 8 development, begin with the dedicated .NET 8 SDK. For an application staying on .NET 6, evaluate the updated .NET 6 package. Use Doconut.NETStandard 26.8.0+ when the .NET Standard 2.1 contract is the right fit for a compatible host, and keep .NET Framework applications on their dedicated package path.
Review the Doconut documentation hub and download a trial to test the selected path with your own application and documents.