You can embed a plugin‑free document viewer into an ASP.NET Core, MVC, or WebForms application without asking a single user to install anything. Enterprises that serve contracts, drawings, or design assets need a viewer that respects corporate security policies and never forces users to install legacy browser plugins. Doconut provides a .NET document viewer SDK for browser-based PDF, Office, CAD, email, and image workflows. It is not a hosted service you call: you install it into your own application, and it renders there. This post outlines the integration decisions without relying on version-specific sample code.
One clarification first, because the two products are easy to confuse. Doconut.app is the free web viewer — one file, opened in a browser tab, deleted afterwards. It is not something you embed. What you embed is Doconut Viewer, the SDK, and everything below is about that.
1. Why security and zero‑plugin rendering matter for .NET web apps
Modern enterprises treat every document as a potential data leak. When you embed a viewer that relies on ActiveX, Flash, or a native client, you inherit three risks:
| Risk | Impact on your .NET application | How Doconut App eliminates it |
|---|---|---|
| Plugin dependency | Users must install or enable a browser plugin, leading to support tickets and compliance headaches. | Doconut runs entirely in HTML5/Canvas, requiring zero plugins. |
| Unencrypted transit | Files travel over HTTP or are stored in plain text, violating GDPR, HIPAA, or internal policies. | The SDK runs inside your application, so transport and storage stay under the TLS and encryption policy you already enforce. Doconut adds no new hop. |
| Uncontrolled lifecycle | Files may linger on the server, increasing breach surface. | Retention is yours to set, because the documents never leave your environment. Temporary render output is written where you configure it, and cleaned up on your schedule. |
The architectural fact that matters is that the SDK is installed in your own environment and makes no calls to Doconut servers. Nothing is uploaded to us, so there is no third‑party processor to add to a data map and no vendor retention policy to reconcile with your own.
2. Prepare the .NET project
Use the package, documentation, and examples that match the Doconut version selected for the project. The official Doconut download page is the reliable starting point.
Before integration, confirm the target .NET runtime, record the package version, keep license configuration outside source control, and begin with representative documents. ASP.NET Core, MVC, and WebForms have different application lifecycles, so their setup should not be treated as identical.
3. Building a secure upload endpoint – AES‑256, SSL, and auto‑delete
The SDK can read a document from a physical path, a stream, a byte array, a database, a URL, an intranet location, or a cloud provider such as S3, Azure Storage, Google Cloud or Dropbox. What it should never read is a path chosen by the browser. Put an authorization check between the request and the document, whatever the source. Below is one common shape for that endpoint in ASP.NET Core; the same ideas apply to MVC and WebForms.
Server‑side workflow
- Accept the uploaded file – Use the standard
IFormFile(orHttpPostedFilein WebForms) to receive the document from the client. - Encrypt the file with AES‑256 – Before persisting the stream, encrypt it using a proven library such as
System.Security.Cryptography.Aes. Store the encrypted blob in a secure location (e.g., Azure Blob Storage with server‑side encryption enabled, or an S3 bucket with SSE‑AES256). - Generate a short‑lived signed URL – Create a URL that is valid for a few minutes (e.g., 5 minutes). The URL should be HTTPS and include a cryptographic token that Doconut can validate. Most cloud storage providers offer a “pre‑signed URL” feature that fits this need.
- Return the signed URL to the client – Send a JSON response containing the URL. The client will hand this URL to the Doconut viewer.
- Schedule auto‑deletion – After the signed URL expires, a background job (Hangfire, Azure Functions, etc.) removes the encrypted blob, guaranteeing that the file does not remain on the server.
MVC / WebForms equivalents
- MVC – Place the same logic inside a regular controller action and return
JsonResult. - WebForms – Implement an
.ashxhandler or a page method that follows the same steps: receiveRequest.Files[0], encrypt, generate a pre‑signed URL, and write the JSON response.
The only difference is the routing syntax; the security workflow remains identical.
4. Render the document through the installed SDK
Keep document access on the server and enforce authorization before processing a file or stream. The exact rendering and UI initialization sequence is version-specific; follow the official documentation shipped with the installed build rather than copying an unverified global JavaScript API.
Why this works for every .NET flavor
- ASP.NET Core Razor – The initialization lives in the same view that hosts the upload form, so there is one page to reason about.
- MVC – Use
@section Scriptsto inject the same snippet; the controller returns JSON that MVC’s$.ajaxcan consume. - WebForms – Register the script with
ClientScript.RegisterStartupScriptafter the upload completes, then calllaunchViewerthe same way.
Rendering happens on your server, and that is the point of it: the browser receives rendered pages rather than the source document, which is why a DWG or a PSD opens on a machine that has neither AutoCAD nor Photoshop. Size the server accordingly — a scanned 300‑page PDF is real work, and it is now your tier doing it.
5. Customizing the viewer to match your portal
Enterprises usually need the viewer to look like part of the product it sits in, rather than a window into somebody else's. The viewer's appearance and the set of controls it exposes are configurable, and which options exist depends on the build you installed.
Take those option names from the documentation shipped with your version rather than from a blog post. Viewer configuration surfaces are exactly the sort of thing that gets renamed between releases, and a snippet copied from an article two versions old fails in a way that looks like a licensing problem.
The decision worth making before you open that documentation is which controls each role should see. Whether a user can print, or download, or only page through a document is a permission question your application already knows the answer to. Configure the viewer from that answer, instead of exposing every control and hoping nobody clicks.
6. Performance and scalability – keep the experience snappy
Embedding a viewer in a high‑traffic portal raises two practical concerns: load time and concurrent rendering. Doconut App addresses both out of the box, but you can reinforce the performance envelope with a few .NET‑specific tricks.
| Concern | What to do about it |
|---|---|
| First page latency | Page auto‑loading lets the reader see page one while the rest is still being prepared. Enable static file compression (app.UseResponseCompression()) and cache the client assets. |
| Repeated views of one file | A frequently opened document can be rendered once and served from cached output instead of re‑rendered per request. The FAQ covers the .DCN option for exactly this. |
| Rendering cost | Rendering is server work. Lowering image resolution where fidelity is not critical is the largest single lever, and it is a configuration change rather than a code change. |
| Concurrency | Review timeout and AutoClose settings under load, and read the web farm examples before assuming one node will do. Rate‑limit the upload endpoint. |
Measure with your own documents. A 5 MB text‑based PDF and a 5 MB scan of the same report behave nothing alike, and only one of them shows up in a synthetic benchmark.
Key Takeaways
- Doconut Viewer is a plugin‑free .NET SDK that works with ASP.NET Core, MVC, and WebForms. Your users install nothing.
- It is installed in your own environment and makes no calls to Doconut servers, so documents stay inside the boundary you already control.
- Transport security, encryption at rest and retention are yours to set, because the file never leaves your infrastructure. Doconut does not become a processor in your data map.
- The SDK catalogue is 75 file extensions across 18 families — PDF, Office, CAD, Visio, Project, email, eBook and images, with DICOM through its own plugin.
- Rendering happens on the server. That is what lets a browser open a DWG, and it is also the line item to size for.
- Which controls a user sees — print, download, or paging only — should follow the permissions your application already holds.
- Take configuration option names from the documentation for your installed version, never from an article.
Common Questions
Q1: Do I install something on the server? A: Yes. Doconut Viewer is a .NET SDK you install into your application — start from the download page and use the package and documentation for the version you selected. There is no hosted endpoint to call, and nothing is served from a Doconut CDN.
Q2: Who deletes the file after viewing? A: You do. Because the document and any temporary render output live in your environment, retention is a setting in your application rather than a promise from a vendor. Decide where temporary files are written, and what removes them, before you go to production.
Q3: Can users print the document? A: Printing is a viewer capability, and it can be granted or withheld per user. Note that controlled printing is part of the viewer itself — it is not one of the four licensed plugins, which are Annotation, Converter, DICOM and Search.
Q4: Can it convert a document to another format? A: That is the Converter plugin, licensed separately. Viewing and converting are different products here, and it is worth being clear about which one the workflow actually needs.
Ready to embed a zero‑plugin document viewer in your .NET application? Start from the Doconut download page — the trial licence is free. And if what you actually needed was to open one file today, Doconut.app does that in a browser tab, and deletes it afterwards.