¿Qué es ClickOnce? - Cómo funciona, actualizaciones y en qué casos conviene o no usarlo, desde la práctica

Cuando se habla de distribuir aplicaciones de escritorio Windows en .NET, a la sombra de MSI y MSIX, hay un nombre que aparece una y otra vez de forma discreta: ClickOnce.

Sin embargo, si aquí se decide de forma superficial que

• ya es una tecnología antigua y no se va a usar más, o
• al contrario, que parece sencilla y con ClickOnce se puede resolver cualquier cosa,

lo normal es errar el tiro.

ClickOnce no es un instalador universal capaz de hacerlo todo. Por otro lado, para casos en los que se quiere distribuir una aplicación de negocio .NET de uso interno a usuarios estándar y gestionar hasta la actualización con bajo coste, sigue siendo una opción bastante sólida.

En este artículo organizamos, desde una perspectiva práctica y con bastantes diagramas Mermaid, qué es ClickOnce, cómo funciona, en qué destaca y dónde se le exige demasiado. El contenido se basa principalmente en la información de Microsoft Learn disponible a fecha de abril de 2026.

Los diagramas son esquemáticos. En un entorno Markdown compatible con Mermaid se muestran como figuras.

Público objetivo

Este artículo está dirigido a desarrolladores que están evaluando cómo distribuir una aplicación de escritorio Windows (WinForms / WPF) en .NET y a los responsables de sistemas que operan esa distribución y sus actualizaciones. Se asume que todavía no se ha decidido si usar ClickOnce, así que primero se presentan los criterios de decisión, y el procedimiento real de publicación se deja para el apartado 6.4.

Términos que conviene tener claros de antemano

En el cuerpo del artículo aparecen varios términos que se dejan en inglés. Para no tropezar con ellos en su primera aparición, los resumimos aquí de antemano.

Índice

1. Antes que nada, la conclusión
2. Qué es ClickOnce
3. Los elementos que componen ClickOnce
4. El flujo desde la instalación hasta el inicio
5. Cómo funcionan las actualizaciones
6. Los puntos fuertes de ClickOnce
7. Casos en los que conviene usarlo
8. Casos en los que no conviene usarlo
9. Puntos donde es fácil tropezar en la práctica
10. Resumen
11. Artículos relacionados
12. Referencias

1. Antes que nada, la conclusión

En una frase, ClickOnce es una tecnología de distribución para repartir aplicaciones de escritorio Windows en .NET por usuario, de forma sencilla, y gestionar todo el ciclo incluyendo la actualización automática.

Conviene, por ejemplo, en casos como estos:

• Aplicaciones de negocio de uso interno como WinForms / WPF
• Se quiere instalar con usuarios estándar
• Basta con distribución per-user
• Se quiere contar con actualización built-in
• Basta con un sitio web o una carpeta compartida como vía de distribución

Por el contrario, si los requisitos son estos, es más seguro pensar desde el principio en otro método:

• Instalación machine-wide para todos los usuarios
• Servicios de Windows, drivers, shell extensions in-process, registro COM denso
• Se necesita package identity
• Se quiere controlar canales de actualización, distribución escalonada y una UX de rollback propia
• El instalador tiene una responsabilidad grande de integrarse profundamente en el sistema operativo

En resumen, ClickOnce es un método fuerte en distribución y actualización sencillas, pero que no conviene para proyectos con una integración pesada con el sistema operativo.

Ver el panorama de un vistazo primero

flowchart TD
    accTitle: Árbol de decisión para elegir un método de distribución en Windows
    accDescr: Diagrama que muestra cómo, a partir de la necesidad de integración profunda con el sistema operativo, del tipo de app y de si basta con distribución per-user y actualización integrada, se llega a ClickOnce o a otras alternativas
    A["Quiero distribuir una app de Windows"]
    B{"¿Hay un requisito de integración profunda con el SO?"}
    C["Pensar desde MSI / MSIX"]
    D{"¿Es una app de escritorio Windows en .NET<br/>y basta con distribución per-user?"}
    E{"¿Se quiere distribuir a usuarios estándar?"}
    F{"¿Basta con la actualización built-in?"}
    G["ClickOnce es una opción sólida"]
    H["Comparar también xcopy / updater propio"]

    A --> B
    B -- Sí --> C
    B -- No --> D
    D -- No --> H
    D -- Sí --> E
    E -- No --> H
    E -- Sí --> F
    F -- Sí --> G
    F -- No --> H

2. Qué es ClickOnce

ClickOnce es una tecnología de distribución de aplicaciones de Windows de Microsoft. Oficialmente se describe como una tecnología de distribución de aplicaciones basadas en Windows que se pueden instalar y ejecutar con una intervención mínima del usuario, y que pueden actualizarse a sí mismas.

Aquí es importante no considerar ClickOnce simplemente como «un tipo de instalador».

En realidad, ClickOnce es un modelo de distribución que se encarga conjuntamente de lo siguiente:

