KomuraSoft LLC
Contáctenos
Menú

Cómo elegir el método de distribución de aplicaciones de Windows - MSI/MSIX/ClickOnce/xcopy/actualizador propio

· Actualizado el: · · Windows, Distribución, MSI, MSIX, ClickOnce, xcopy, Actualizador

Descargar la hoja de cálculo Excel de decisión, con pestañas en japonés e inglés

A la hora de decidir el método de distribución de una aplicación de Windows, es fácil empezar la conversación preguntando «¿cuál es más nuevo?» o «¿cuál es más fácil?». Sin embargo, en la práctica lo que realmente importa se mide con otros ejes.

  • ¿Se quiere instalar por usuario o en toda la máquina?
  • ¿Se quiere delegar la actualización en una plataforma de distribución o gestionarla uno mismo?
  • ¿Hay integración con el sistema operativo, como servicios, drivers, shell extensions o registro COM?
  • ¿Es necesario soportar distribución en redes cerradas, sin conexión o por USB?
  • ¿Se necesita package identity, o se prefiere funcionar como Win32 puro y sin restricciones (unrestricted)?

La elección del método de distribución no es una preferencia de formato de instalador, sino la elección de hasta dónde se toca el sistema operativo y de quién asume la responsabilidad de la actualización.

Este artículo está escrito para desarrolladores que están creando una aplicación de escritorio de Windows y que van a decidir su método de distribución, o que quieren revisar el que ya tienen, así como para el personal de sistemas que se hace cargo de la operación posterior. No se parte de ningún lenguaje o framework en concreto. Como en este ámbito muchos términos circulan tal cual en inglés, se recopilan en el apartado 1.1. El contenido de la hoja de cálculo del principio se resume en el apartado 1.2.

1. Conclusión, para empezar

Dicho de forma bastante directa, pero útil para el trabajo diario, queda así.

  • Si se instala en toda la máquina, hay servicios o registro COM, o se instalan prerrequisitos, conviene empezar a pensar por MSI.
  • Si se parte de Windows 10/11, se quiere clean install/clean uninstall, actualizaciones frecuentes y package identity, MSIX es una opción sólida.
  • Si se quiere distribuir fácilmente, por usuario, una app de escritorio de .NET para uso interno y mantenerla actualizada automáticamente, ClickOnce sigue siendo hoy una opción muy fuerte.
  • Si se prioriza una herramienta que funcione con solo colocarla, redes cerradas, distribución por USB y sin permisos de administrador, xcopy es lo más directo.
  • Si se quiere controlar por cuenta propia la experiencia de actualización, los canales, la distribución escalonada, la telemetría y la estrategia de recuperación, la respuesta es un actualizador propio.
  • Si se necesita un driver, es más seguro no plantear todo desde el principio en torno a MSIX.
  • Si se necesita una shell extension in-process del Explorador, conviene confirmar antes el alcance que cubre MSIX y las condiciones de versión del sistema operativo.

Resumido de forma más contundente, queda así.

  1. El registro en el sistema operativo es intenso → tendencia hacia MSI
  2. Se quiere package identity y modern packaging → MSIX
  3. Se quiere distribución simple per-user y actualización built-in → ClickOnce
  4. La distribución “solo colocar” es la prioridad máxima → xcopy
  5. Se está dispuesto a diseñar y operar la propia plataforma de actualización → actualizador propio

1.1 Términos que aparecen en el artículo

En el ámbito de la distribución muchos términos circulan tal cual en inglés, así que se listan antes de continuar.

