Cómo incrustar un visor de documentos sin complementos en ASP.NET
10/7/2026

Cómo incrustar un visor de documentos sin complementos en ASP.NET

Una guía paso a paso para ingenieros .NET que necesitan incrustar el visor de documentos seguro y sin complementos de Doconut App en proyectos ASP.NET Core, MVC o WebForms.

Puedes incrustar un visor de documentos sin complementos en una aplicación ASP.NET Core, MVC o WebForms sin pedir a ningún usuario que instale nada.
Las empresas que gestionan contratos, planos o activos de diseño necesitan un visor que respete las políticas de seguridad corporativas y nunca obligue a los usuarios a instalar complementos de navegador heredados. Doconut ofrece un SDK de visor de documentos .NET para flujos de trabajo basados en navegador de PDF, Office, CAD, correo electrónico e imágenes. No es un servicio alojado al que se llama: lo instalas en tu propia aplicación y se renderiza allí. Esta publicación describe las decisiones de integración sin depender de código de ejemplo específico de versión.

Una aclaración primero, porque los dos productos son fáciles de confundir. Doconut.app es el visor web gratuito — un archivo, abierto en una pestaña del navegador, eliminado después. No es algo que incrustes. Lo que incrustas es Doconut Viewer, el SDK, y todo lo que sigue trata de eso.

Visor de documentos incrustado conectado a un backend ASP.NET controlado
Visor de documentos incrustado conectado a un backend ASP.NET controlado

1. Por qué la seguridad y la renderización sin complementos son importantes para aplicaciones web .NET

Las empresas modernas tratan cada documento como una posible fuga de datos. Cuando incrustas un visor que depende de ActiveX, Flash o un cliente nativo, heredas tres riesgos:

RiesgoImpacto en tu aplicación .NETCómo lo elimina Doconut App
Dependencia de complementosLos usuarios deben instalar o habilitar un complemento del navegador, lo que genera tickets de soporte y problemas de cumplimiento.Doconut se ejecuta completamente en HTML5/Canvas, requiriendo cero complementos.
Tránsito sin cifrarLos archivos viajan por HTTP o se almacenan en texto plano, violando GDPR, HIPAA o políticas internas.El SDK se ejecuta dentro de tu aplicación, por lo que el transporte y el almacenamiento permanecen bajo la política TLS y de cifrado que ya aplicas. Doconut no añade ningún salto adicional.
Ciclo de vida no controladoLos archivos pueden permanecer en el servidor, aumentando la superficie de vulnerabilidad.La retención es tuya para definir, porque los documentos nunca abandonan tu entorno. La salida de renderizado temporal se escribe donde la configures y se elimina según tu programación.

El hecho arquitectónico importante es que el SDK se instala en tu propio entorno y no realiza llamadas a los servidores de Doconut. No se sube nada a nosotros, por lo que no hay un procesador externo que añadir a un mapa de datos y ninguna política de retención de proveedores que conciliar con la tuya.

2. Preparar el proyecto .NET

Utiliza el paquete, la documentación y los ejemplos que coincidan con la versión de Doconut seleccionada para el proyecto. La página de descarga oficial de Doconut es el punto de partida confiable.

Antes de la integración, confirma el runtime .NET objetivo, registra la versión del paquete, mantiene la configuración de licencia fuera del control de versiones y comienza con documentos representativos. ASP.NET Core, MVC y WebForms tienen ciclos de vida de aplicación diferentes, por lo que su configuración no debe tratarse como idéntica.

3. Construir un endpoint de carga segura – AES‑256, SSL y eliminación automática

El SDK puede leer un documento desde una ruta física, un flujo, un arreglo de bytes, una base de datos, una URL, una ubicación intranet o un proveedor de nube como S3, Azure Storage, Google Cloud o Dropbox. Lo que nunca debe leer es una ruta elegida por el navegador. Coloca una verificación de autorización entre la solicitud y el documento, sea cual sea la fuente. A continuación se muestra una forma común de ese endpoint en ASP.NET Core; las mismas ideas se aplican a MVC y WebForms.