• Qué versión distribuir
• Qué archivos incluye esa versión
• Cómo detectar la actualización
• De dónde obtener la actualización
• Cómo conservarla en un lugar seguro por usuario
• Cómo verificar la integridad al iniciar

El núcleo de ClickOnce no es setup.exe en sí, sino que se acerca más a la realidad verlo como un mecanismo centrado en los manifiestos que gestiona conjuntamente la distribución, la actualización y la administración de la caché.

En el .NET actual, ClickOnce en sí sigue siendo una opción normal a considerar. En Visual Studio se usa la herramienta Publish para .NET Core 3.1 y .NET 5 en adelante, y si se manejan los manifiestos manualmente se recurre a dotnet-mage.exe.

Las responsabilidades que cubre ClickOnce

flowchart LR
    accTitle: Responsabilidades que cubre ClickOnce
    accDescr: Diagrama que muestra cómo ClickOnce se encarga de decidir qué versión distribuir, de dónde obtener las actualizaciones, de conservar los archivos en un lugar seguro por usuario y de verificar la integridad antes de iniciar la app
    CO["ClickOnce"]
    V["Qué versión distribuir"]
    U["De dónde obtener la actualización"]
    S["Conservarla en un lugar seguro por usuario"]
    I["Verificar la integridad e iniciar"]

    CO --> V
    CO --> U
    CO --> S
    CO --> I

3. Los elementos que componen ClickOnce

Para entender el funcionamiento de ClickOnce, el camino más rápido es dominar estos cuatro elementos.

Lo que resulta central aquí son los dos tipos de manifiesto.

• El manifiesto de implementación expresa «cuál es, ahora mismo, la versión correcta de esta app»
• El manifiesto de aplicación expresa «qué contiene esa versión»

Es decir, la comprobación de actualizaciones de ClickOnce empieza siempre por el manifiesto de implementación, y lo que realmente se descarga lo determina el manifiesto de aplicación.

La relación entre los cuatro elementos

flowchart LR
    accTitle: Relación entre los cuatro elementos de ClickOnce
    accDescr: Diagrama que muestra el flujo desde setup.exe, pasando por el manifiesto de implementación y el manifiesto de aplicación, hasta los archivos de la app y la caché de ClickOnce
    Setup["setup.exe<br/>opcional<br/>Comprobación / instalación de requisitos previos"]
    Deploy["Manifiesto de implementación (.application)<br/>Qué versión distribuir<br/>Ubicación / condiciones de actualización"]
    App["Manifiesto de aplicación (*.exe.manifest)<br/>Contenido de esa versión<br/>Lista de archivos / hash / punto de entrada"]
    Files["App en sí<br/>exe / dll / config / datos"]
    Cache["Caché de ClickOnce<br/>por usuario / por aplicación"]

    Setup --> Deploy
    Deploy --> App
    App --> Files
    Files --> Cache

setup.exe no es el protagonista, sino un apoyo

setup.exe suele llamar mucho la atención, pero no es el protagonista de ClickOnce. Es un papel de apoyo que comprueba e instala los requisitos previos.

Por ejemplo, cuando hace falta el runtime .NET correcto o componentes redistribuibles adicionales, setup.exe los prepara primero, y solo después empieza la distribución propia de ClickOnce.

4. El flujo desde la instalación hasta el inicio

Si se simplifica de forma decidida el flujo de ClickOnce con fines prácticos, queda así:

1. El usuario abre setup.exe o el archivo .application publicado en una página web o carpeta compartida
2. Si la configuración usa setup.exe, se comprueban los requisitos previos y se instala lo que falte
3. ClickOnce lee el manifiesto de implementación
4. Lee el manifiesto de aplicación al que apunta el manifiesto de implementación
5. Obtiene los archivos necesarios y los coloca en la caché de ClickOnce de ese usuario
6. Si la configuración permite el uso sin conexión, se registra en el menú Inicio o en la lista de aplicaciones
7. A partir de ahí, la aplicación se inicia bajo la gestión de ClickOnce

El punto clave es que no se trata de la idea de colocarla en Program Files como haría un instalador normal.

Una aplicación ClickOnce entra en un área de caché segura por usuario, y queda separada por aplicación y por usuario. Esta es una gran característica de ClickOnce.

De la instalación al primer inicio

sequenceDiagram
    accTitle: De la instalación al primer inicio
    accDescr: Diagrama de secuencia que muestra cómo el usuario abre setup.exe o el archivo .application, se lee el manifiesto de implementación, este remite al manifiesto de aplicación, se obtienen los archivos hacia la caché de ClickOnce y finalmente se coloca e inicia la app
    participant U as Usuario
    participant P as setup.exe / .application
    participant D as Manifiesto de implementación
    participant A as Manifiesto de aplicación
    participant C as Caché de ClickOnce
    participant X as App en sí

    U->>P: Abre
    Note over U,P: En una configuración con setup.exe,<br/>primero se comprueban los requisitos previos
    P->>D: Obtiene y lee
    D->>A: Consulta la versión objetivo
    A->>C: Obtiene los archivos necesarios y verifica su integridad
    C->>X: Coloca e inicia

