Cuándo elegir un CMS .NET

Elegir un gestor de contenidos (CMS) depende del tipo de proyecto, el equipo tecnico y el hosting. Un CMS .NET como DotNetNuke (DNN) puede ser adecuado para entornos empresariales que ya trabajan con tecnologia Microsoft.

Cuando elegir un CMS .NET

Si tu empresa usa Windows Server, SQL Server y desarrolladores .NET, un CMS basado en .NET encaja bien en el ecosistema. DNN ofrece multi-idioma, roles y permisos granulares, y modularidad. Es una opcion a valorar para portales corporativos, intranets o sitios que requieren integracion con sistemas Microsoft.

DotNetNuke: ventajas e inconvenientes

Ventajas: solidez, comunidad, multiples modulos y temas, soporte empresarial disponible. Inconvenientes: curva de aprendizaje si no conoces .NET, hosting suele ser mas caro que el tipico PHP, y menos plugins que WordPress para usos muy concretos. Compara con tus necesidades reales.

Hosting para DotNetNuke

DNN requiere Windows Server, IIS y .NET en la version adecuada. No todos los hostings compartidos lo ofrecen; suele ser necesario VPS o servidor dedicado. Revisa requisitos oficiales de version y base de datos antes de contratar.

Seguridad y actualizaciones en DNN

Mantener DNN actualizado es importante para la seguridad. Suscribirse a las noticias oficiales y aplicar parches en cuanto salgan reduce riesgos. Configura backups y pruebas en entorno de desarrollo antes de actualizar en produccion.

DNN frente a WordPress u otros CMS

WordPress domina en cantidad de sitios y facilidad para blogs y pequenas webs. DNN brilla en entornos donde ya se usa .NET y se necesitan permisos avanzados o integracion con Active Directory y otros sistemas corporativos. La decision depende del equipo y del proyecto.

En resumen: valora un CMS .NET como DNN si tu stack es Microsoft y necesitas un portal flexible y seguro. Revisa hosting, formacion del equipo y coste total antes de decidir.

CMS .NET: cuándo elegir DotNetNuke

Elegir un CMS (sistema de gestión de contenidos) para tu web depende del tipo de proyecto, del equipo técnico y del presupuesto. Si valoras una solución basada en .NET, DotNetNuke es una de las opciones más extendidas. Aquí tienes aspectos básicos para valorarla.

Ventajas de un CMS .NET

Si tu empresa ya usa tecnología Microsoft (servidores, Active Directory, aplicaciones propias), un CMS como DNN puede integrarse mejor con el ecosistema. La seguridad, el control de versiones y la escalabilidad suelen estar bien resueltos en entornos .NET. La curva de aprendizaje es mayor si el equipo no conoce la plataforma.

Alternativas y comparativa

Además de DotNetNuke existen otros CMS (WordPress, Drupal, etc.) que no usan .NET. Compara según tus necesidades: tipo de contenido, multidioma, comercio electrónico, número de editores. No hay una solución única; lo importante es que el CMS se adapte al proyecto y al equipo.

Conclusión

DotNetNuke y otros CMS .NET son una buena opción cuando el contexto técnico y organizativo lo favorecen. Con un análisis claro de requisitos, tomarás la decisión correcta.

Novedades del Dotnetnuke 5.6.2

La versión 5.6.2 nos deja una novedad, con la que hay que ir con cuidado. Especialmente si, te dedicas habitualmente a mover portales de un servidor a otro. Cambiar de sitio portales DotNetNuke no es algo extraño para quien monta los portales en un servidor de desarrollo y luego debe subirlos al servidor de producción, o quien debe aumentar la capacidad de su centro de datos, por ejemplo.

Mover un DNN, hasta ahora, era sencillo: una vez copiados los ficheros y la base de datos, y modificadas las cadenas de conexión correspondientes, bastaba con cambiar el alias en la tabla PortalAlias. Por ejemplo, podríamos mover este portal a un servidor de desarrollo usando como host new.webdelcliente.com: bastaría con tenerlo añadido como alias o añadirlo después de la migración .Con DotNetNuke 5.6.2 debemos tener en cuenta que es posible, aunque no obligatorio, tener definido un alias por defecto, sobre el que siempre funcionara el portal. En el caso de que tengamos predefinido un alias del portal, de nada nos servirá tener definidos o añadir otros (en la tabla PortalAlias). Deberemos también tocar la tabla PortalSettings, en el parámetro DefaultPortalAlias. Os recuerdo que todo lo relativo a los alias de portales se gestiona en Admin > Site Settings, como usuario host.

 

Fuente:dotware