Término Equivalente en español Significado
package identity ID de paquete Identificación única que el sistema operativo asigna a una app empaquetada. Sin ella, hay funciones de Windows que no se pueden usar
authoring Creación del instalador Trabajo de definir el contenido de un MSI. Se usa con un sentido cercano a «escribir el MSI»
custom action Acción personalizada Mecanismo para insertar, con código propio, procesos que el comportamiento estándar del instalador no cubre
ARP Lista de aplicaciones Abreviatura de Add/Remove Programs. Es la lista que aparece en «Aplicaciones instaladas» de Configuración o en «Programas y características» del Panel de control
clean install / clean uninstall Instalación / desinstalación limpia Estado en el que todo lo instalado queda correctamente colocado, y al desinstalar no quedan restos
repair Reparación Restaurar, mediante el propio mecanismo del instalador, un estado de instalación dañado
telemetry Medición del uso Mecanismo para recopilar y conocer el éxito de las actualizaciones y el uso de la aplicación
per-user / per-machine Por usuario / por máquina Instalar solo para ese usuario, o de forma común para todos los usuarios
shell extension Extensión del Explorador Componente que se integra en el Explorador de archivos, como el menú contextual o la visualización de iconos
unrestricted Sin restricciones Estado en el que, sin las limitaciones del empaquetado, se puede acceder libremente a archivos y al registro como un Win32 puro
side-by-side Coexistencia Mantener varias versiones instaladas simultáneamente en la misma máquina
staged rollout Distribución escalonada Distribuir la nueva versión no a todos a la vez, sino en porcentajes que se amplían poco a poco

1.2 Qué contiene la hoja de cálculo del principio

La hoja de cálculo de Excel colocada al principio sirve para aplicar y dejar registrado, en el propio proyecto, el criterio de decisión de este artículo. Existe una versión en japonés y otra en inglés, cada una con 2 hojas.

La hoja Planner está dividida en 3 bloques.

  1. Hoja de entrada: al completar los siguientes 7 elementos, queda registrada la primera opción candidata junto con su motivo
    • Alcance de la distribución … per-user / per-machine / ambos / por decidir
    • Elementos de integración con el SO … ninguno / servicio / driver / shell extension / registro COM / varios
    • package identity … necesario / innecesario / no se puede determinar
    • Requisito de instalación con usuario estándar … obligatorio / innecesario / según condiciones
    • Frecuencia de actualización … manual o poco frecuente / mensual / semanal / más frecuente
    • Entorno de destino … red cerrada/sin conexión / Windows nuevo y gestionado / Windows mixto con versiones antiguas / USB/campo
    • Notas sobre el tipo de app … escritorio .NET interno / producto comercial / utilidad / mixto
  2. Cómo distinguir entre candidatos: para cada uno de los 5 métodos, «la condición que hay que mirar primero con más fuerza» y «la condición que conviene descartar primero»
  3. Flujo de decisión: en qué orden revisar los puntos anteriores y hacia qué método tiende a inclinarse el resultado

La hoja Reference reproduce tal cual la tabla de decisión del capítulo 3 y la tabla comparativa del capítulo 4 de este artículo.

En resumen, es una forma de convertir los capítulos 3, 4 y 7 del artículo en algo que se puede completar para cada proyecto. Si con solo leer el artículo ya se llega a una conclusión, no hace falta descargarla. Úsela cuando quiera comparar varios proyectos o dejar constancia interna del motivo de la decisión.

2. Los cinco no compiten en el mismo terreno

Este punto es bastante importante.

MSI, MSIX, ClickOnce y xcopy tratan principalmente de cómo se instala. En cambio, el actualizador propio trata principalmente de cómo se asume la responsabilidad de la actualización.

Es decir, en la práctica resulta más claro pensarlo separado en dos capas.

Capa Candidatos principales Qué se decide
Instalación inicial MSI / MSIX / ClickOnce / xcopy Dónde se coloca, qué se registra, permisos, desinstalación
Actualización continua MSIX App Installer / ClickOnce / reemplazo manual / actualizador propio Comprobación de actualizaciones, origen de distribución, verificación de firma, rollback, canales, UI

Representado en un diagrama queda así. Las líneas punteadas indican «el medio de actualización al que ese método de instalación conecta de forma natural».