Solo en línea y con uso sin conexión

ClickOnce tiene, a grandes rasgos, dos formas de presentarse.

• Solo en línea: se ejecuta desde la ubicación publicada como punto de partida. Da poca sensación de instalación permanente
• Con uso sin conexión: se instala en el equipo del usuario y también se puede iniciar desde el menú Inicio

En las aplicaciones de negocio de uso interno, en la práctica se suele elegir la opción con uso sin conexión.

flowchart LR
    accTitle: Solo en línea frente a con uso sin conexión
    accDescr: Diagrama que compara el modo solo en línea, que se ejecuta desde la ubicación publicada y da poca sensación de instalación permanente, con el modo de uso sin conexión, que se instala en el área del usuario, se registra en el menú Inicio, se inicia localmente y comprueba actualizaciones en el momento indicado
    subgraph Online[Solo en línea]
        O1["Se inicia desde la ubicación publicada"]
        O2["Poca sensación de instalación permanente"]
        O3["Tiende a requerir conexión de red"]
        O1 --> O2 --> O3
    end

    subgraph Offline[Con uso sin conexión]
        F1["Se instala en el área del usuario"]
        F2["Se registra en el menú Inicio"]
        F3["Se inicia localmente"]
        F4["Comprueba actualizaciones en el momento indicado"]
        F1 --> F2 --> F3 --> F4
    end

5. Cómo funcionan las actualizaciones

La fortaleza más clara de ClickOnce sigue siendo que su modelo de actualización es built-in.

La comprobación de actualizaciones empieza por el manifiesto de implementación

Una aplicación ClickOnce lee el manifiesto de implementación y comprueba

• si hay una versión nueva,
• si la actualización es obligatoria, y
• de dónde obtenerla.

A partir de ahí, cuando empieza la actualización, ClickOnce usa file patching para evitar descargas redundantes. En la práctica resulta más fácil entenderlo pensando que compara el manifiesto de aplicación de la nueva versión con el de la versión actual y va a buscar solo los archivos que cambiaron.

En cuanto al criterio para comprobar actualizaciones, resulta claro organizarlo en estos tres patrones:

• Comprobar antes de iniciar
• Comprobar después de iniciar
• Que la propia app disponga de una interfaz de «comprobar actualización»

Sin embargo, hay diferencias entre .NET Framework y .NET 5 en adelante en cuanto a las API disponibles y la interfaz de configuración. Es importante no ponerse a implementar solo con lo que se recuerda de artículos antiguos sobre ClickOnce.

El flujo de la actualización

flowchart TD
    accTitle: Flujo de la actualización de ClickOnce
    accDescr: Diagrama que muestra cómo, al iniciar la app, se comprueba el manifiesto de implementación y, si hay una versión nueva, se obtiene el manifiesto de aplicación, se comparan firmas y hashes, se descargan solo los cambios, se establece la nueva versión y se cambia a ella, reiniciando si es necesario
    Start["Inicio de la app"]
    Check["Comprobar el manifiesto de implementación"]
    New{"¿Hay una versión nueva?"}
    Run["Se inicia tal cual"]
    Get["Obtener el manifiesto de aplicación de la nueva versión"]
    Compare["Comparar firmas / hashes de archivos"]
    Download["Obtener lo que cambió"]
    Switch["Establecer la nueva versión y cambiar a ella"]
    Restart["Si hace falta, reiniciar y ejecutar la nueva versión"]

    Start --> Check --> New
    New -- No --> Run
    New -- Sí --> Get --> Compare --> Download --> Switch --> Restart

También conviene tener presente que, si no hay conexión de red, la aplicación se ejecuta tal cual sin comprobar actualizaciones; recordar esta premisa evita confusiones en la práctica.

Las versiones se conservan separadas

ClickOnce se acerca más a la idea de establecer correctamente la nueva versión antes de cambiar a ella, más que a «sobrescribir los archivos actuales in situ».

Además, la caché de ClickOnce conserva la versión actual y la anterior por separado. Esta es una de las razones por las que resulta difícil ensuciar el entorno y fácil evitar conflictos entre versiones.

flowchart TB
    accTitle: Las versiones se conservan separadas por usuario
    accDescr: Diagrama que muestra cómo la caché de ClickOnce del usuario A y la del usuario B conservan cada una, por separado, su versión anterior, su versión actual y su configuración y datos
    subgraph UA[Caché de ClickOnce del usuario A]
        APrev["Versión anterior"]
        ACur["Versión actual"]
        AData["Configuración / datos"]
    end

    subgraph UB[Caché de ClickOnce del usuario B]
        BPrev["Versión anterior"]
        BCur["Versión actual"]
        BData["Configuración / datos"]
    end

    APrev --> ACur
    AData --> ACur
    BPrev --> BCur
    BData --> BCur

