Créer des applications ClickOnce destinées à être déployées par des tiers

  • Article

Les développeurs qui créent des déploiements ClickOnce ne prévoient pas tous de déployer les applications eux-mêmes. Beaucoup d’entre eux empaquettent simplement leur application à l’aide de ClickOnce, puis remettent les fichiers à un client, comme une grande entreprise. Le client devient le responsable de l’hébergement de l’application sur son réseau. Cette rubrique décrit certains des problèmes inhérents à de tels déploiements dans les versions du .NET Framework antérieures à la version 3.5. Elle décrit ensuite une nouvelle solution fournie à l’aide de la nouvelle fonctionnalité « use manifest for trust » dans .NET Framework 3.5. Enfin, elle se termine par les stratégies recommandées pour créer des déploiements ClickOnce pour les clients qui utilisent encore des versions antérieures du .NET Framework.

Problèmes inhérents à la création de déploiements pour les clients

Plusieurs problèmes se produisent lorsque vous envisagez de fournir un déploiement à un client. Le premier problème concerne la signature de code. Pour être déployés sur un réseau, le manifeste de déploiement et le manifeste d’application d’un déploiement ClickOnce doivent être signés avec un certificat numérique. Cela pose la question de savoir s’il faut utiliser le certificat du développeur ou le certificat du client lors de la signature des manifestes.

La question du certificat à utiliser est essentielle, car l’identité d’une application ClickOnce est basée sur la signature numérique du manifeste de déploiement. Si le développeur signe le manifeste de déploiement, cela peut entraîner des conflits si le client est une grande entreprise et que plusieurs divisions de l’entreprise déploient une version personnalisée de l’application.

Par exemple, supposons qu’Adventure Works dispose d’un département des finances et d’un département des ressources humaines. Les deux services attribuent une licence à une application ClickOnce de Microsoft Corporation qui génère des rapports à partir de données stockées dans une base de données SQL. Microsoft fournit à chaque service une version de l’application personnalisée pour l’adapter à ses données. Si les applications étaient signées avec le même certificat Authenticode, un utilisateur tentant d’utiliser les deux applications rencontrerait une erreur, car ClickOnce considérerait la seconde application comme identique à la première. Dans ce cas, le client pourrait subir des effets secondaires imprévisibles et indésirables, notamment la perte de toutes les données stockées localement par l’application.

Un autre problème lié à la signature de code est l’élément deploymentProvider dans le manifeste de déploiement, qui indique à ClickOnce où rechercher les mises à jour de l’application. Cet élément doit être ajouté au manifeste de déploiement avant sa signature. Si cet élément est ajouté par la suite, le manifeste de déploiement doit être signé une nouvelle fois.

Signature du manifeste de déploiement par le client

Une solution à ce problème de déploiements non uniques consiste à faire en sorte que le développeur signe le manifeste de l’application et que le client signe le manifeste de déploiement. Bien que cette approche fonctionne, elle présente d’autres problèmes. Étant donné qu’un certificat Authenticode doit rester une ressource protégée, le client ne peut pas simplement donner le certificat au développeur pour signer le déploiement. Bien que le client puisse signer lui-même le manifeste de déploiement à l’aide d’outils disponibles gratuitement avec le SDK .NET Framework, cela peut nécessiter des connaissances techniques supérieures à celles que le client est disposé ou en mesure de fournir. Dans ce cas, le développeur crée généralement une application, un site web ou un autre mécanisme par lequel le client peut envoyer sa version de l’application en vue de sa signature.

Impact de la signature du client sur la sécurité de l’application ClickOnce

Même si le développeur et le client conviennent que le client doit signer le manifeste de l’application, cela soulève d’autres problèmes qui entourent l’identité de l’application, en particulier dans le cas du déploiement d’applications approuvées. (Pour plus d’informations sur cette fonctionnalité, consultez Vue d’ensemble du déploiement d’applications approuvées.) Supposons qu’Adventure Works souhaite configurer ses ordinateurs clients afin que toutes les applications qui lui sont fournies par Microsoft Corporation s’exécutent avec une confiance totale. Si Adventure Works signe le manifeste de déploiement, ClickOnce utilise la signature de sécurité d’Adventure Work pour déterminer le niveau de confiance de l’application.

