È possibile incorporare un visualizzatore di documenti senza plugin in un'applicazione ASP.NET Core, MVC o WebForms senza chiedere a nessun utente di installare nulla.
Le aziende che forniscono contratti, disegni o risorse di design hanno bisogno di un visualizzatore che rispetti le politiche di sicurezza aziendali e che non costringa gli utenti a installare plugin obsoleti del browser. Doconut fornisce un SDK .NET per visualizzatore di documenti basato su browser per PDF, Office, CAD, email e flussi di lavoro con immagini. Non è un servizio hosted da chiamare: lo installi nella tua applicazione e il rendering avviene lì. Questo post descrive le decisioni di integrazione senza fare affidamento su codice di esempio legato a versioni specifiche.

Una prima precisazione, perché i due prodotti sono facili da confondere. Doconut.app è il visualizzatore web gratuito — un singolo file, aperto in una scheda del browser, cancellato successivamente. Non è qualcosa che si incorpora. Ciò che si incorpora è Doconut Viewer, l'SDK, e tutto ciò che segue riguarda questo.

Visualizzatore di documenti incorporato collegato a un backend ASP.NET controllato

1. Perché la sicurezza e il rendering senza plugin sono importanti per le app web .NET

Le moderne imprese trattano ogni documento come una potenziale perdita di dati. Quando si incorpora un visualizzatore che si basa su ActiveX, Flash o un client nativo, si ereditano tre rischi:

Rischio	Impatto sulla tua applicazione .NET	Come Doconut App lo elimina
Dipendenza da plugin	Gli utenti devono installare o abilitare un plugin del browser, generando ticket di supporto e problemi di conformità.	Doconut funziona interamente in HTML5/Canvas, richiedendo zero plugin.
Trasporto non crittografato	I file viaggiano su HTTP o sono memorizzati in chiaro, violando GDPR, HIPAA o le politiche interne.	L'SDK gira all'interno della tua applicazione, quindi trasporto e archiviazione rimangono sotto la politica TLS e di crittografia che già applichi. Doconut non aggiunge alcun hop aggiuntivo.
Ciclo di vita non controllato	I file possono rimanere sul server, aumentando la superficie di violazione.	La conservazione è a tua discrezione, perché i documenti non lasciano mai il tuo ambiente. L'output temporaneo del rendering è scritto dove lo configuri e viene eliminato secondo il tuo programma.

Il fatto architetturale che conta è che l'SDK è installato nel tuo ambiente e non effettua chiamate ai server Doconut. Nulla viene caricato su di noi, quindi non c'è alcun processore terzo da aggiungere a una mappa dei dati né una politica di conservazione del fornitore da conciliare con la tua.

2. Preparare il progetto .NET

Usa il pacchetto, la documentazione e gli esempi che corrispondono alla versione Doconut selezionata per il progetto. La pagina ufficiale di pagina di download di Doconut è il punto di partenza affidabile.

Prima dell'integrazione, conferma il runtime .NET di destinazione, registra la versione del pacchetto, mantieni la configurazione della licenza fuori dal controllo del codice sorgente e inizia con documenti rappresentativi. ASP.NET Core, MVC e WebForms hanno cicli di vita dell'applicazione diversi, quindi la loro configurazione non deve essere trattata come identica.

3. Creare un endpoint sicuro per il caricamento – AES‑256, SSL e cancellazione automatica

L'SDK può leggere un documento da un percorso fisico, uno stream, un array di byte, un database, un URL, una posizione intranet o un provider cloud come S3, Azure Storage, Google Cloud o Dropbox. Ciò che non dovrebbe mai leggere è un percorso scelto dal browser. Inserisci un controllo di autorizzazione tra la richiesta e il documento, qualunque sia la fonte. Di seguito è mostrata una forma comune per quell'endpoint in ASP.NET Core; le stesse idee si applicano a MVC e WebForms.

Flusso di lavoro lato server