Aquí hay dos puntos clave:

• Es difícil que se mezcle con otro usuario
• Es difícil que entre en conflicto con otra versión

Esta estructura es un factor importante para que resulte fácil evitar el llamado DLL Hell.

6. Los puntos fuertes de ClickOnce

Lo bueno de ClickOnce no se limita a que «se puede distribuir fácilmente». Lo que resulta útil en la práctica es, más o menos, lo siguiente.

6.1 Es fácil distribuir a usuarios estándar

ClickOnce encaja bien con una distribución basada en per-user, y lo importante es que resulta fácil instalarla sin permisos de administrador.

En las aplicaciones de negocio internas es habitual la siguiente situación:

• Los usuarios son usuarios estándar
• No se quiere pedir la instalación al departamento de TI cada vez
• Pero tampoco se quiere dejar de actualizar

En estas condiciones, ClickOnce resulta bastante fuerte. La premisa de «instalarse de forma segura en el área de cada usuario, incluyendo la actualización» encaja desde el principio.

6.2 No hace falta implementar la actualización por cuenta propia

Crear una actualización automática desde cero implica más trabajo del que parece a simple vista:

• Comprobación de nueva versión
• Descarga
• Verificación de integridad
• Cambio respecto a la versión anterior
• Recuperación en caso de fallo
• Interfaz de actualización
• Gestión del propio updater

ClickOnce ya cubre buena parte de todo esto con su modelo existente.

flowchart LR
    accTitle: Responsabilidades de un updater propio frente a las que asume ClickOnce
    accDescr: Diagrama que compara las cinco responsabilidades de un updater propio (detección de nueva versión, descarga, verificación de integridad, cambio de versión y recuperación tras fallo) con las tres que ClickOnce ya resuelve (detección de nueva versión, obtención y verificación, y cambio de versión)
    subgraph Custom[Responsabilidades de un updater propio]
        C1["Detección de nueva versión"]
        C2["Descarga"]
        C3["Verificación de integridad"]
        C4["Cambio de versión"]
        C5["Recuperación tras fallo"]
        C1 --> C2 --> C3 --> C4 --> C5
    end

    subgraph Click[Responsabilidades que asume ClickOnce]
        K1["Detección de nueva versión"]
        K2["Obtención y verificación"]
        K3["Cambio de versión"]
        K1 --> K2 --> K3
    end

Por supuesto, no se puede hacer absolutamente todo con libertad. Pero la «actualización suficiente» que necesita una aplicación de uso interno resulta bastante fácil de cubrir.

6.3 Las aplicaciones no suelen entrar en conflicto entre sí

Las aplicaciones ClickOnce se separan por aplicación, por usuario y por versión.

Por eso resulta difícil que ocurran los clásicos incidentes de siempre, como

• conflictos de versión en componentes compartidos,
• que se sobrescriba una DLL en algún lugar y se rompa otra aplicación, o
• que el entorno se ensucie por reemplazos manuales.

6.4 Es fácil publicar desde Visual Studio

ClickOnce encaja bien con la función de publicación de Visual Studio, y otra ventaja es que la distancia hasta la distribución es corta.

Antes de meterse en otra dificultad como la autoría de un MSI, resulta fácil crear el flujo de

• publicar primero,
• distribuir primero,
• poner en marcha la actualización primero, y
• obtener primero la retroalimentación del terreno.

El procedimiento mínimo de publicación

Quedarse solo en los conceptos deja la distancia demasiado grande, así que aquí dejamos también la operación real. Para aplicaciones de escritorio Windows en .NET Core 3.1 / .NET 5 en adelante, no se usa el antiguo Publish Wizard sino la herramienta Publish. Aplica a Visual Studio 2019 versión 16.8 en adelante y a Visual Studio 2022. Las aplicaciones .NET Framework usan otro asistente, así que el procedimiento es distinto.