Dos capas de la distribución de apps de WindowsDiagrama que muestra que primero se decide cómo instalar la app (MSI, MSIX, ClickOnce, xcopy) y luego quién asume la actualización continua (MSIX App Installer, actualización built-in de ClickOnce, reemplazo manual o actualizador propio), y qué combinaciones conectan de forma natural.Aplicación de Windows a distribuirPrimero: cómo instalar (capa de instalación inicial)Después: quién asume la actualización (capa de actualización continua)MSIMSIXClickOncexcopyMSIX App InstallerActualización built-in de ClickOnceReemplazo manualActualizador propio

En ClickOnce y MSIX, al decidir la capa superior, la capa inferior queda prácticamente decidida también. En cambio, en MSI y xcopy es necesario decidir la capa inferior por separado. Es precisamente al elegir estos dos cuando «qué hacer con la actualización» tiende a quedar en el aire.

Por eso conviene pensar que el actualizador propio no es algo que se elige primero, sino algo que se añade cuando el método de distribución existente no cubre ciertos requisitos de actualización; así no habrá dudas más adelante.

3. Tabla de decisión de un vistazo

Antes que nada, se presenta la tabla de decisión más práctica.

Situación Qué elegir primero Motivo
Para todos los usuarios, con servicios, registro COM o configuración machine-wide MSI Es más seguro apoyarse directamente en el terreno de Windows Installer
Se parte de Windows 10/11 y se quiere clean install/uninstall, actualizaciones frecuentes y package identity MSIX Se adapta bien al modern packaging y al modelo de actualización
Se quiere distribuir fácilmente, per-user, una app empresarial de .NET ClickOnce Su modelo de actualización built-in es fácil de usar
Herramienta que funciona con solo colocarla, red cerrada, USB, sin permisos de administrador xcopy Evita en lo posible introducir el concepto de “install”
Producto comercial en el que se quiere controlar la experiencia de actualización y los canales Actualizador propio Ofrece más libertad que la actualización built-in
Se necesita un driver Hacia MSI o un instalador dedicado El driver package es un problema aparte y MSIX no es adecuado
Se necesita una shell extension in-process Hacia MSI o un instalador dedicado A partir de Windows 11 21H2, MSIX permite registrar cosas como un legacy context menu handler, pero hay que confirmar las condiciones

Lo más importante de esta tabla es no saltar directamente a un actualizador propio solo porque «hay actualizaciones».

4. Comparación por criterios

Criterio MSI MSIX ClickOnce xcopy Actualizador propio
Facilidad de instalación per-user ○ ○ ◎ ◎ ○
Facilidad de instalación per-machine ◎ ○ △ × ○
Actualización built-in △ ◎ ◎ × ◎
package identity × ◎ × × ×
Compatibilidad con servicios ◎ △ × × ○
Compatibilidad con drivers △ × × × ○
Compatibilidad con shell extensions ◎ △ × × ○
Distribución en red cerrada / sin conexión ◎ ○ ○ ◎ ◎
Costo de implementación y operación ○ ○ ◎ ◎ ×
Libertad en la experiencia de actualización △ ○ △ × ◎

Lo que hay que observar en esta tabla no es qué es lo más fuerte, sino qué genera menos fricción.

5. Para qué tipo de proyecto sirve cada uno

5.1 MSI

MSI es el punto de referencia cuando se quiere instalar, desinstalar y reparar correctamente una aplicación de escritorio tradicional de Windows.

Es especialmente adecuado para proyectos como estos.

  • Aplicaciones empresariales para todos los usuarios
  • Aplicaciones que incluyen un servicio de Windows
  • Aplicaciones con registro COM, asociación de archivos o configuración machine-wide
  • Productos que ya cuentan con una operación de instalador existente

La fortaleza de MSI es que resulta fácil expresar, siguiendo las convenciones propias de Windows, “cómo se instaló la app en el sistema operativo”.

Por otro lado, sus puntos débiles también son claros.

  • El authoring es, discretamente, bastante difícil
  • Si el upgrade o el patch se diseñan sin cuidado, suele generar problemas más adelante
  • Cuantas más custom actions se añaden, más frágil se vuelve
  • En productos con actualizaciones muy frecuentes, la experiencia de actualización tiende a volverse pesada

