Doconut Viewer is a .NET document-viewing library designed to place PDF, Office, CAD, image, and other supported document families inside an application. A sound Doconut integration is less about finding the shortest snippet and more about choosing a clean boundary between your application, the viewer, and the browser.
The Doconut documentation hub links to the maintained setup paths for supported .NET project types. Use the guide that matches the version installed in your application, then treat the surrounding page, identity checks, and access workflow as application code that your team owns.
Start with the Integration Boundary
There are three common ways to place a document preview in a product. The right choice depends on who owns navigation, authentication, and viewer lifecycle.
| Pattern | Best fit | Main trade-off |
|---|---|---|
| Application view | A .NET page that renders the viewer beside product controls | Tight integration, but the page and viewer lifecycle are coupled |
| Application-owned iframe | A portal that needs isolation between the host UI and preview route | Clear boundary, but communication must be designed explicitly |
| Framework component around a server route | A React, Angular, or Vue shell backed by a .NET application | Familiar front-end composition, with more lifecycle states to manage |
The iframe pattern does not have to point at a public document URL. It can point at an authenticated route in your own application. That route can verify access and render the viewer page without exposing a storage path to the host page.
Build a Stable, Responsive Preview Surface
Do not reconstruct the viewer markup or initialization from an illustrative blog snippet. Doconut publishes the files, middleware steps, namespaces, and viewer setup appropriate to each supported .NET line. For example, the official .NET 6 or higher setup guide explains the server middleware, viewer object, document options, rendering configuration, and required client assets.
Use those versioned materials to create the viewer, then give its host region a stable width and height in your own layout. Reserve enough space before loading so the surrounding page does not jump, and test the toolbar and first page at the real breakpoints supported by your product.
Before committing to a composition, compare it with the official Doconut live demos. The demos cover multiple .NET and front-end integration styles, including a dedicated iframe example, and help distinguish an officially supported path from a plausible-looking snippet.
Keep Access Decisions on the Server
The host page should never decide whether a user may view a document. Before rendering the preview route, the application should:
- Authenticate the request.
- Authorize the user for the requested document and tenant.
- Resolve the document through a server-controlled identifier.
- Open it through the viewer only after those checks pass.
- Return a generic not-found or forbidden state without leaking storage details.
An opaque identifier improves URL hygiene, but it is not authorization. Apply the same checks to page, thumbnail, search, annotation, export, and print requests that you expose.
Decide How the Host and Viewer Communicate
An application view can call its own components directly. An iframe needs a narrower contract. Define only the events the host genuinely needs, such as:
- Preview ready
- Document failed to open
- Current page changed
- Session expired
- User requested to close the preview
If you use postMessage, validate both event.origin and the message shape. Do not accept wildcard origins in production, and never pass credentials, storage locations, or raw document content through messages.
Treat Browser Restrictions as Defense in Depth
An iframe is not automatically isolated. A sandbox attribute can reduce capabilities, but an overly strict value may also break viewer scripts, downloads, or same-origin behavior. Start from the smallest capability set documented for your integration and test it with your Content Security Policy.
Also review:
frame-ancestorsorX-Frame-Optionsfor the preview routeframe-srcfor the host page- Same-site cookie behavior if the iframe requires a session
- Referrer policy for URLs that contain routing identifiers
- Cache headers for pages that display sensitive material
These controls belong to the surrounding application and infrastructure. A viewer component cannot choose the correct policy for your tenancy and threat model.
Design Loading, Error, and Expiry States
A blank rectangle is not a useful error message. Give the host page explicit states for authorization failure, unsupported input, damaged files, timeouts, and expired sessions. Keep the wording actionable without revealing internal paths or exception details.
For long documents, preserve the viewer container while the first page is prepared. If users can switch documents without leaving the page, cancel stale requests and reset the visible title, page count, and focus before loading the next item.
Accessibility and Keyboard Behavior
Give every iframe a useful title. Make the preview reachable by keyboard, provide a visible way to return focus to the host page, and do not trap focus inside custom overlays. If the viewer has its own keyboard shortcuts, document conflicts with shortcuts used by your product shell.
An accessible fallback can offer a controlled download or an alternate representation when your business rules permit it. Do not add a public file link merely as a fallback.
A Practical Verification Checklist
Before release, verify the complete request path rather than only the initial page load:
- An authorized user can open an allowed document.
- A user from another tenant cannot reuse the preview URL.
- Direct requests to viewer-related endpoints receive the same authorization checks.
- Refresh, back navigation, and session expiry produce understandable states.
- The preview remains usable at supported viewport sizes and zoom levels.
- Browser console errors and failed network requests are visible in monitoring.
- Storage and application logs do not record secrets or full document URLs.
Conclusion
The most maintainable Doconut embed is the one with a small, explicit contract. Let Doconut handle the document-viewing role described in its versioned documentation, while your application owns identity, authorization, routing, retention, browser policy, and user feedback. When you are ready to evaluate the packaged examples locally, use the official Doconut download resources rather than copying source from an unrelated article.