1. En el Explorador de soluciones, haga clic con el botón derecho en el proyecto y seleccione «Publicar». Desde el menú, es «Compilar» y luego «Publicar».
2. Si ya existe un perfil de publicación, se abre la página «Publicar»; seleccione «Nuevo».
3. En la página para elegir el tipo de destino de publicación, seleccione «Carpeta».
4. En la siguiente página, «Destino específico», seleccione «ClickOnce».
5. Escriba la ruta de destino de la publicación o selecciónela con «Examinar». Este es el lugar donde se vuelcan los artefactos de la compilación.
6. En la página «Ubicación de instalación», indique desde dónde va a instalar el usuario. Que esto pueda ser distinto del destino de volcado del paso 5 es lo que más suele hacer tropezar al principio. Elija entre sitio web, recurso compartido UNC o CD / DVD / USB.
7. En la página «Configuración», decida si permite el uso sin conexión. Si lo permite, la app aparece en el menú Inicio y se actualiza automáticamente cuando se publica una versión nueva. De forma predeterminada, el origen de la actualización es el mismo que la ubicación de instalación. Si se quiere usar otro lugar como origen de actualización, se indica desde la configuración de actualización de esta página. La ubicación indicada aquí es el deploymentProvider del apartado 9.6.
8. Desde el enlace en la parte superior de esa misma página «Configuración» se pueden indicar los archivos que se incluyen en la distribución (Application Files), los paquetes de requisitos previos a instalar (Prerequisites) y otras opciones. Aquí también se define la versión de publicación y si se incrementa automáticamente en cada publicación.
9. En la página «Firma de manifiestos», indique si se firman los manifiestos y qué certificado se usa. Esto se conecta con lo tratado en el apartado 9.5.
10. En la página «Configuración» (de compilación), elija la configuración de compilación, si la app depende del framework o es autocontenida, y el identificador de runtime de destino.
11. En «Finalizar» se guarda el perfil, y al pulsar «Publicar» en la página «Resumen» se ejecutan la compilación y la publicación. A partir de la segunda vez, basta con pulsar «Publicar» en esta misma página.

Conviene saber de antemano, en la práctica, estos dos puntos:

• La versión de publicación es independiente para cada perfil de ClickOnce. Si se separan los perfiles de verificación y de producción, hay que gestionar el número de versión de cada uno de forma consciente.
• La herramienta Publish crea un perfil de publicación llamado .pubxml. Al compilar desde la línea de comandos con MSBuild, se indica este .pubxml. Este es el punto de entrada al integrarlo en CI.

6.5 El traspaso de configuración también es relativamente sencillo

Si se usa el proveedor de configuración de aplicación predeterminado, ClickOnce cuenta con un mecanismo para fusionar la configuración de la versión anterior en la nueva al actualizar.

Sin embargo, esto presupone el proveedor de configuración predeterminado. Si se usa un guardado de configuración propio, un proveedor propio o se cambia el destino de guardado, evidentemente ya no basta con esto tal cual.

7. Casos en los que conviene usarlo

Los proyectos para los que ClickOnce resulta especialmente adecuado son, más o menos, los siguientes.

Si se dan ejemplos concretos con los que encaja bien en la práctica, serían estos:

• Aplicaciones internas de captura de datos de negocio
• Herramientas de escritorio de negocio como presupuestos, pedidos e inventario
• Aplicaciones auxiliares para configurar equipos
• Clientes internos distribuidos a oficinas de ventas, fábricas y back office
• Aplicaciones que necesitan actualización pero no justifican crear un updater dedicado

En este tipo de aplicaciones, simplificar la distribución y la actualización es un valor en sí mismo. ClickOnce responde a ese valor de forma directa.

El árbol de decisión sobre si conviene o no

flowchart TD
    accTitle: Árbol para decidir si ClickOnce conviene
    accDescr: Diagrama que, a partir de si es una app de escritorio .NET, de si basta con distribución per-user, de si se quiere instalar para usuarios estándar, de si se puede distribuir por web o carpeta compartida y de si no hace falta una experiencia de actualización muy elaborada, concluye si ClickOnce es una opción sólida o si conviene comparar otros métodos
    S["Ordenar los requisitos"]
    Q1{"¿Es una app de escritorio .NET<br/>como WinForms / WPF?"}
    Q2{"¿Basta con distribución per-user?"}
    Q3{"¿Se quiere instalar para usuarios estándar?"}
    Q4{"¿Se puede distribuir por web o carpeta compartida?"}
    Q5{"¿No hace falta elaborar mucho la UX de actualización?"}
    G["ClickOnce es bastante sólido"]
    O["Comparar otros métodos"]

    S --> Q1
    Q1 -- No --> O
    Q1 -- Sí --> Q2
    Q2 -- No --> O
    Q2 -- Sí --> Q3
    Q3 -- No --> O
    Q3 -- Sí --> Q4
    Q4 -- No --> O
    Q4 -- Sí --> Q5
    Q5 -- Sí --> G
    Q5 -- No --> O

8. Casos en los que no conviene usarlo

Por otro lado, también están claros los casos en los que es mejor no forzar el uso de ClickOnce.

8.1 Se necesita instalación machine-wide

ClickOnce se basa fundamentalmente en per-user.

• Se quiere instalar de forma común para todos los usuarios
• Se quiere instalar presuponiendo Program Files
• Se quiere instalar y gestionar a nivel de todo el equipo

En estos casos resulta más natural usar MSI u otra opción, en lugar de ClickOnce.

8.2 Windows service / driver / shell extension / registro COM denso

Todo esto entra en el terreno de tocar profundamente el sistema operativo.

• Servicios de Windows
• Drivers
• Shell extensions in-process
• Configuraciones que presuponen registro COM mecánico