5.2 MSIX

MSIX es la opción cuando se quiere obtener modern packaging junto con una actualización y desinstalación limpias. También cobra mucho sentido cuando se necesita usar funciones de Windows que requieren package identity.

Es adecuado, entre otros, en estos casos.

  • Aplicaciones de escritorio que pueden asumir Windows 10/11 como requisito
  • Aplicaciones empresariales con una frecuencia de actualización relativamente alta
  • Aplicaciones que quieren usar funciones de Windows que dependen del package identity
  • Proyectos que quieren apoyarse en Intune o en App Installer

La fortaleza de MSIX es la limpieza de la actualización y la desinstalación.

Sin embargo, no todo encaja en MSIX. En particular, es más seguro confirmar antes estos cuatro puntos.

  • Shell extension in-process (a partir de Windows 11 21H2, MSIX permite registrar cosas como un legacy context menu handler, pero hace falta declararlo en el manifiesto y confirmar el sistema operativo de destino)
  • Driver
  • Supuestos Win32 antiguos y unrestricted
  • Configuraciones en las que no se quiere obtener package identity

Cada uno de estos cuatro puntos se confirma en una fuente distinta. En lugar de detenerse en «parece que MSIX no sirve», conviene decidir de antemano qué documento consultar para zanjar la duda; así se avanza más rápido.

Qué se quiere confirmar Documento a consultar Qué se puede saber
A partir de qué versión de Windows se puede usar «MSIX features and supported platforms» de Microsoft Learn Una tabla con la versión de SO compatible para cada función
Si se puede registrar una shell extension in-process «Support legacy context menus for packaged apps» de Microsoft Learn Las versiones de SO compatibles y cómo declararlo en el manifiesto
Si el propio instalador se puede convertir a MSIX «Prepare to package a desktop application» y «Know your installer» de Microsoft Learn La lista de configuraciones que no se pueden empaquetar y los puntos que conviene confirmar antes
Cómo queda una configuración que incluye servicios «Convert an installer that includes services» de Microsoft Learn Las condiciones y limitaciones de la conversión cuando hay servicios de por medio

Todos estos documentos están enlazados en las referencias del capítulo 9. A la hora de decidir, no se quede en «si es compatible», sino observe hasta «a partir de qué versión, y con qué tipo de declaración, resulta compatible». Si no se deja bien fijado este punto incluyendo la condición de versión de SO, más adelante puede aparecer el problema de que funcionaba en la máquina de pruebas pero no se instala en un Windows antiguo del entorno real.

5.3 ClickOnce

ClickOnce sigue siendo, incluso hoy, una opción muy sólida cuando se quiere hacer funcionar de forma rápida, per-user y con actualización incluida, una aplicación de escritorio de .NET para uso interno.

Es adecuado en situaciones como estas.

  • Aplicaciones empresariales de uso interno
  • Se quiere instalar con una cuenta de usuario estándar
  • Basta con distribuir por usuario
  • No se quiere invertir demasiado en construir la experiencia de actualización

En cambio, es más seguro no esperar de ClickOnce que cubra productos que tocan el sistema operativo en profundidad, ni que cumpla un papel de instalador que agrupe varios prerrequisitos.

5.4 xcopy

xcopy es deploy, no install. No hay registro en el registro de Windows, ni función de reparación, ni package identity. A cambio, si basta con colocarlo y ya está, es de una simplicidad prácticamente insuperable.

Su valor se aprecia en herramientas como estas.

  • Herramientas de diagnóstico
  • Herramientas de configuración de equipos
  • Herramientas de recolección de logs
  • Utilidades que se entregan al personal de campo por USB
  • Casos en los que se quiere mantener varias versiones coexistiendo (side-by-side)

La fortaleza de xcopy es que la forma en que puede fallar es fácil de entender. Es sencillo operar reemplazando la carpeta entera, y volver a la versión anterior si hace falta revertir.