// Código de ejemplo del endpoint (no traducir)
[HttpPost("api/upload")]
public async Task<IActionResult> Upload(IFormFile file)
{
    // Validar autorización
    if (!User.HasClaim("CanUpload", "true"))
        return Forbid();

    // Guardar temporalmente de forma segura
    var tempPath = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());
    using (var stream = new FileStream(tempPath, FileMode.Create))
    {
        await file.CopyToAsync(stream);
    }

    // Procesar con Doconut SDK (ejemplo)
    var viewer = new DoconutViewer();
    var renderResult = viewer.RenderDocument(tempPath, new RenderOptions
    {
        // Opciones de seguridad, cifrado, etc.
    });

    // Eliminar archivo después de procesar
    System.IO.File.Delete(tempPath);

    return File(renderResult.Stream, "application/pdf");
}

Flujo de trabajo del lado del servidor

  1. Aceptar el archivo subido – Utilice el estándar IFormFile (o HttpPostedFile en WebForms) para recibir el documento del cliente.
  2. Cifrar el archivo con AES‑256 – Antes de persistir el flujo, encriptelo usando una biblioteca probada como System.Security.Cryptography.Aes. Almacene el blob cifrado en una ubicación segura (p. ej., Azure Blob Storage con cifrado del lado del servidor habilitado, o un bucket S3 con SSE‑AES256).
  3. Generar una URL firmada de corta duración – Cree una URL válida por unos minutos (p. ej., 5 minutos). La URL debe ser HTTPS e incluir un token criptográfico que Doconut pueda validar. La mayoría de los proveedores de almacenamiento en la nube ofrecen una función de “URL pre‑firmada” que se ajusta a esta necesidad.
  4. Devolver la URL firmada al cliente – Envíe una respuesta JSON que contenga la URL. El cliente entregará esta URL al visor Doconut.
  5. Programar la eliminación automática – Después de que la URL firmada expire, un trabajo en segundo plano (Hangfire, Azure Functions, etc.) elimina el blob cifrado, garantizando que el archivo no permanezca en el servidor.

Equivalentes MVC / WebForms

  • MVC – Coloque la misma lógica dentro de una acción de controlador regular y devuelva JsonResult.
  • WebForms – Implemente un controlador .ashx o un método de página que siga los mismos pasos: recibir Request.Files[0], cifrar, generar una URL pre‑firmada y escribir la respuesta JSON.

La única diferencia es la sintaxis de enrutamiento; el flujo de trabajo de seguridad sigue siendo idéntico.


4. Renderizar el documento mediante el SDK instalado

Mantenga el acceso al documento en el servidor y haga cumplir la autorización antes de procesar un archivo o flujo. La secuencia exacta de renderizado e inicialización de la UI es específica de la versión; siga la documentación oficial incluida con la compilación instalada en lugar de copiar una API JavaScript global no verificada.

Por qué esto funciona para cualquier variante de .NET

  • ASP.NET Core Razor – La inicialización vive en la misma vista que aloja el formulario de carga, por lo que hay una sola página que considerar.
  • MVC – Use @section Scripts para inyectar el mismo fragmento; el controlador devuelve JSON que $.ajax de MVC puede consumir.
  • WebForms – Registre el script con ClientScript.RegisterStartupScript después de que la carga se complete, luego llame a launchViewer de la misma manera.

El renderizado ocurre en su servidor, y ese es el objetivo: el navegador recibe páginas renderizadas en lugar del documento fuente, lo que explica por qué un DWG o un PSD se abre en una máquina que no tiene AutoCAD ni Photoshop. Dimensione el servidor adecuadamente — un PDF escaneado de 300 páginas implica trabajo real, y ahora es su nivel el que lo realiza.


5. Personalizando el visor para que coincida con su portal

Las empresas suelen necesitar que el visor se vea como parte del producto en el que se integra, en lugar de una ventana al producto de otro. La apariencia del visor y el conjunto de controles que expone son configurables, y las opciones disponibles dependen de la compilación que haya instalado.

Obtenga esos nombres de opción de la documentación incluida con su versión en lugar de un blog. Las superficies de configuración del visor son precisamente el tipo de cosas que se renombran entre versiones, y un fragmento copiado de un artículo de dos versiones atrás falla de una manera que parece un problema de licencia.

La decisión que vale la pena tomar antes de abrir esa documentación es qué controles debe ver cada rol. Si un usuario puede imprimir, descargar o solo pasar páginas de un documento es una cuestión de permisos que su aplicación ya conoce. Configure el visor a partir de esa respuesta, en lugar de exponer todos los controles y esperar que nadie haga clic.