Cuando el requisito llega a este nivel, se sale del planteamiento de «distribuir de forma ligera» de ClickOnce.

8.3 Se quiere package identity

Una de las razones para elegir MSIX es el requisito de querer obtener package identity.

ClickOnce no va en esa dirección. Si lo que se necesita es el modern packaging o funciones de Windows que presuponen package identity, es mejor priorizar MSIX.

8.4 Se quiere controlar la UX de actualización o los canales de distribución como producto

Por ejemplo, cuando se llega a querer

• canales stable / beta / preview,
• distribución escalonada,
• ajustar el porcentaje de rollout viendo la telemetría,
• un control fino de la descarga en segundo plano,
• una estrategia de rollback propia, o
• un ciclo de vida complejo para el propio updater,

la actualización built-in de ClickOnce se queda corta.

8.5 Herramientas para las que basta con “colocar y listo”

Al contrario, también hay casos en los que basta con algo más sencillo.

• Funciona con solo colocar la carpeta entera
• Basta con reemplazar manualmente al actualizar
• Se entrega por USB
• Es un entorno cerrado donde la simplicidad es la prioridad

En estos casos, la distribución por xcopy puede tener menos fricción.

Qué requisitos llevan a otro método

flowchart LR
    accTitle: Qué requisitos llevan a otro método de distribución
    accDescr: Diagrama que asocia cada requisito -instalación para todos los usuarios, service o driver o shell extension o COM denso, necesidad de package identity, distribución escalonada o canales o UX propia, y bastar con copiar archivos- con el método más adecuado, sea MSI, MSIX, un updater propio o xcopy
    A1["Instalación para todos los usuarios"] --> B1["MSI / en parte MSIX"]
    A2["service / driver / shell extension / COM denso"] --> B2["MSI / installer dedicado"]
    A3["Se necesita package identity"] --> B3["MSIX"]
    A4["Distribución escalonada / canales / UX propia"] --> B4["Updater propio"]
    A5["Basta con colocar los archivos"] --> B5["xcopy"]

ClickOnce no es un método universal ni por arriba ni por abajo, pero a cambio es fuerte en proyectos con la complejidad justa.

9. Puntos donde es fácil tropezar en la práctica

ClickOnce es conveniente, pero si se entra en él de forma descuidada, se producen algunos tropiezos. Conviene tener presente de antemano especialmente lo siguiente.

9.1 No lo vea con la misma sensación que “un instalador normal”

ClickOnce no es un modelo que coloque los archivos en un destino de instalación fijo de forma que una persona pueda gestionarlo directamente con facilidad.

Los archivos reales entran en la caché que gestiona ClickOnce y quedan separados por versión. Por eso, no encaja bien con operativas como

• las que presuponen una ruta de EXE fija,
• las que sobrescriben directamente a mano, o
• las que dejan que una persona controle la ubicación de los archivos reales.

ClickOnce es un método en el que el estado de la distribución se gestiona mediante manifiestos, no un método en el que una persona gestiona la colocación de archivos.

9.2 Muchos artículos antiguos sobre ClickOnce presuponen .NET Framework

Este es un punto que requiere atención.

Incluso hoy, en los primeros resultados de búsqueda aparecen muchos artículos sobre ClickOnce de la época de .NET Framework. Pero en el .NET actual la situación es un poco distinta.

• En .NET Core 3.1, .NET 5 y .NET 6, la API ApplicationDeployment ya no se puede usar tal cual
• A partir de .NET 7, algunas propiedades de implementación se pueden leer mediante variables de entorno
• Si se manejan los manifiestos manualmente, se presupone el uso de dotnet-mage.exe
• En Visual Studio, algunas explicaciones que presuponen el antiguo Publish Wizard tampoco aplican tal cual

Aunque se crea «ya conocer ClickOnce», es más seguro no implementar basándose solo en recuerdos antiguos.

9.3 Los requisitos previos se piensan aparte

ClickOnce en sí es un modelo de distribución, pero a veces la aplicación necesita requisitos previos para funcionar.

• El runtime compatible
• Componentes redistribuibles adicionales
• Otras dependencias

En este caso resulta útil una configuración de bootstrapper con setup.exe. Al contrario, si esto se deja ambiguo, ocurre que «se distribuyó con ClickOnce, pero no funciona».

9.4 El traspaso de configuración depende de “qué y cómo se guarda”

Con el proveedor de configuración predeterminado, la migración de la configuración al actualizar es relativamente directa. Sin embargo, si se da alguno de estos casos:

• Un proveedor de configuración propio
• Se presupone roaming
• Se ha cambiado por cuenta propia el destino de guardado de la configuración
• La estructura de la configuración cambia mucho entre versiones

entonces, como es natural, ya no basta con esto tal cual.

9.5 No subestime la firma y la vía de actualización

ClickOnce cuenta con un mecanismo de distribución y actualización, pero eso no significa que desaparezca la responsabilidad sobre la seguridad.