Créer des déploiements client à l’aide du manifeste d’application pour l’approbation

ClickOnce dans .NET Framework 3.5 contient une nouvelle fonctionnalité qui offre aux développeurs et aux clients une nouvelle solution pour le scénario de signature des manifestes. Le manifeste d’application ClickOnce prend en charge un nouvel élément nommé <useManifestForTrust>, qui permet à un développeur de signifier que c’est la signature numérique du manifeste d’application qui doit être utilisée pour prendre des décisions d’approbation. Le développeur utilise les outils d’empaquetage ClickOnce, tels que Mage.exe, MageUI.exeet Visual Studio, pour inclure cet élément dans le manifeste de l’application, ainsi que pour incorporer à la fois le nom de l’éditeur et le nom de l’application dans le manifeste.

Avec <useManifestForTrust>, le manifeste de déploiement n’a pas besoin d’être signé avec un certificat Authenticode émis par une autorité de certification. À la place, il peut être signé avec ce que l’on appelle un certificat auto-signé. Un certificat auto-signé est généré par le client ou par le développeur à l’aide des outils standard du SDK .NET Framework, puis appliqué au manifeste de déploiement à l’aide des outils de déploiement ClickOnce standard. Pour plus d’informations, voir MakeCert.

L’utilisation d’un certificat auto-signé pour le manifeste de déploiement présente plusieurs avantages. En éliminant la nécessité pour le client d’obtenir ou de créer son propre certificat Authenticode, <useManifestForTrust> simplifie le déploiement pour le client, tout en permettant au développeur de conserver sa propre identité de marque sur l’application. Le résultat est un ensemble de déploiements signés qui sont plus sécurisés et qui possèdent des identités d’application uniques. Cela élimine le conflit potentiel qui peut se produire lors du déploiement d’une même application sur plusieurs clients.

Pour obtenir des informations pas à pas sur la création d’un déploiement ClickOnce avec l’élément <useManifestForTrust> activé, consultez Procédure pas à pas : déploiement manuel d’une application ClickOnce qui ne nécessite pas de nouvelle signature et qui conserve les informations relatives à la personnalisation.

Fonctionnement du manifeste d’application pour l’approbation au moment de l’exécution

Pour mieux comprendre le fonctionnement du manifeste d’application pour l’approbation au moment de l’exécution, examinez l’exemple suivant. Microsoft crée une application ClickOnce qui cible le .NET Framework 3.5. Le manifeste de l’application utilise l’élément <useManifestForTrust> et est signé par Microsoft. Adventure Works signe le manifeste de déploiement à l’aide d’un certificat auto-signé. Les clients Adventure Works sont configurés pour approuver toute application signée par Microsoft.

Lorsqu’un utilisateur clique sur un lien vers le manifeste de déploiement, ClickOnce installe l’application sur l’ordinateur de l’utilisateur. Les informations de certificat et de déploiement identifient l’application de manière unique à ClickOnce sur l’ordinateur client. Si l’utilisateur tente d’installer à nouveau la même application à partir d’un autre emplacement, ClickOnce peut utiliser cette identité pour déterminer que l’application existe déjà sur le client.

Ensuite, ClickOnce examine le certificat Authenticode utilisé pour signer le manifeste de l’application, ce qui détermine le niveau de confiance accordé par ClickOnce. Étant donné qu’Adventure Works a configuré ses clients pour qu’ils approuvent toute application signée par Microsoft, cette application ClickOnce bénéficie d’une confiance totale. Pour plus d’informations, consultez Vue d’ensemble du déploiement d’applications approuvées.

Créer des déploiements client pour les versions antérieures

Que se passe-t-il si un développeur déploie des applications ClickOnce sur des clients qui utilisent des versions antérieures du .NET Framework ? Les sections suivantes récapitulent plusieurs solutions recommandées, ainsi que les avantages et les inconvénients de chacune d’elles.

Signer des déploiements au nom du client