6. Rendimiento y escalabilidad – mantenga la experiencia ágil

Incorporar un visor en un portal de alto tráfico plantea dos preocupaciones prácticas: tiempo de carga y renderizado concurrente. La Aplicación Doconut aborda ambos de forma nativa, pero puede reforzar el rendimiento con algunos trucos específicos de .NET.

PreocupaciónQué hacer al respecto
Latencia de la primera páginaLa carga automática de página permite al lector ver la primera página mientras el resto aún se está preparando. Habilite la compresión de archivos estáticos (app.UseResponseCompression()) y almacene en caché los recursos del cliente.
Vistas repetidas de un mismo archivoUn documento abierto con frecuencia puede renderizarse una vez y servirse desde la salida en caché en lugar de volver a renderizarse por cada solicitud. Las preguntas frecuentes cubren la opción .DCN para exactamente esto.
Costo de renderizadoEl renderizado es trabajo del servidor. Reducir la resolución de la imagen donde la fidelidad no es crítica es la palanca única más grande, y es un cambio de configuración más que un cambio de código.
ConcurrenciaRevise la configuración de tiempo de espera y AutoClose bajo carga, y lea los ejemplos de granja web antes de asumir que un solo nodo será suficiente. Limite la tasa del punto final de carga.

Mida con sus propios documentos. Un PDF basado en texto de 5 MB y un escaneo de 5 MB del mismo informe no se comportan de la misma manera, y solo uno de ellos aparece en una prueba sintética.

Puntos clave

  • Doconut Viewer es un SDK .NET sin complementos que funciona con ASP.NET Core, MVC y WebForms. Tus usuarios no instalan nada.
  • Se instala en tu propio entorno y no realiza llamadas a los servidores de Doconut, por lo que los documentos permanecen dentro del límite que ya controlas.
  • La seguridad de transporte, el cifrado en reposo y la retención son configurables por ti, porque el archivo nunca abandona tu infraestructura. Doconut no se convierte en un procesador en tu mapa de datos.
  • El catálogo del SDK incluye 75 extensiones de archivo en 18 familias — PDF, Office, CAD, Visio, Project, correo electrónico, eBook e imágenes, con DICOM a través de su propio complemento.
  • El renderizado se realiza en el servidor. Eso es lo que permite que un navegador abra un DWG, y también es el elemento a dimensionar.
  • Los controles que ve un usuario — imprimir, descargar o solo paginar — deben seguir los permisos que ya tiene tu aplicación.
  • Obtén los nombres de las opciones de configuración de la documentación de la versión que tienes instalada, nunca de un artículo.

Preguntas comunes

P1: ¿Instalo algo en el servidor?
R: Sí. Doconut Viewer es un SDK .NET que instalas en tu aplicación — comienza desde la página de descarga y usa el paquete y la documentación de la versión que seleccionaste. No hay un endpoint alojado al que llamar, y nada se sirve desde un CDN de Doconut.

P2: ¿Quién elimina el archivo después de la visualización?
R: Tú lo haces. Debido a que el documento y cualquier salida temporal de renderizado viven en tu entorno, la retención es una configuración en tu aplicación y no una promesa de un proveedor. Decide dónde se escriben los archivos temporales y qué los elimina, antes de pasar a producción.

P3: ¿Pueden los usuarios imprimir el documento?
R: La impresión es una capacidad del visor, y puede concederse o revocarse por usuario. Ten en cuenta que la impresión controlada forma parte del propio visor — no es uno de los cuatro complementos con licencia, que son Anotación, Convertidor, DICOM y Búsqueda.

P4: ¿Puede convertir un documento a otro formato?
R: Ese es el complemento Convertidor, licenciado por separado. Visualizar y convertir son productos diferentes aquí, y vale la pena ser claro sobre cuál necesita realmente el flujo de trabajo.


¿Listo para integrar un visor de documentos sin complementos en tu aplicación .NET? Comienza desde la página de descarga de Doconut — la licencia de prueba es gratuita. Y si lo que realmente necesitabas era abrir un archivo hoy, Doconut.app lo hace en una pestaña del navegador y lo elimina después.