Especialmente en producción, conviene aclarar desde el principio

• cómo gestionar el certificado de firma,
• cómo mostrar el nombre del editor,
• cómo gestionar el origen de la actualización, y
• cómo separar la autofirma de pruebas de la firma de producción.

flowchart TD
    accTitle: Firma y verificación del manifiesto
    accDescr: Diagrama que muestra cómo el certificado de firma de código firma el manifiesto de aplicación y el manifiesto de implementación, el cliente los verifica antes de actualizar o ejecutar, y una manipulación del manifiesto detiene el proceso al fallar la verificación
    Cert["Certificado de firma de código"]
    AppMan["Manifiesto de aplicación"]
    DepMan["Manifiesto de implementación"]
    Verify["Verificación en el cliente"]
    Run["Actualización / ejecución"]
    Tamper["Manipulación del manifiesto"]
    Stop["Se detiene al fallar la verificación"]

    Cert --> AppMan
    Cert --> DepMan
    AppMan --> Verify
    DepMan --> Verify
    Verify --> Run
    Tamper -. falla la verificación .-> Stop

«Tener actualización automática» no equivale a «estar tranquilo»: hay que pensar por separado qué se confía y cómo se mantiene esa confianza.

9.6 Si mueve el destino de implementación, revise deploymentProvider

Esto es poco vistoso, pero en la práctica genera bastantes tropiezos.

Una aplicación ClickOnce ya instalada consulta como origen de actualización la ubicación que señala deploymentProvider dentro del manifiesto de implementación. Es decir, aunque se copie toda la carpeta publicada a otra URL o a otro recurso compartido, si no se actualiza deploymentProvider, puede ocurrir que el cliente siga consultando la ubicación original.

Y si se modifica el manifiesto a mano, hace falta volver a firmarlo.

Flujo operativo desde la publicación hasta que se refleja la actualización

flowchart TD
    accTitle: Flujo operativo desde la publicación hasta que la actualización llega al cliente
    accDescr: Diagrama que muestra el flujo desde la compilación, pasando por generar el nuevo manifiesto de aplicación, firmarlo, actualizar el manifiesto de implementación a la nueva versión, firmarlo también, publicarlo en el destino, hasta que el cliente detecta la actualización
    Build["Compilación"]
    AppManifest["Generar el nuevo manifiesto de aplicación"]
    SignApp["Firmar el manifiesto de aplicación"]
    UpdateDep["Actualizar el manifiesto de implementación a la nueva versión"]
    SignDep["Firmar el manifiesto de implementación"]
    Publish["Publicar en el destino"]
    Client["El cliente detecta la actualización"]

    Build --> AppManifest --> SignApp --> UpdateDep --> SignDep --> Publish --> Client

Al final, lo importante en la operación de ClickOnce no es tanto si se colocaron los archivos, sino si el manifiesto y la firma mantienen su integridad.

10. Resumen

En una frase, ClickOnce es

un mecanismo para distribuir aplicaciones de escritorio Windows en .NET de forma sencilla por usuario, y gestionar hasta la actualización con bajo coste.

Destaca principalmente en estos puntos:

• Es fácil de distribuir a usuarios estándar
• Cuenta con un modelo de actualización built-in
• Facilita actualizar solo lo que cambió
• Facilita separar la aplicación y la versión
• Es fácil de publicar desde Visual Studio
• Encaja bien con aplicaciones de negocio de uso interno

Sin embargo, no es universal. Si existen requisitos como

• instalación machine-wide,
• service / driver / shell extension,
• registro COM denso,
• package identity,
• canales propios o distribución escalonada, o
• elaborar la UX de actualización como valor de producto,

conviene pensar desde MSI, MSIX o un updater propio, en lugar de ClickOnce.

ClickOnce no es un instalador simple donde cabe cualquier cosa, pero en los proyectos donde encaja, sigue siendo bastante fuerte hoy en día.

Si lo que se quiere distribuir es

• una aplicación de negocio Windows en .NET,
• para la que basta con instalación por usuario,
• que se quiere distribuir a usuarios estándar, y
• para la que no se quiere mantener la actualización por cuenta propia,

entonces ClickOnce entra como un candidato bastante sólido.

11. Artículos relacionados

• Cómo elegir el método de distribución de aplicaciones Windows - MSI/MSIX/ClickOnce/xcopy/actualización propia
• Diseño de seguridad para la actualización automática - Por qué no basta solo con HTTPS
• Cuándo se necesitan privilegios de administrador en Windows - UAC, áreas protegidas y cómo distinguirlo en el diseño

Temas relacionados

Esta es una página de temas cercana a este artículo. Desde aquí se puede avanzar hacia servicios relacionados u otros artículos.

Temas técnicos de Windows

Es la puerta de entrada que reúne los temas técnicos de desarrollo en Windows, investigación de fallos y aprovechamiento de activos existentes.