Por supuesto, también tiene puntos débiles.

  • Start menu / ARP / repair
  • Asociación de archivos / servicio / shell extension / driver
  • Actualización built-in

5.5 Actualizador propio

Un actualizador propio es, más que una elección de libertad, una elección de responsabilidad.

Vale la pena plantearlo cuando existen requisitos como estos.

  • Frecuencia de actualización alta
  • Se quiere mantener canales del tipo stable/beta/preview
  • Se quiere controlar la distribución escalonada o la tasa de rollout
  • Se quiere controlar con detalle la descarga en segundo plano, las notificaciones y las franjas horarias de mantenimiento
  • Se quiere gestionar por cuenta propia la telemetría de actualizaciones y la recuperación ante fallos

Las ventajas son grandes, pero también lo es el precio a pagar.

  • Verificación de firmas
  • Manifiesto de distribución
  • Reintentos / resume
  • Soporte de proxy, firewall y redes cerradas
  • Rollback
  • Recuperación de actualizaciones dañadas
  • Actualización del propio actualizador

Es decir, lo que aumenta no es la libertad, sino la responsabilidad.

5.6 Después de decidir el método, qué investigar a continuación

Aunque se decida «vamos con MSI», si no se sabe qué investigar a partir de ahí, el trabajo se detiene. A continuación se listan las puertas de entrada más representativas. En ningún caso se trata de «use esto», sino de algo cuyo nombre conviene conocer de antemano una vez elegido ese método.

Método decidido Qué investigar a continuación Nota
MSI WiX Toolset Conjunto de herramientas de código abierto para escribir MSI en XML. Es la puerta de entrada estándar al authoring de MSI
MSI Advanced Installer, InstallShield Herramientas comerciales de creación de MSI centradas en GUI. Útiles si se quiere componer custom actions y el diseño del upgrade desde una interfaz gráfica
No hace falta MSI, basta con un EXE Inno Setup, NSIS Herramientas que crean instaladores EXE con formato propio, no MSI. No se apoyan en el terreno de Windows Installer
MSIX MSIX Packaging Tool, makeappx.exe, signtool.exe Herramientas de conversión desde instaladores existentes, y las herramientas de empaquetado y firma del Windows SDK
MSIX Windows Application Packaging Project Tipo de proyecto en Visual Studio para convertir a MSIX un proyecto existente
ClickOnce El asistente de publicación de Visual Studio, mage.exe Genera la publicación y el manifest. El comportamiento de la actualización se decide con las opciones del momento de publicar
Actualizador propio Squirrel.Windows, Velopack, WinSparkle, NetSparkle Bibliotecas que proporcionan el esqueleto de la actualización. Antes de decidir si adoptarlas, compárelas por cómo gestionan la verificación de firmas y el rollback

Aquí conviene tener presente que elegir una herramienta y elegir un método son cosas distintas. Por ejemplo, Inno Setup es fácil de manejar, pero lo que produce no es un MSI, así que no encaja en operaciones que dan por hecho Windows Installer, como la distribución de software mediante directiva de grupo o la reparación con msiexec. Si el motivo por el que se eligió MSI en el apartado 5.1 era precisamente ese, la herramienta también debe ajustarse a él.

6. Puntos que suelen generar dudas

6.1 ¿Se necesita package identity?

Si lo que se necesita son funciones de Windows que dan por supuesto el package identity, el valor de MSIX aumenta de golpe.

En cambio, si se da alguno de estos casos,

  • Acceso unrestricted al sistema de archivos
  • Acceso unrestricted al registro
  • Libertad en la elevación de privilegios y en el modelo de procesos
  • Se quiere conservar tal cual un supuesto Win32 antiguo

lo natural es inclinarse por un método más cercano a unpackaged.

6.2 ¿Hay servicio, driver o shell extension?