Une stratégie de déploiement possible consiste pour le développeur à créer un mécanisme pour signer les déploiements au nom de ses clients, à l’aide de la clé privée du client. Cela évite au développeur d’avoir à gérer des clés privées ou plusieurs packages de déploiement. Le développeur fournit simplement le même déploiement à chaque client. Il incombe au client de le personnaliser pour son environnement à l’aide du service de signature.

L’un des inconvénients de cette méthode est le temps et les dépenses nécessaires pour l’implémenter. Bien qu’un tel service puisse être créé à l’aide des outils fournis dans le SDK .NET Framework, il ajoute du temps de développement au cycle de vie du produit.

Comme indiqué plus haut dans cette rubrique, un autre inconvénient est que la version de chaque client de l’application aura la même identité d’application, ce qui peut entraîner des conflits. Si cela pose problème, le développeur peut modifier le champ Nom utilisé lors de la génération du manifeste de déploiement pour donner à chaque application un nom unique. Cela crée une identité distincte pour chaque version de l’application et élimine les conflits d’identité potentiels. Ce champ correspond à l’argument -Name de Mage.exe et au champ Nom sous l’onglet Nom dans MageUI.exe.

Par exemple, supposons que le développeur a créé une application nommée Application1. Au lieu de créer un déploiement unique avec le champ Nom défini sur Application1, le développeur peut créer plusieurs déploiements avec une variante spécifique au client sur ce nom, comme Application1-ClientA, Application1-ClientB, etc.

Déployer à l’aide d’un package d’installation

Une deuxième stratégie de déploiement possible consiste à générer un projet d’installation Microsoft pour effectuer le déploiement initial de l’application ClickOnce. Cela peut être fourni dans différents formats : sous forme de déploiement MSI, d’un exécutable d’installation (.EXE) ou d’un fichier cabinet (.cab) avec un script batch.

Avec cette technique, le développeur fournit au client un déploiement qui inclut les fichiers d’application, le manifeste de l’application et un manifeste de déploiement qui sert de modèle. Le client exécute alors le programme d’installation, qui lui demande une URL de déploiement (l’emplacement du serveur ou du partage de fichiers à partir duquel les utilisateurs installeront l’application ClickOnce), ainsi qu’un certificat numérique. L’application d’installation peut également proposer des options de configuration ClickOnce supplémentaires, telles que l’intervalle de vérification des mises à jour. Une fois ces informations collectées, le programme d’installation génère le manifeste de déploiement réel, le signe et publie l’application ClickOnce à l’emplacement du serveur désigné.

Dans ce cas, le client peut signer le manifeste de déploiement de trois façons :

  1. Le client peut utiliser un certificat valide émis par une autorité de certification (CA).

  2. Comme variante de cette approche, le client peut choisir de signer son manifeste de déploiement avec un certificat auto-signé. L’inconvénient est que l’application affiche le message « Éditeur inconnu » lorsque l’utilisateur est invité à indiquer s’il veut l’installer. Toutefois, l’avantage est que cela permet aux petits clients d’éviter d’avoir à consacrer du temps et de l’argent pour faire émettre un certificat par une autorité de certification.

  3. Enfin, le développeur peut inclure son propre certificat auto-signé dans le package d’installation. Dans ce cas, les problèmes potentiels liés à l’identité de l’application abordés plus haut dans cette rubrique peuvent se produire.

    L’inconvénient de la méthode par projet de déploiement d’installation est le temps et les dépenses nécessaires pour créer une application de déploiement personnalisée.

Faire générer le manifeste de déploiement par le client

Une troisième stratégie de déploiement possible consiste à remettre uniquement les fichiers d’application et le manifeste de l’application au client. Dans ce scénario, le client est responsable de l’utilisation du SDK .NET Framework pour générer et signer le manifeste de déploiement.

L’inconvénient de cette méthode est qu’elle nécessite que le client installe les outils du SDK .NET Framework et qu’il dispose d’un développeur ou d’un administrateur système qualifié pour les utiliser. Certains clients peuvent exiger une solution qui ne nécessite que peu ou pas d’efforts techniques de leur part.

Contenu connexe