Compartir a través de

Creación de aplicaciones ClickOnce para que otros usuarios implementen

No todos los desarrolladores que crean implementaciones de ClickOnce planean implementar las propias aplicaciones. Muchos de ellos solo empaquetan su aplicación mediante ClickOnce y luego entregan los archivos a un cliente, como una gran empresa. El cliente se convierte en el responsable de hospedar la aplicación en su red. En este tema se describen algunos de los problemas inherentes a estas implementaciones en versiones de .NET Framework anteriores a la versión 3.5. A continuación, describe una nueva solución proporcionada mediante la nueva característica "usar manifiesto para confianza" en .NET Framework 3.5. Por último, concluye con las estrategias recomendadas para crear implementaciones de ClickOnce para los clientes que todavía usan versiones anteriores de .NET Framework.

Problemas relacionados con la creación de implementaciones para los clientes

Se producen varios problemas cuando planea proporcionar una implementación a un cliente. El primer problema se refiere a la firma de código. Para poder implementarse en una red, el manifiesto de implementación y el manifiesto de aplicación de una implementación ClickOnce deben estar firmados con un certificado digital. Esto plantea la pregunta de si se debe usar el certificado del desarrollador o el certificado del cliente al firmar los manifiestos.

La pregunta de qué certificado usar es fundamental, ya que la identidad de una aplicación ClickOnce se basa en la firma digital del manifiesto de implementación. Si el desarrollador firma el manifiesto de implementación, podría provocar conflictos si el cliente es una empresa grande y más de una división de la empresa implementa una versión personalizada de la aplicación.

Por ejemplo, supongamos que Adventure Works tiene un departamento financiero y un departamento de recursos humanos. Ambos departamentos licencian una aplicación ClickOnce de Microsoft Corporation que genera informes a partir de datos almacenados en una base de datos SQL. Microsoft proporciona a cada departamento una versión de la aplicación personalizada para sus datos. Si las aplicaciones están firmadas con el mismo certificado Authenticode, un usuario que intenta usar ambas aplicaciones encontraría un error, ya que ClickOnce consideraría la segunda aplicación como idéntica a la primera. En este caso, el cliente podría experimentar efectos secundarios imprevisibles y no deseados que incluyen la pérdida de cualquier dato almacenado localmente por la aplicación.

Un problema adicional relacionado con la firma de código es el deploymentProvider elemento del manifiesto de implementación, que indica a ClickOnce dónde buscar actualizaciones de aplicaciones. Este elemento se debe agregar al manifiesto de implementación antes de firmarlo. Si este elemento se agrega después, el manifiesto de implementación debe volver a firmarse.

Requerir al cliente que firme el manifiesto de implementación

Una solución a este problema de implementaciones no únicas es que el desarrollador firme el manifiesto de aplicación y el cliente firme el manifiesto de implementación. Aunque este enfoque funciona, presenta otros problemas. Dado que un certificado Authenticode debe permanecer protegido, el cliente no puede simplemente dar el certificado al desarrollador para firmar la implementación. Aunque el cliente puede firmar el manifiesto de implementación mediante herramientas disponibles libremente con el SDK de .NET Framework, esto puede requerir más conocimientos técnicos que el cliente dispuesto o capaz de proporcionar. En tales casos, el desarrollador normalmente crea una aplicación, un sitio web u otro mecanismo a través del cual el cliente puede enviar su versión de la aplicación para la firma.

El impacto de la firma de clientes en la seguridad de la aplicación ClickOnce

Incluso si el desarrollador y el cliente están de acuerdo en que el cliente debe firmar el manifiesto de aplicación, esto genera otros problemas que rodean la identidad de la aplicación, especialmente cuando se aplica a la implementación de aplicaciones de confianza. (Para obtener más información sobre esta característica, consulte Introducción a la implementación de aplicaciones de confianza). Supongamos que Adventure Works quiere configurar sus equipos cliente para que cualquier aplicación proporcionada por Microsoft Corporation se ejecute con plena confianza. Si Adventure Works firma el manifiesto de implementación, ClickOnce usará la firma de seguridad de Adventure Work para determinar el nivel de confianza de la aplicación.

