Compartir a través de

Creación de aplicaciones ClickOnce para que las implementen terceros

  • Artículo

No todos los desarrolladores que crean planes de implementación de ClickOnce implementan las aplicaciones por sí mismos. Muchos de ellos simplemente empaquetan la aplicación mediante ClickOnce y luego entregan los archivos a un cliente como, por ejemplo, una gran corporación. 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, se describe una nueva solución proporcionada mediante la característica "Usar manifiesto para obtener confianza" de .NET Framework 3.5. Como conclusión, se incluyen 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 clientes

Se pueden producir varios problemas cuando planea una implementación para un cliente. El primer problema se refiere a la firma de código. Para implementarse en una red, el manifiesto de implementación y el manifiesto de aplicación de una implementación de ClickOnce deben estar firmados con un certificado digital. Esto plantea la cuestión de si se debe usar el certificado del desarrollador o el 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 otro de recursos humanos. Ambos departamentos crean una licencia para 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 intente usar ambas aplicaciones se encontrará con un error, ya que ClickOnce considerará la segunda aplicación como idéntica a la primera. En este caso, el cliente podría experimentar efectos secundarios impredecibles y no deseados que incluyen la pérdida de todos los datos almacenados localmente por la aplicación.

Un problema adicional relacionado con la firma de código es el elemento deploymentProvider 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 deberá volver a firmarse.

Solicitar 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. Como un certificado Authenticode debe permanecer como un recurso protegido, el cliente no puede simplemente dar el certificado al desarrollador para que firme la implementación. Aunque el cliente puede firmar el manifiesto de implementación por sí mismo mediante las herramientas disponibles de forma gratuita con el SDK de .NET Framework, esto puede requerir más conocimientos técnicos de los que el cliente puede proporcionar. En estos 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 firmar.

Impacto de la firma del cliente en la seguridad de la aplicación ClickOnce

Aunque el desarrollador y el cliente acepten que el cliente debe firmar el manifiesto de aplicación, esto genera otros problemas relacionados con la identidad de la aplicación, especialmente en lo que respecta a la implementación de aplicaciones de confianza. (Para 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 que proporcione 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.

Creación de implementaciones de cliente mediante el manifiesto de aplicación para obtener confianza

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

Si 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 aplica al manifiesto de implementación mediante las herramientas de implementación estándar de ClickOnce. Para 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 para el 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 una nueva firma y que conserva la información de personalización de marca.

Funcionamiento del manifiesto de aplicación para obtener confianza en tiempo de ejecución

Para comprender mejor cómo funciona el manifiesto de aplicación para obtener confianza en tiempo de ejecución, tenga en cuenta el ejemplo siguiente. Microsoft crea una aplicación ClickOnce destinada a .NET Framework 3.5. El manifiesto de aplicación usa el elemento <useManifestForTrust> 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 en ClickOnce en el equipo cliente. Si el usuario intenta instalar de nuevo la misma aplicación 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, el cual determina el nivel de confianza que ClickOnce concederá. Dado que Adventure Works ha configurado sus clientes para que confíen en cualquier aplicación firmada por Microsoft, a esta aplicación ClickOnce se le concede plena confianza. Para más información, vea Introducción a la implementación de aplicaciones de confianza.

Creación de implementaciones de cliente 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 las implementaciones en nombre de sus clientes, mediante el uso de la propia clave privada del cliente. Esto impide que el desarrollador tenga que administrar claves privadas o varios paquetes de implementación. El desarrollador simplemente proporciona la misma implementación a cada cliente. El cliente puede personalizarlo para su entorno mediante el servicio de firma.

Una desventaja de este método es el tiempo y los gastos necesarios para implementarlo. Aunque este tipo de 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, otra desventaja es que la versión de la aplicación de cada cliente tendrá la misma identidad de aplicación, lo que podría provocar conflictos. Si esto supone un problema, el desarrollador puede cambiar el campo Nombre que se usa al generar el manifiesto de implementación para asignar un nombre único a cada aplicación. Esto permite crear una identidad independiente para cada versión de la aplicación y elimina los posibles conflictos de identidad. Este campo corresponde al argumento -Name de Mage.exe y 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 que realice la implementación inicial de la aplicación ClickOnce. Esto se puede proporcionar en uno de estos formatos diferentes: una implementación MSI, un archivo ejecutable de instalación (.EXE) o un archivo contenedor (.cab) junto con un script por lotes.

Con esta técnica, el desarrollador podría proporcionar 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, el cual le 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 variante 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 "Editor desconocido" 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 han descrito anteriormente en este tema.

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

Hacer que el cliente genere el manifiesto de implementación

Una tercera estrategia de implementación posible es entregar solo los archivos de aplicación y el manifiesto de aplicación al cliente. En este escenario, el cliente es responsable de usar el 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 disponga de un desarrollador o administrador del sistema con conocimientos sobre su uso. Algunos clientes pueden solicitar una solución que requiera poco o ningún esfuerzo técnico por su parte.

Contenido relacionado