Accetta il file caricato – Usa lo standard IFormFile (o HttpPostedFile in WebForms) per ricevere il documento dal client.
Cifra il file con AES‑256 – Prima di persistere lo stream, cifralo usando una libreria collaudata come System.Security.Cryptography.Aes. Conserva il blob cifrato in una posizione sicura (ad es., Azure Blob Storage con crittografia lato server abilitata, o un bucket S3 con SSE‑AES256).
Genera un URL firmato a breve durata – Crea un URL valido per pochi minuti (ad es., 5 minuti). L'URL dovrebbe essere HTTPS e includere un token crittografico che Doconut può convalidare. La maggior parte dei fornitori di storage cloud offre una funzionalità di “URL pre‑firmato” che soddisfa questa esigenza.
Restituisci l'URL firmato al client – Invia una risposta JSON contenente l'URL. Il client passerà questo URL al visualizzatore Doconut.
Programma l'eliminazione automatica – Dopo la scadenza dell'URL firmato, un job in background (Hangfire, Azure Functions, ecc.) rimuove il blob cifrato, garantendo che il file non rimanga sul server.

Equivalenti MVC / WebForms

MVC – Inserisci la stessa logica all'interno di un'azione di controller regolare e restituisci JsonResult.
WebForms – Implementa un handler .ashx o un metodo di pagina che segua gli stessi passaggi: ricevi Request.Files[0], cifra, genera un URL pre‑firmato e scrivi la risposta JSON.

L'unica differenza è la sintassi del routing; il flusso di lavoro di sicurezza rimane identico.

4. Renderizza il documento tramite l'SDK installato

Mantieni l'accesso al documento sul server e applica l'autorizzazione prima di elaborare un file o uno stream. La sequenza esatta di rendering e di inizializzazione dell'interfaccia è specifica per versione; segui la documentazione ufficiale fornita con la build installata invece di copiare un'API JavaScript globale non verificata.

Perché questo funziona per ogni variante .NET

ASP.NET Core Razor – L'inizializzazione vive nella stessa vista che ospita il modulo di upload, quindi c'è una sola pagina da considerare.
MVC – Usa @section Scripts per iniettare lo stesso snippet; il controller restituisce JSON che $.ajax di MVC può consumare.
WebForms – Registra lo script con ClientScript.RegisterStartupScript dopo il completamento dell'upload, quindi chiama launchViewer allo stesso modo.

Il rendering avviene sul tuo server, ed è proprio questo il suo scopo: il browser riceve pagine renderizzate anziché il documento sorgente, motivo per cui un DWG o un PSD si aprono su una macchina che non ha né AutoCAD né Photoshop. Dimensiona il server di conseguenza — un PDF scansionato di 300 pagine è un lavoro reale, e ora è il tuo tier a gestirlo.

5. Personalizzare il visualizzatore per adattarlo al tuo portale

Le aziende solitamente hanno bisogno che il visualizzatore appaia come parte integrante del prodotto in cui è inserito, piuttosto che come una finestra verso quello di qualcun altro. L'aspetto del visualizzatore e il set di controlli che espone sono configurabili, e le opzioni disponibili dipendono dalla build installata.

Prendi i nomi di queste opzioni dalla documentazione fornita con la tua versione anziché da un post di blog. Le superfici di configurazione del visualizzatore sono esattamente il tipo di cosa che viene rinominata tra le versioni, e uno snippet copiato da un articolo di due versioni fa' fallire in un modo che sembra un problema di licenza.

La decisione da prendere prima di aprire quella documentazione è quali controlli ogni ruolo dovrebbe vedere. Se un utente può stampare, scaricare o solo scorrere un documento è una questione di permessi a cui la tua applicazione già conosce la risposta. Configura il visualizzatore in base a quella risposta, invece di esporre tutti i controlli sperando che nessuno clicchi.

6. Prestazioni e scalabilità – mantieni l'esperienza reattiva

Incorporare un visualizzatore in un portale ad alto traffico solleva due preoccupazioni pratiche: tempo di caricamento e rendering concorrente. Doconut App affronta entrambi subito, ma puoi rafforzare le prestazioni con alcuni trucchi specifici per .NET.

