Puede ver PDFs, archivos de Office, dibujos CAD, correos electrónicos e imágenes en el navegador sin instalar plugins heredados. Para aplicaciones .NET basadas en Windows, Visor Doconut proporciona procesamiento de documentos en el backend mientras los usuarios permanecen dentro de la aplicación empresarial.

Visualización moderna de documentos sin plugins en una aplicación de navegador Windows

En las siguientes secciones exploraremos por qué es importante eliminar los plugins heredados, describiremos un flujo de integración con ASP.NET Core y discutiremos cargas por arrastrar y soltar y la integración con Blazor sin depender de código SDK no verificado.

Sin plugins: Por qué son un cambio de juego para aplicaciones web .NET

Eliminar la fricción del “instalar‑primero”

Los visores tradicionales se aferran a ActiveX, Java o Flash. Estos exigen permisos, generan alertas de seguridad y dejan de funcionar en navegadores modernos. Doconut lo evita al renderizar en el servidor y enviar al navegador HTML e imágenes ordinarias — nada que instalar en el cliente, sin mensajes, sin tickets de TI.

Esa distinción es importante para el resto de este artículo, así que vale la pena declararla claramente: el análisis y rasterizado se realizan en su servidor, no en el navegador del usuario. Sin plugins significa que el cliente no necesita nada; no implica que el trabajo se haya trasladado a JavaScript.

Mantener intacto el sandbox del navegador

Dado que no se carga ningún plugin externo, el sandbox del navegador permanece intacto. Mejor aún, la máquina del usuario nunca recibe el documento original — solo recibe páginas renderizadas — por lo que un PDF malicioso no tiene nada sobre lo que actuar.

Lo que esto no hace es eliminar la superficie de ataque; la traslada a su servidor, donde un analizador procesa entradas no confiables. Ejecútelo con los mínimos privilegios, manténgalo actualizado y valide las cargas. La seguridad del transporte, el cifrado en reposo y la retención son responsabilidad de su aplicación — el SDK no los incluye.

Preparado para el futuro en navegadores y dispositivos

Como el navegador solo necesita mostrar HTML e imágenes estándar, hay muy poco que una actualización del navegador pueda romper. Chrome, Edge, Safari o un WebView móvil se comportan igual, sin advertencias de “plugin faltante” y sin soluciones específicas por versión — y un dispositivo de bajo rendimiento no es una desventaja, ya que no realiza el renderizado.

Incrustar el visor sin plugins de Doconut App en ASP.NET Core

Para integrar el visor, genere una URL firmada y de corta duración para el documento en el servidor y pásela al cliente. El servidor renderiza el documento y transmite las páginas mediante HTTPS a un elemento contenedor en la página.

Flujo de trabajo del lado del servidor (conceptual)

Recibir una solicitud de documento.
Recuperar el archivo de su almacenamiento (SQL, Blob, etc.).
Crear una URL firmada y limitada en el tiempo que apunte al archivo cifrado.
Devolver esa URL a la vista Razor.

Vista Razor (conceptual)

Mantenga la vista responsable del diseño y del estado autorizado del visor, mientras el servidor recupera y procesa el documento. Utilice solo los recursos del cliente y la secuencia de inicialización documentada para la versión instalada de Doconut.

Cuando la página se carga, el cliente solicita el documento mediante su URL firmada y muestra las páginas que devuelve el servidor. Sin ActiveX, Java o Flash.

Por qué esto es importante

Sin plugins: el cliente solo necesita un navegador y nada más.
El archivo fuente nunca llega al usuario: recibe páginas renderizadas, por lo que no hay una copia local para reenviar, almacenar en caché o filtrar.
La seguridad es su responsabilidad: la URL de corta duración y firmada es código que usted escribe. Nada del visor lo impone por usted, así que inclúyalo en el diseño en lugar de asumirlo.
Paginación: las páginas se entregan según se necesiten en lugar de todas a la vez, lo que permite que un PDF extenso o un dibujo denso sean utilizables.

Renderizado de formatos compatibles sin complementos

El motor del SDK maneja 75 extensiones de archivo en 18 familias — PDF, DOCX, XLSX, PPTX, DWG, DXF, PSD, VSDX, MPP, EML, MSG, EPUB, TIFF, PNG, JPEG y el resto, incluido DICOM a través de su complemento con licencia separada. Los visores gratuitos en doconut.app aceptan 73 de ellas: todo excepto .dcm y .ima.

El motor identifica el archivo por su contenido en lugar de por su extensión, lo cual es más importante de lo que parece: muchos archivos con el nombre .xls son en realidad tablas HTML o CSV.

Una advertencia sobre la fidelidad, ya que “pixel-perfect” es una promesa que ningún renderizador puede cumplir: los documentos que hacen referencia a recursos que no contienen diferirán de lo que vio su autor. Las fuentes que nunca se incrustaron son sustituidas, y las referencias externas de un DWG no están dentro del DWG.

Carga por arrastrar y soltar con renderizado instantáneo y sin complementos

Las empresas quieren que los usuarios previsualicen los archivos directamente. Puedes añadir una zona de arrastrar y soltar que cargue un documento, genere una URL de vista firmada y muestre el resultado sin ningún complemento en el cliente. Todo el ciclo permanece dentro de tu backend .NET — lo que te permite mantener los registros de auditoría, ya que el registro es tuyo para escribir.

Flujo del cliente (conceptual)

El usuario arrastra un archivo a un área designada.
JavaScript envía el archivo a un endpoint ASP.NET Core.
El endpoint almacena el archivo de forma segura y devuelve una URL de vista firmada.
La página inyecta un <div> con data‑doc‑url que apunta a esa URL.
El script de Doconut App renderiza el documento instantáneamente.

El renderizado ocurre en tu servidor, así que planifícalo: aquí es donde se utilizan la CPU y la memoria, y escala con los espectadores concurrentes en lugar de con los usuarios. Verifica dónde el SDK escribe la salida temporal del renderizado y asegúrate de que algo la limpie — los archivos huérfanos en un directorio temporal son la parte más comúnmente pasada por alto en una integración.

Visualización consistente en flujos de trabajo basados en Windows

Un visor en el navegador puede ofrecer un punto de entrada consistente para los usuarios de una aplicación interna de Windows sin requerir programas de escritorio separados para documentos. Los equipos deben probar los navegadores compatibles, tamaños de pantalla, métodos de entrada, complejidad de los documentos y requisitos de accesibilidad en lugar de asumir un comportamiento idéntico en cada entorno.

Extender el visor con Blazor – Mantener todo dentro de tu ecosistema .NET

Si tu equipo prefiere un enfoque centrado en componentes, puedes envolver el script del visor del lado del cliente en un componente Blazor, bajo cualquiera de los modelos de alojamiento. Eso mantiene la integración dentro del mundo .NET. Ten en cuenta que el modelo de alojamiento solo afecta dónde se ejecuta tu código de UI — el renderizado del documento permanece en el servidor de cualquier manera.

Esquema del componente Blazor (conceptual)

Inyecta un servicio que pueda generar una URL de vista segura para un ID de archivo dado.
En la inicialización, solicita la URL al servicio.
Después de que el componente se renderice, inicializa el visor usando la API de integración compatible para la versión instalada de Doconut.

El componente Blazor puede coordinar el estado del visor mientras el backend sigue siendo responsable del acceso y procesamiento de documentos. Esto mantiene el flujo de trabajo dentro de la aplicación .NET sin publicar suposiciones sobre una API global de JavaScript.

Puntos clave

Cero complementos eliminan la fricción de instalación, advertencias de seguridad y dolores de cabeza de compatibilidad.
El SDK renderiza 75 extensiones — PDF, Office, CAD, correo electrónico e imágenes — en el servidor, no en el navegador.
Integración: genera una URL de vista firmada del lado del servidor y muestra las páginas devueltas en un contenedor.
La carga por arrastrar y soltar más la vista previa en el lugar mantiene a los usuarios en el flujo.
Se comporta igual en escritorio, tablet y móvil, porque el navegador solo muestra la salida estándar.
Los desarrolladores de Blazor pueden envolver el visor en un componente .NET.
La seguridad es arquitectónica, no una lista de características: el archivo fuente nunca llega al cliente, y el documento nunca abandona tu infraestructura. El cifrado en reposo, la expiración de URLs firmadas y el registro de auditoría son tuyos para implementar — y Doconut no posee certificación ISO 27001, SOC 2 o HIPAA en la que apoyarse.

Preguntas comunes

P: ¿Necesito instalar algo en las máquinas cliente?
R: No. El visor Aplicación Doconut se ejecuta completamente en el navegador usando HTML5 y JavaScript. Los usuarios solo necesitan un navegador moderno—no se requieren instalaciones de ActiveX, Java o Flash.

P: ¿Cómo maneja archivos grandes?
R: Las páginas se renderizan y entregan según se necesiten, de modo que el lector puede saltar a una página sin esperar a que se cargue todo el documento. Tenga en cuenta que este trabajo lo realiza su servidor—pruebe con sus archivos reales más pesados para dimensionarlo. En el sitio gratuito en doconut.app el límite es nuestro y varía por formato: 25 MB para un PDF, 10 MB para un dibujo CAD.

Comience con la Aplicación Doconut hoy

¿Listo para eliminar los complementos heredados de su aplicación .NET basada en Windows? Evalúe el SDK de Doconut con los navegadores, formatos de documento y cargas de trabajo que usa su organización.