Many developers start by looking for UI component libraries when they need to display documents in a web application. Doconut Viewer is a .NET SDK for adding plugin-free browser viewing to ASP.NET Core, MVC, or classic WebForms projects. Security still depends on the complete application architecture: authentication, authorization, transport, storage, validation, cleanup, patching, and monitoring.
1. Install the Doconut App SDK and Prepare Your .NET Project for Multiple File Formats
1.1 Add the supported package
Use the current package and setup instructions from the official Doconut download page. Record the chosen version and verify that it supports the target .NET runtime.
1.2 Verify the package reference
After installation, confirm the package reference and resolved version in the project file. Keeping versions explicit helps make builds and deployments reproducible.
1.3 Enable HTTPS
Serve the application over HTTPS so uploaded documents are not travelling in clear text on your network. For a Kestrel-hosted app, add an endpoint configuration in appsettings.json:
{
"Kestrel": {
"Endpoints": {
"Https": {
"Url": "
}
}
}
}
If you host on IIS, bind an HTTPS certificate to the site. With HTTPS enabled, the file travels over a secure channel on its way to your own server, which is where the SDK renders it.
Where the security comes from. The SDK runs inside your application, on your infrastructure: it makes no calls out to Doconut servers, so documents never leave your network. That is the property worth designing around. It is not a compliance certificate — the SDK ships no ISO 27001, SOC 2 or HIPAA attestation of its own, and it cannot confer one on your application. What it does is keep the file inside a boundary you already control and already audit.
2. Configure Secure File Uploads and Storage for Document Management
This is the part that is yours rather than the SDK's, and it is worth saying plainly: transport security, encryption at rest, retention and cleanup are decisions your application makes. The SDK renders documents; it is not a storage layer and it does not encrypt your disk for you.
2.1 Register the services
In Startup.cs (or Program.cs on modern .NET), register the Doconut services in the dependency injection container following the documentation for the version you installed. Where the SDK needs a working folder for temporary render output, point it somewhere you control, and make cleanup of that folder your responsibility — a scheduled job or an application-managed lifetime, not an assumption.
2.2 Create the upload endpoint
Implement a controller action that receives an uploaded file, writes it to whatever store your application already uses, and returns a short one‑time token. The token is what the client‑side viewer will use to fetch and render the document. Note that the storing is yours: you hand the SDK the bytes or the path when it is time to render, and it hands you back pages.
2.3 Protect the endpoint
Because the upload endpoint deals with sensitive data, protect it with authentication and role-based authorization (for example, only users in a DocumentViewer role may upload). Validate the extension and the size server-side as well as in the browser, and treat the uploaded bytes as untrusted input.
Do not skip this on the assumption that the SDK covers it. Encryption at rest, key management and orphaned-file cleanup are your application's job. If you need documents encrypted on disk, use the platform facilities you already trust for that — the viewer is not where that belongs.
3. Embed the Viewer Component in ASP.NET Core, MVC, or WebForms
With the backend ready, initialize the viewer using the assets and API documented for the installed Doconut version.
3.1 Add the JavaScript bundle
In your shared layout, include only the viewer resources described by the documentation that matches the installed SDK. Do not assume fixed bundle names or locations across versions.
3.2 Create a Razor view for Core/MVC
Add a view (e.g., Views/Document/View.cshtml) that contains a file input, a container element for the viewer, and a small script that uploads the selected file, receives the secure token, and initializes the Doconut Viewer widget.
The script should:
- Capture the selected file from the
<input type="file">element. - Send the file to the upload endpoint using
fetchorXMLHttpRequest. - When the authorized response arrives, initialize the viewer using the supported API for the installed version.
3.3 WebForms equivalent
In a WebForms page (e.g., DocumentViewer.aspx), place an asp:FileUpload control, a button to trigger the upload, and a <div> that will host the viewer. In the code‑behind, call the Doconut service to store the uploaded file, obtain the token, and register a startup script that calls a JavaScript function (initViewer(token)) to create the viewer instance.
The reason to do it this way: one rendering path serving three .NET UI models, with nothing installed on the end user's machine.
4. Customize the Viewer for Document Management
The viewer renders inside a container in your own page, so the surrounding application is already yours. Beyond that, take the option names and defaults from the documentation for the version you installed rather than from any tutorial, this one included — the configuration surface changes between releases and a hard-coded option name is the thing most likely to break on upgrade.
The things worth deciding up front:
4.1 Which controls the user gets
Decide whether your users should be able to download the original file, or only read the rendered pages. Controlled printing is part of the viewer rather than a separate purchase, so printing rules are a configuration question, not a licensing one.
4.2 Which plugins you actually need
Four are licensed separately, and the list is short enough to be worth memorising: Annotation, Converter, DICOM and Search. Conversion — DOC to PDF and the rest — is the Converter plugin. Text search is the Search plugin. If you need neither, you do not buy either.
4.3 Localisation
If your application is multilingual, check what the installed version offers for viewer UI strings before you design around it.
Why this matters: the viewer should look like part of your product. What it should not do is quietly promise your users capabilities the licence you bought does not include.
5. Test the Integration Across All Supported Formats
Before going live, run a quick sanity check for each file type you expect your users to view. Using Doconut App’s viewer, open a sample file of each format and verify that rendering, navigation, and any specialized tools work as described.
| Format | Test Scenario | Expected Result |
|---|---|---|
| Large, multi‑page report with embedded images | Smooth scrolling, zoom, and accurate color rendering | |
| DOCX | Word document with tables and footnotes | All text, tables, and footnotes visible; no layout shift |
| XLSX | Spreadsheet with charts | Charts render as vector graphics; zoom retains clarity |
| PPTX | Slide deck with animated builds | Every build on a slide renders stacked in one frame — that is expected, not a fault |
| DWG | Technical drawing with layers and external references | Layers toggle, distance and area measurement work; xrefs and SHX fonts are absent because they were never in the file |
| PSD | Layered Photoshop file | The saved composite renders, with hidden layers staying hidden; colours hold on zoom |
| SVG | Vector graphic with gradients | Gradients render smoothly; zoom stays sharp |
| TIFF | High‑resolution scan | Image loads quickly; zoom reveals details |
Test with your users' real files, not with clean samples. The formats that surprise people are the ones whose oddities are in the format itself — a DWG that references four other drawings, a spreadsheet whose stored values were never recalculated, a deck whose fonts were not embedded. The free viewer at Doconut.app runs the same engine, so it is a quick way to see how a specific awkward file comes out before you write any code.
Conclusion
Embedding a plugin-free document viewer comes down to four things: install the SDK, secure your own upload path, render into a container in your page, and configure only what the installed version documents. The viewer's contribution to security is narrow and real — it runs on your servers and sends nothing out. Everything else on that list is your application's, and no SDK can take it over for you.
Ready to evaluate it? Start with the official Doconut download and documentation page, then test the SDK within the same security review applied to the rest of your Windows-based ASP.NET application.