Crear implementaciones de clientes usando el manifiesto de la aplicación para garantizar confianza

ClickOnce en .NET Framework 3.5 contiene una nueva característica que proporciona a los desarrolladores y clientes una nueva solución al escenario de cómo se deben firmar los manifiestos. El manifiesto de aplicación ClickOnce admite un nuevo elemento denominado <useManifestForTrust> que permite al desarrollador indicar que la firma digital del manifiesto de aplicación es lo que se debe usar para tomar decisiones de confianza. El desarrollador usa herramientas de empaquetado ClickOnce (como Mage.exe, MageUI.exey Visual Studio) para incluir este elemento en el manifiesto de aplicación, así como para insertar su nombre de publicador y el nombre de la aplicación en el manifiesto.

Cuando se usa <useManifestForTrust>, el manifiesto de implementación no tiene que firmarse con un certificado Authenticode emitido por una entidad de certificación. En su lugar, se puede firmar con lo que se conoce como certificado autofirmado. El cliente o el desarrollador generan un certificado autofirmado mediante las herramientas estándar del SDK de .NET Framework y, a continuación, se aplican al manifiesto de implementación mediante las herramientas de implementación de ClickOnce estándar. Para obtener más información, consulte MakeCert.

El uso de un certificado autofirmado para el manifiesto de implementación presenta varias ventajas. Al eliminar la necesidad de que el cliente obtenga o cree su propio certificado Authenticode, <useManifestForTrust> simplifica la implementación del cliente, al tiempo que permite al desarrollador mantener su propia identidad de personalización de marca en la aplicación. El resultado es un conjunto de implementaciones firmadas que son más seguras y tienen identidades de aplicación únicas. Esto elimina el posible conflicto que puede producirse al implementar la misma aplicación en varios clientes.

Para obtener información paso a paso sobre cómo crear una implementación de ClickOnce con <useManifestForTrust> habilitado, consulte Tutorial: Implementación manual de una aplicación ClickOnce que no requiere volver a firmar y que conserva la información de personalización de marca.

Cómo funciona el manifiesto de aplicaciones para la confianza durante la ejecución

Para comprender mejor cómo funciona el manifiesto de aplicación con respecto a la confianza en tiempo de ejecución, considere el ejemplo siguiente. Microsoft crea una aplicación ClickOnce que tiene como destino .NET Framework 3.5. El manifiesto de aplicación usa el <useManifestForTrust> elemento y está firmado por Microsoft. Adventure Works firma el manifiesto de implementación mediante un certificado autofirmado. Los clientes de Adventure Works están configurados para confiar en cualquier aplicación firmada por Microsoft.

Cuando un usuario hace clic en un vínculo al manifiesto de implementación, ClickOnce instala la aplicación en el equipo del usuario. La información de certificado e implementación identifica la aplicación de forma exclusiva a ClickOnce en el equipo cliente. Si el usuario intenta instalar la misma aplicación de nuevo desde otra ubicación, ClickOnce puede usar esta identidad para determinar que la aplicación ya existe en el cliente.

A continuación, ClickOnce examina el certificado Authenticode que se usa para firmar el manifiesto de aplicación, que determina el nivel de confianza que ClickOnce concederá. Puesto que Adventure Works ha configurado a sus clientes para que confíen en cualquier aplicación firmada por Microsoft, esta aplicación ClickOnce tiene plena confianza. Para más información, consulte Introducción a la implementación de aplicaciones de confianza.

Creación de implementaciones de clientes para versiones anteriores

¿Qué ocurre si un desarrollador implementa aplicaciones ClickOnce en clientes que usan versiones anteriores de .NET Framework? En las secciones siguientes se resumen varias soluciones recomendadas, junto con las ventajas y desventajas de cada una.

Firma de implementaciones en nombre del cliente