Estos tres elementos hacen que el método de distribución se vuelva mucho más pesado de golpe.

  • Driver: no es adecuado en MSIX
  • Shell extension in-process: no es adecuada en MSIX
  • Servicio de Windows: es natural en MSI; en MSIX también puede considerarse, de forma condicional

Cuantos más elementos ligados en profundidad al sistema operativo haya, más pasa el tema principal de ser una distribución que parece simple a ser si se puede instalar, actualizar y desinstalar correctamente.

6.3 ¿Per-user o per-machine?

Si se avanza dejando esto ambiguo, más adelante siempre acaba generando conflictos.

  • Se prefiere per-user
    • ClickOnce
    • xcopy
    • Parte de los casos de MSIX
  • Se prefiere per-machine
    • MSI
    • MSIX, si se cumplen las condiciones

«Querer instalar sin permisos de administrador» y «querer que todos los usuarios lo usen desde el mismo lugar» no son la misma cosa.

6.4 Frecuencia de actualización y responsabilidad operativa

En términos generales, según la frecuencia de actualización, queda así.

  • De trimestral a mensual: MSI ya funciona bien
  • De mensual a semanal: MSIX o ClickOnce resultan bastante más cómodos
  • De semanal a diario: aparecen motivos para plantearse un actualizador propio
  • Basta con actualización manual, o el control lo lleva quien despliega: xcopy también es suficiente

El método de distribución es, a la vez, una elección tecnológica y un diseño operativo.

6.5 Distribución en red cerrada y sin conexión

En redes cerradas, con frecuencia la simplicidad gana a un auto-update elegante.

  • xcopy es fuerte
  • MSI también es fuerte
  • ClickOnce también se puede usar mediante un file share o un medio extraíble
  • MSIX también funciona según cómo se use App Installer

Sin embargo, si se actualiza con frecuencia en una red cerrada, mientras no se decida también «quién coloca la nueva versión, dónde, y qué se hace con la versión anterior», elegir solo el método no evita que la operación acabe descontrolándose.

7. Las 6 preguntas finales para cuando hay dudas

  1. ¿Basta con que la app funcione solo para el current user, o hace falta instalarla machine-wide?
  2. ¿Hay servicio, driver, shell extension o registro COM?
  3. ¿Se usan funciones de Windows que requieren package identity?
  4. ¿Se quiere instalar solo con usuario estándar?
  5. ¿La frecuencia de actualización es mensual, semanal o más alta?
  6. ¿El entorno de destino es una red cerrada, y están alineadas las versiones de SO?

Con solo responder estas 6 preguntas, en general ya se ve hacia dónde converge la decisión.

  • Si la 2 es «sí» → empezar a pensar por el lado de MSI
  • Si la 3 es «sí» → priorizar MSIX
  • Si la 1 es current user, la 4 es «sí» y es una app de escritorio de .NET → ClickOnce es una opción sólida
  • Si la 4 es «sí», la 2 es «no» y basta con una operación de solo colocar → xcopy es una opción sólida
  • Si la 5 es alta y se quiere controlar la experiencia de actualización como valor del producto → incluir un actualizador propio entre los candidatos a comparar

8. Resumen

El método de distribución de una aplicación de Windows se puede resumir bastante bien en esta frase.

Decidir por separado cómo hacer que funcione la instalación inicial y quién asume la responsabilidad de la actualización continua.

Sobre esa base, el criterio práctico general queda así.

  • MSI: aplicación de escritorio tradicional que se instala en profundidad en el sistema operativo
  • MSIX: aplicación que quiere obtener package identity junto con modern packaging/update
  • ClickOnce: distribuir y actualizar con facilidad una aplicación empresarial de .NET per-user
  • xcopy: herramienta autocontenida que basta con colocar
  • Actualizador propio: producto para el que se está dispuesto a diseñar y operar la propia actualización

Y lo más importante es esto.

  • Si hay driver, shell extension o service, el método de distribución no se decide por la apariencia final, sino por el método de integración con el sistema operativo
  • Si se necesita package identity, MSIX cobra mucho sentido
  • El actualizador propio es el último recurso, no la primera opción
  • En redes cerradas, la simplicidad suele ganarle a la inteligencia