Problema	Cosa fare
Latenza della prima pagina	Il caricamento automatico della pagina consente al lettore di vedere la prima pagina mentre il resto è ancora in preparazione. Abilita la compressione dei file statici (`app.UseResponseCompression()`) e metti nella cache le risorse client.
Visualizzazioni ripetute dello stesso file	Un documento aperto frequentemente può essere renderizzato una volta e servito dall'output in cache invece di essere renderizzato nuovamente per ogni richiesta. La FAQ copre l'opzione `.DCN` proprio per questo.
Costo di rendering	Il rendering è un lavoro del server. Ridurre la risoluzione delle immagini dove la fedeltà non è critica è la leva più efficace, ed è una modifica di configurazione piuttosto che di codice.
Concorrenza	Rivedi le impostazioni di timeout e AutoClose sotto carico, e leggi gli esempi di web farm prima di presumere che un solo nodo sia sufficiente. Limita la velocità dell'endpoint di upload.

Misura con i tuoi documenti. Un PDF basato su testo da 5 MB e una scansione da 5 MB dello stesso rapporto non si comportano allo stesso modo, e solo uno dei due appare in un benchmark sintetico.

Punti Chiave

Doconut Viewer è un SDK .NET senza plugin che funziona con ASP.NET Core, MVC e WebForms. I tuoi utenti non installano nulla.
Viene installato nel tuo ambiente e non effettua chiamate ai server Doconut, quindi i documenti rimangono all'interno del perimetro che già controlli.
La sicurezza del trasporto, la crittografia a riposo e la conservazione sono a tua discrezione, poiché il file non lascia mai la tua infrastruttura. Doconut non diventa un responsabile del trattamento nella tua mappa dei dati.
Il catalogo SDK comprende 75 estensioni di file in 18 famiglie — PDF, Office, CAD, Visio, Project, email, eBook e immagini, con DICOM tramite il proprio plugin.
Il rendering avviene sul server. Questo è ciò che permette a un browser di aprire un DWG, ed è anche l'elemento di cui tenere conto per le dimensioni.
Quali controlli vede un utente — stampa, download o solo paginazione — dovrebbe seguire le autorizzazioni già possedute dalla tua applicazione.
Prendi i nomi delle opzioni di configurazione dalla documentazione della versione installata, mai da un articolo.

Domande Frequenti

Q1: Devo installare qualcosa sul server?
A: Sì. Doconut Viewer è un SDK .NET che installi nella tua applicazione — inizia dalla pagina di download e utilizza il pacchetto e la documentazione per la versione selezionata. Non esiste un endpoint hosted da chiamare, e nulla viene servito da un CDN Doconut.

Q2: Chi elimina il file dopo la visualizzazione?
A: Sei tu. Poiché il documento e qualsiasi output di rendering temporaneo vivono nel tuo ambiente, la conservazione è un'impostazione nella tua applicazione piuttosto che una promessa da parte di un fornitore. Decidi dove vengono scritti i file temporanei e cosa li rimuove, prima di passare alla produzione.

Q3: Gli utenti possono stampare il documento?
A: La stampa è una funzionalità del visualizzatore e può essere concessa o revocata per utente. Nota che la stampa controllata fa parte del visualizzatore stesso — non è uno dei quattro plugin con licenza, che sono Annotation, Converter, DICOM e Search.

Q4: Può convertire un documento in un altro formato?
A: Questa è la funzionalità del plugin Converter, con licenza separata. Visualizzare e convertire sono prodotti diversi qui, ed è utile chiarire quale dei due sia effettivamente necessario al flusso di lavoro.

Pronto a incorporare un visualizzatore di documenti senza plugin nella tua applicazione .NET? Inizia dalla pagina di download di Doconut — la licenza di prova è gratuita. E se quello di cui avevi realmente bisogno era aprire un file oggi, Doconut.app lo fa in una scheda del browser e lo elimina successivamente.