Una posible estrategia de implementación es que el desarrollador cree un mecanismo para firmar implementaciones en nombre de sus clientes mediante la propia clave privada del cliente. Esto impide que el desarrollador tenga que administrar claves privadas o varios paquetes de implementación. El desarrollador solo proporciona la misma implementación a cada cliente. Es responsabilidad del cliente personalizarlo para su entorno mediante el servicio de firma.

Un inconveniente de este método es el tiempo y los gastos necesarios para implementarlo. Aunque este servicio se puede crear mediante las herramientas proporcionadas en el SDK de .NET Framework, agregará más tiempo de desarrollo al ciclo de vida del producto.

Como se indicó anteriormente en este tema, otro inconveniente es que la versión de cada cliente de la aplicación tendrá la misma identidad de aplicación, lo que podría provocar conflictos. Si se trata de un problema, el desarrollador puede cambiar el campo Nombre que se usa al generar el manifiesto de implementación para asignar a cada aplicación un nombre único. Esto creará una identidad independiente para cada versión de la aplicación y eliminará los posibles conflictos de identidad. Este campo corresponde al -Name argumento de Mage.exey al campo Nombre de la pestaña Nombre de MageUI.exe.

Por ejemplo, supongamos que el desarrollador ha creado una aplicación denominada Application1. En lugar de crear una sola implementación con el campo Nombre establecido en Application1, el desarrollador puede crear varias implementaciones con una variación específica del cliente en este nombre, como Application1-CustomerA, Application1-CustomerB, etc.

Implementación mediante un paquete de instalación

Una segunda estrategia de implementación posible es generar un proyecto de instalación de Microsoft para realizar la implementación inicial de la aplicación ClickOnce. Esto se puede proporcionar en uno de varios formatos diferentes: como implementación msi, como un archivo ejecutable de instalación (.EXE) o como un archivo de gabinete (.cab) junto con un script por lotes.

Con esta técnica, el desarrollador proporcionaría al cliente una implementación que incluye los archivos de aplicación, el manifiesto de aplicación y un manifiesto de implementación que actúa como plantilla. El cliente ejecutaría el programa de instalación, que les solicitaría una dirección URL de implementación (la ubicación del servidor o del recurso compartido de archivos desde la que los usuarios instalarán la aplicación ClickOnce), así como un certificado digital. La aplicación de instalación también puede optar por solicitar opciones de configuración de ClickOnce adicionales, como el intervalo de comprobación de actualizaciones. Una vez recopilada esta información, el programa de instalación generaría el manifiesto de implementación real, lo firmaría y publicaría la aplicación ClickOnce en la ubicación del servidor designada.

Hay tres maneras de que el cliente pueda firmar el manifiesto de implementación en esta situación:

  1. El cliente puede usar un certificado válido emitido por una entidad de certificación (CA).

  2. Como variación de este enfoque, el cliente puede elegir firmar su manifiesto de implementación con un certificado autofirmado. El inconveniente de esto es que hará que la aplicación muestre las palabras "Unknown Publisher" cuando se le pregunte al usuario si desea instalarla. Sin embargo, la ventaja es que impide que los clientes más pequeños tengan que dedicar el tiempo y el dinero necesarios para un certificado emitido por una entidad de certificación.

  3. Por último, el desarrollador puede incluir su propio certificado autofirmado en el paquete de instalación. Esto presenta los posibles problemas con la identidad de la aplicación que se describen anteriormente en este tema.

    El inconveniente del método de proyecto de implementación de instalación es el tiempo y los gastos necesarios para construir una aplicación de implementación personalizada.

Hacer que el cliente genere el manifiesto de implementación

Una tercera estrategia de implementación posible consiste en entregar solo los archivos de aplicación y el manifiesto de aplicación al cliente. En este escenario, el cliente es responsable del uso del SDK de .NET Framework para generar y firmar el manifiesto de implementación.

El inconveniente de este método es que requiere que el cliente instale las herramientas del SDK de .NET Framework y que tenga un desarrollador o administrador del sistema que esté capacitado para usarlos. Algunos clientes pueden exigir una solución que requiera poco o ningún esfuerzo técnico por su parte.

Contenido relacionado

  • Last updated on