Servicios relacionados con este tema

Este artículo conecta con las siguientes páginas de servicio. Le invitamos a acceder por la entrada que más se ajuste.

Desarrollo de aplicaciones Windows

En aplicaciones de negocio internas, herramientas de configuración de equipos, modificaciones de software existente y similares, cuál de entre ClickOnce, MSI, MSIX o xcopy genera menos fricción cambia bastante según cómo se organice antes de implementar.

Ver el servicio Contacto

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

Distinciones como «¿basta con ClickOnce?», «¿conviene inclinarse hacia MSIX o MSI?» o «¿dejar la actualización automática en manos del modelo built-in o mantenerla por cuenta propia?» resultan más fáciles de decidir si se organizan antes de implementar.

Ver el servicio Contacto

Perfil del autor

Go Komura

Representante de KomuraSoft LLC

Se especializa principalmente en desarrollo de software Windows, consultoría técnica e investigación de fallos, con fortaleza en proyectos con activos existentes y en investigaciones de fallos cuya causa no resulta evidente.

Ver el perfil Contacto

12. Referencias

• Microsoft Learn - Implementación y seguridad de ClickOnce
• Microsoft Learn - ClickOnce para .NET en Windows
• Microsoft Learn - Implementar una aplicación de escritorio Windows en .NET con ClickOnce
• Microsoft Learn - Introducción a Package Identity en aplicaciones de Windows
• Microsoft Learn - Cómo realiza ClickOnce las actualizaciones de la aplicación
• Microsoft Learn - Cómo elegir una estrategia de actualización de ClickOnce
• Microsoft Learn - Manifiesto de implementación de ClickOnce
• Microsoft Learn - Manifiesto de aplicación de ClickOnce
• Microsoft Learn - Introducción a la caché de ClickOnce
• Microsoft Learn - ClickOnce y la configuración de la aplicación
• Microsoft Learn - Instalar requisitos previos con una aplicación ClickOnce
• Microsoft Learn - ClickOnce y Authenticode
• Microsoft Learn - Problemas de seguridad, versionado y manifiestos en implementaciones ClickOnce

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.

Preguntas frecuentes

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

¿Qué es ClickOnce?

Es una tecnología de distribución para repartir aplicaciones de escritorio Windows en .NET por usuario, de forma sencilla, y gestionar todo el ciclo incluyendo la actualización automática. Oficialmente se describe como una tecnología de distribución de aplicaciones basadas en Windows que se pueden instalar y ejecutar con una intervención mínima del usuario, y que pueden actualizarse a sí mismas. En la práctica es un modelo de distribución centrado en manifiestos que gestiona conjuntamente la distribución, la actualización y la caché, y la aplicación se conserva en un área de caché segura por usuario, separada por aplicación, por usuario y por versión.

¿Se puede seguir usando ClickOnce? ¿No es una tecnología antigua?

En el .NET actual, ClickOnce sigue siendo una opción normal a considerar. En Visual Studio se usa la herramienta Publish para .NET Core 3.1 y .NET 5 en adelante, y si se manejan los manifiestos manualmente se recurre a dotnet-mage.exe. Sin embargo, hay que tener presente que la situación es distinta a la de la época de .NET Framework: en .NET Core 3.1, .NET 5 y .NET 6 la API ApplicationDeployment ya no se puede usar tal cual, y a partir de .NET 7 algunas propiedades de implementación se leen mediante variables de entorno. Es más seguro no ponerse a implementar solo con lo que se recuerda de artículos antiguos.

¿Para qué tipo de aplicaciones conviene ClickOnce?

Conviene especialmente para aplicaciones de negocio WinForms / WPF de uso interno, cuando se quiere distribuir a usuarios estándar sin permisos de administrador, la distribución per-user es suficiente y se quiere contar con actualización built-in. También basta con un sitio web o una carpeta compartida como vía de distribución. Por el contrario, no conviene para requisitos de instalación machine-wide para todos los usuarios, para servicios de Windows, drivers, shell extensions o registro COM denso, para requisitos que necesiten package identity, ni para requisitos que exijan controlar canales de actualización o distribución escalonada; en esos casos conviene pensar desde MSI, MSIX o un updater propio.

¿Cómo funciona la actualización automática de ClickOnce?

La comprobación de actualizaciones empieza por el manifiesto de implementación (.application). La aplicación lee ese manifiesto y comprueba si hay una versión nueva, si la actualización es obligatoria y de dónde obtenerla. Al actualizar, mediante file patching se comparan el manifiesto de aplicación de la nueva versión y el de la versión actual, y se obtienen solo los archivos que cambiaron, evitando descargas redundantes. La caché de ClickOnce conserva la versión actual y la anterior por separado, con la idea de establecer correctamente la nueva versión antes de cambiar a ella. Si no hay conexión de red, la aplicación se ejecuta tal cual, sin comprobar actualizaciones.

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.