Saltar al contenido principal

DNN · Visión general

DNN Platform sigue siendo una plataforma viva en el ecosistema .NET, especialmente en sectores B2B, gobierno y educación. Neuroon no publica un módulo empaquetado (.dnn) por ahora: en su lugar mantenemos un recipe end-to-end y una serie de plantillas C# que cubren los tres frentes habituales.

¿Qué versiones de DNN están soportadas?​

StackSoportadoNotas
DNN 9.x sobre .NET Framework 4.7.2+SíVía System.Net.Http + System.Text.Json 6.0+.
DNN 9.x sobre .NET 8SíRecomendado: System.Net.Http.Json nativo.
DNN 8.xNo probadoProbablemente funciona si añades System.Net.Http.Json y Polly.
Legacy DotNetNuke 7.xNo soportadoHttpClient y APIs requeridas no disponibles sin parches.

El recipe completo asume DNN 9.x. Si estás en .NET Framework 4.7.2 sin .NET 8, sustituye record por class y la lógica del cliente sigue funcionando.

Arquitectura recomendada​

Neuroon se integra en DNN como tres piezas independientes, cada una alineada con un mecanismo nativo de la plataforma:

PiezaMecanismo DNNResponsabilidad
Módulo / DesktopModuleIPortable, ModuleSettingsBasePestaña de configuración (API Key, Shop ID, ApiUrl).
SchedulerIScheduledTask (SchedulerClient)Sync nocturna y delta en background.
Skin / SkinObject.ascx con code-behindEmbebido del widget en el tema, con widget token cacheado.

La razón de mantenerlas separadas es respetar el ciclo de vida que DNN ya conoce: el Host gestiona el scheduler con Host → Schedule, los settings cifrados viven en HostController, y los skins se actualizan sin tocar deploys del módulo.

Componentes clave​

DesktopModules/Neuroon/
├── App_Code/Neuroon/
│   ├── NeuroonClient.cs          // HTTP client con Polly + chunk 500
│   ├── NeuroonSettings.cs        // Lectura cifrada de HostSettings
│   ├── NeuroonProduct.cs         // DTO alineado con products/sync
│   └── WidgetTokenProvider.cs    // Cache del widget token (24h, margen 5min)
├── Schedulers/
│   └── NeuroonSyncScheduler.cs   // IScheduledTask (sync nocturna)
└── Skins/Neuroon/
    └── NeuroonSearchSkin.ascx    // SkinObject con loader + SRI

¿Por qué cifrar las credenciales en HostSettings?​

DNN ofrece HostController.Instance.UpdateEncryptedString con la decryption key de web.config. Esto permite:

  • Persistir la Shop API Key (sk_…) sin escribirla en plano en BD.
  • Rotar la key con un único UPDATE (no requiere redeploy).
  • Auditar cambios desde el log de eventos de DNN.

Nunca pongas la key en web.config, en una variable de entorno expuesta al frontend, ni en un appSettings plano.

Flujo end-to-end​

  1. Configurar HostSettings (Neuroon.ShopId, Neuroon.ApiKey, Neuroon.ApiUrl).
  2. Sync inicial ejecutando manualmente el scheduler con frecuencia 0 (one-shot).
  3. Programar el scheduler (Host → Schedule → Add Item) con frecuencia 1 day y Catch-up Enabled.
  4. Embeber el widget en el .ascx del Skin con el token emitido por WidgetTokenProvider.
  5. Cart bridge: emite neuroon:cart-update desde Razor / .ascx cuando el módulo de e-commerce dispara su evento equivalente.
  6. Tracking: llama a client.TrackConversionAsync(...) desde tu handler OnOrderConfirmed (server-side, robusto vs. adblockers).

Por qué este enfoque y no un módulo empaquetado​

Los módulos DNN empaquetados imponen una versión rígida del runtime y dependencias propias. Mantener un recipe + plantillas (no un .dnn) ofrece:

  • Adaptabilidad al módulo de e-commerce real del cliente (DNN Commerce, NB_Store, Hotcakes, módulo propio).
  • Pin de dependencias elegido por el equipo (Polly versión, JSON serializer, etc.).
  • Iteración rápida: las correcciones se aplican copiando un archivo .cs, no reinstalando un módulo.

Cuando exista demanda crítica para un .dnn, lo publicaremos como complemento opcional sin romper la ruta actual.

Próximos pasos​

Última actualización en