Si todavía hay dudas, fijar de antemano aunque solo sean estos tres puntos —per-user o per-machine, qué se registra en el sistema operativo y cuál es la frecuencia de actualización— ya hace avanzar bastante la conversación.

9. Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Consultoría técnica y revisión de diseño

MSI, MSIX, ClickOnce, xcopy y el actualizador propio no son una cuestión de preferencia de instalador, sino un diseño de responsabilidad de actualización e integración con el sistema operativo, por lo que revisar la separación de requisitos desde el inicio facilita la decisión.

Ver el servicio Contactar

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Cuál es la diferencia entre MSI y MSIX?
MSI es el formato de instalador tradicional de Windows: encaja bien con implementaciones per-machine, servicios de Windows, registro COM y shell extensions, es decir, con instalaciones que tocan el sistema operativo en profundidad, y permite expresar install, uninstall y repair siguiendo las convenciones propias de Windows. MSIX es el modern packaging pensado para Windows 10/11, y su fortaleza está en el clean install, el clean uninstall, las actualizaciones frecuentes y el package identity. Por otro lado, MSIX no es adecuado para drivers, el soporte de shell extensions in-process es condicional a partir de Windows 11 21H2, y tampoco encaja con supuestos Win32 antiguos y unrestricted. Si el registro en el sistema operativo es intenso, el punto de partida es MSI; si se quiere obtener package identity y limpieza en las actualizaciones, el punto de partida es MSIX.
¿Debería elegir MSIX o ClickOnce?
Si lo que se busca es distribuir con facilidad una app empresarial de .NET per-user y mantenerla actualizada automáticamente, ClickOnce sigue siendo, incluso hoy, una opción muy sólida: su modelo de actualización built-in es fácil de usar, permite instalar con una cuenta de usuario estándar y no exige construir una experiencia de actualización a medida. Por otro lado, si se necesita usar funciones de Windows que requieren package identity, se prioriza el clean install/uninstall, o se quiere apoyarse en Intune o en App Installer, MSIX es la opción más sólida. Ninguna de las dos es adecuada para productos que tocan el sistema operativo en profundidad, así que si hay servicios o drivers de por medio conviene empezar a pensar por el lado de MSI.
¿ClickOnce todavía se puede usar? ¿No es una tecnología antigua?
Sí, todavía se puede usar, y en los escenarios para los que está pensado sigue siendo una opción muy sólida. Es eficaz cuando se quiere distribuir rápidamente una app de escritorio de .NET para uso interno, por usuario (per-user), manteniendo permisos de usuario estándar, y mantenerla al día con su modelo de actualización built-in. En cambio, es más seguro no esperar de ClickOnce que cubra productos que tocan el sistema operativo en profundidad, como servicios de Windows, drivers o shell extensions, ni que asuma un papel de instalador que agrupe varios prerrequisitos. En cuanto a la frecuencia de actualización, para ciclos de mensuales a semanales, tanto ClickOnce como MSIX permiten mantenerse al día con bastante facilidad.
¿En qué casos conviene plantearse un actualizador propio?
Un actualizador propio no es lo primero que se debe elegir, sino algo que se añade cuando el método de distribución existente no cubre ciertos requisitos de actualización. Vale la pena plantearlo cuando existen requisitos como una frecuencia de actualización alta, la necesidad de mantener canales del tipo stable/beta/preview, el control de la distribución escalonada o de la tasa de rollout, o el querer gestionar por cuenta propia la telemetría de actualizaciones y la recuperación ante fallos. Sin embargo, esto implica asumir la responsabilidad de diseñar y operar uno mismo la verificación de firmas, el manifiesto de distribución, los reintentos, el rollback, la recuperación de actualizaciones dañadas e incluso la actualización del propio actualizador, así que debe entenderse como una opción que aumenta la responsabilidad, no la libertad.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog