Elegir el SDK Doconut adecuado: .NET Standard 2.1, .NET 6 o .NET 8
Comience con el host de la aplicación
Elegir un paquete Doconut comienza con el proyecto que lo ejecutará. Una nueva aplicación web .NET 8, un servicio .NET 6 ya establecido y un host compatible con ASP.NET Core pueden necesitar visualización de documentos integrada, pero sus restricciones de framework y planes de actualización difieren.
Doconut ofrece rutas de SDK actuales para .NET 8, .NET 6 y hosts compatibles que consumen el nuevo paquete .NET Standard 2.1. La elección correcta suele ser el paquete que coincida directamente con el host y deje la menor ambigüedad de framework para el equipo que mantiene la aplicación.
La descripción general del SDK del Visor Doconut es el punto de partida para conocer las capacidades del producto. Use la documentación específica del framework para tomar la decisión del paquete.
Entienda lo que significan las tres etiquetas
.NET 8 y .NET 6 son objetivos de aplicación. Una aplicación web puede dirigirse a uno de estos runtimes y seleccionar el paquete Doconut correspondiente.
.NET Standard 2.1 es diferente: define un contrato de API de biblioteca que los hosts .NET compatibles pueden consumir. Doconut 26.8.0 introduce la generación actual Doconut.NETStandard para aplicaciones que apuntan a .NET Core 3.0 o posterior, incluido .NET 5 a través de .NET 8. No puede ser consumido por .NET Framework.
Esa distinción mantiene la decisión fundamentada. No elija .NET Standard 2.1 solo porque suena más general; elíjalo cuando su contrato sea el ajuste apropiado para el host y la estructura de la solución.
Tabla práctica de selección
| Situación de la aplicación | Ruta Doconut a evaluar | Por qué |
|---|---|---|
| Nueva aplicación dirigida a .NET 8 | Doconut.NET8 | Coincidencia directa para el desarrollo .NET actual y la ruta completa de documentación de .NET 8. |
| Aplicación existente que debe permanecer en .NET 6 | Doconut.NET6 | Mantiene el objetivo del host mientras proporciona la inyección de dependencias, middleware, sesión asíncrona y modelo distribuido opcional actuales. |
| Host ASP.NET Core compatible donde se requiere el contrato .NET Standard | Doconut.NETStandard 26.8.0+ | Apunta a .NET Standard 2.1 y expone la integración Doconut actual para hosts soportados. |
| Integración Doconut.NETStandard 26.7.0 o anterior existente | Planifique una migración antes de seleccionar 26.8.0+ | El ID del paquete sigue siendo el mismo, pero el objetivo y la generación de API cambian. |
| Aplicación dirigida a .NET Framework | Doconut.NETFramework | .NET Framework no puede consumir .NET Standard 2.1. |
Esta tabla reduce la primera decisión. Licencias, complementos opcionales, formatos de documento, diseño de despliegue y esfuerzo de actualización aún requieren validación separada.
Elija Doconut.NET8 para nuevas aplicaciones .NET 8
Para una nueva aplicación .NET 8, el paquete dedicado es la opción más clara para evaluar. La página del Visor .NET 8 describe el modelo actual basado en inyección de dependencias, recursos servidos por middleware, sesiones de documento asíncronas y flujos de trabajo distribuidos opcionales.
Una coincidencia directa del runtime también facilita seguir la documentación. Instalación, configuración, solución de problemas, complementos y ejemplos pueden evaluarse dentro de una única ruta específica del framework.
Antes de adoptarlo, pruebe los formatos de documento y las funciones opcionales que el producto realmente necesita. Una coincidencia de paquete no reemplaza las decisiones a nivel de aplicación sobre autenticación, autorización, almacenamiento, retención, monitoreo y límites de recursos.
Elija Doconut.NET6 cuando el host debe permanecer en .NET 6
Una aplicación establecida puede tener dependencias o compromisos de soporte que la mantengan en .NET 6. El Visor .NET 6 actualizado permite que la aplicación conserve ese objetivo mientras se traslada a la arquitectura de integración actual de Doconut.
Esto es útil cuando una actualización del tiempo de ejecución y una migración del visor de documentos no deben ocurrir en la misma versión. El equipo puede modernizar el registro del visor, la entrega de recursos, la apertura asíncrona y las sesiones de documentos mientras mantiene estable el framework del host.
Verifique si el proyecto existente utiliza la integración clásica o actualizada de Doconut .NET 6. Los nombres de los paquetes por sí solos pueden no revelar la generación. La documentación oficial de migración identifica las firmas de API y los patrones de alojamiento que los distinguen.
Elija Doconut.NETStandard cuando el contrato se ajuste a la solución
La nueva guía de instalación de .NET Standard 2.1 define el límite de compatibilidad. Soporta .NET Core 3.0 y hosts posteriores, incluidos .NET 5, 6, 7 y 8, y excluye .NET Framework.
Esta ruta puede tener sentido cuando la solución requiere específicamente el contrato de la biblioteca .NET Standard. La selección de versión es crítica: Doconut.NETStandard 26.7.0 y anteriores apuntan a .NET Standard 2.0 y utilizan la integración anterior, mientras que 26.8.0 y posteriores apuntan a .NET Standard 2.1 con la API actual.
Si la aplicación ya utiliza la generación anterior del paquete, consulte la guía de migración de .NET Standard antes de actualizar. El cambio afecta más que la compilación: el inicio, la vida útil del visor, el enrutamiento de recursos, la apertura de documentos, licencias, complementos y la publicación distribuida pueden requerir atención.
Compare el impacto completo de la aplicación
Una pequeña prueba de concepto debería responder más que “¿se instala el paquete?” Evalúe:
- Compatibilidad del host: Confirme el objetivo de la aplicación y cada proyecto que haga referencia al paquete del visor.
- Generación de integración: Identifique el registro actual o clásico, la creación del visor y los patrones de apertura de documentos.
- Cobertura de documentos: Pruebe archivos representativos de PDF, Office, CAD, imágenes, correo electrónico o archivos médicos requeridos por el producto.
- Necesidades de complementos: Valide individualmente las capacidades de Búsqueda, Anotación, Conversor o DICOM cuando formen parte del flujo de trabajo.
- Modelo operativo: Pruebe la duración de la sesión, el almacenamiento en caché, la entrega de recursos, la limpieza y cualquier diseño de nodo único o distribuido.
- Esfuerzo de actualización: Separe los cambios del framework de los cambios de Doconut para que los fallos sean más fáciles de diagnosticar.
- Controles de la aplicación: Verifique el acceso, almacenamiento, retención y comportamiento de entrega en el sistema circundante.
Registre la versión del paquete y el objetivo del framework junto a cada resultado. Eso evita que una prueba exitosa contra una ruta SDK se confunda con evidencia sobre otra.
Haga explícita la elección del framework
Una buena nota de arquitectura puede ser breve: indique el objetivo de la aplicación, el paquete Doconut seleccionado y su versión, los complementos requeridos, el modelo de despliegue y la ruta de documentación utilizada durante la implementación. Ese registro de decisión ayuda a que las actualizaciones posteriores comiencen desde hechos en lugar de suposiciones basadas en el nombre del paquete.
Para el desarrollo nuevo en .NET 8, comience con el SDK dedicado de .NET 8. Para una aplicación que permanezca en .NET 6, evalúe el paquete .NET 6 actualizado. Use Doconut.NETStandard 26.8.0+ cuando el contrato .NET Standard 2.1 sea el adecuado para un host compatible, y mantenga las aplicaciones .NET Framework en su ruta de paquete dedicada.
Revise el centro de documentación de Doconut y descargue una prueba para probar la ruta seleccionada con su propia aplicación y documentos.