Créer des applications ClickOnce pour que d’autres utilisateurs puissent déployer

Tous les développeurs qui créent des déploiements ClickOnce ne prévoient pas de déployer les applications elles-mêmes. Beaucoup d'entre eux empaquetent leur application en utilisant ClickOnce, puis remettent les fichiers à un client, comme une grande entreprise. Le client devient responsable de l’hébergement de l’application sur son réseau. Cette rubrique décrit certains des problèmes inhérents à ces déploiements dans les versions du .NET Framework antérieures à la version 3.5. Il décrit ensuite une nouvelle solution fournie à l’aide de la nouvelle fonctionnalité « utiliser le manifeste pour approbation » dans .NET Framework 3.5. Enfin, elle se termine par des stratégies recommandées pour la création de déploiements ClickOnce pour les clients qui utilisent toujours des versions antérieures du .NET Framework.

Problèmes liés à 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é sur un réseau, le manifeste de déploiement et le manifeste d’application d’un déploiement ClickOnce doivent tous deux être signés avec un certificat numérique. Cela soulève 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 de savoir quel certificat utiliser est critique, 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, il peut entraîner des conflits si le client est une grande entreprise, et plusieurs divisions de l’entreprise déploient une version personnalisée de l’application.

Par exemple, supposons que Adventure Works dispose d’un service financier et d’un service de ressources humaines. Les deux services licencent 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 ses données. Si les applications sont signées avec le même certificat Authenticode, un utilisateur qui tente d’utiliser les deux applications rencontre une erreur, car ClickOnce considère la deuxième application comme identique à la première. Dans ce cas, le client peut rencontrer des effets secondaires imprévisibles et indésirables qui incluent la perte de données stockées localement par l’application.

Un problème supplémentaire lié à la signature de code est l’élément deploymentProvider du manifeste de déploiement, qui indique à ClickOnce où rechercher les mises à jour d’application. Cet élément doit être ajouté au manifeste de déploiement avant de le signer. Si cet élément est ajouté par la suite, le manifeste de déploiement doit être ré-signé.

Exiger que le client signe le manifeste de déploiement

Une solution à ce problème de déploiements non uniques consiste à faire signer le manifeste de l’application par le développeur et au client à signer 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 le manifeste de déploiement lui-même à l’aide d’outils disponibles librement avec le Kit de développement logiciel (SDK) .NET Framework, cela peut nécessiter plus de connaissances techniques que le client est prêt ou capable 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 soumettre sa version de l’application pour signature.

Impact de la signature du client sur la sécurité des applications 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 lorsqu’il s’applique au déploiement d’applications approuvées. (Pour plus d’informations sur cette fonctionnalité, consultez la vue d’ensemble du déploiement d’applications approuvées.) Supposons que Adventure Works souhaite configurer ses ordinateurs clients afin que toute application fournie par Microsoft Corporation s’exécute 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 d’approbation de l’application.

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

ClickOnce dans .NET Framework 3.5 contient une nouvelle fonctionnalité qui donne aux développeurs et aux clients une nouvelle solution au 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 la signature numérique du manifeste d'application doit être utilisée pour prendre des décisions d’approbation. Le développeur utilise des 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 son nom de serveur de publication et le nom de l’application dans le manifeste.

Lors de l’utilisation <useManifestForTrust>, le manifeste de déploiement n’a pas besoin d’être signé avec un certificat Authenticode émis par une autorité de certification. Au lieu de cela, il peut être signé avec ce qu’on appelle un certificat auto-signé. Un certificat auto-signé est généré par le client ou le développeur à l’aide d’outils du Kit de développement logiciel (SDK) .NET Framework standard, puis appliqué au manifeste de déploiement à l’aide des outils de déploiement ClickOnce standard. Pour plus d’informations, consultez 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 personnalisation sur l’application. Le résultat est un ensemble de déploiements signés qui sont plus sécurisés et qui ont des identités d’application uniques. Cela élimine le conflit potentiel qui peut se produire lors du déploiement de la même application sur plusieurs clients.

Pour plus d’informations détaillées sur la création d’un déploiement ClickOnce avec <useManifestForTrust> activé, consultez Procédure pas à pas : déployer manuellement une application ClickOnce qui ne nécessite pas de re-signature et qui conserve les informations de personnalisation.

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

Pour mieux comprendre comment l’utilisation du manifeste d’application pour l’approbation fonctionne au moment de l’exécution, tenez compte de l’exemple suivant. Une application ClickOnce qui cible .NET Framework 3.5 est créée par Microsoft. 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 pour ClickOnce sur l’ordinateur client. Si l’utilisateur tente à nouveau d’installer 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, qui détermine le niveau de confiance accordé par ClickOnce. Étant donné que Adventure Works a configuré ses clients pour approuver n’importe quelle application signée par Microsoft, cette application ClickOnce bénéficie d’une confiance totale. Pour plus d’informations, consultez la vue d’ensemble du déploiement d’applications approuvées.

Créer des déploiements de clients 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ésument plusieurs solutions recommandées, ainsi que les avantages et inconvénients de chacun d’eux.

Signer des déploiements au nom du client

Une stratégie de déploiement possible est que le développeur crée un mécanisme pour signer des déploiements pour le compte de ses clients, à l’aide de la clé privée du client. Cela empêche le 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 Kit de développement logiciel (SDK) .NET Framework, il ajoutera davantage de temps de développement au cycle de vie du produit.

Comme indiqué précédemment 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. S’il s’agit d’un 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.exeet 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-CustomerA, Application1-CustomerB, 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 l’un des différents formats : en tant que déploiement MSI, en tant qu’exécutable d’installation (.EXE) ou en tant que fichier cabinet (.cab) avec un script batch.

À l’aide de 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écuterait le programme d’installation, qui lui demanderait une URL de déploiement (le serveur ou l’emplacement de partage de fichiers à partir duquel les utilisateurs installeront l’application ClickOnce), ainsi qu’un certificat numérique. L’application d’installation peut également choisir d’inviter 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é.

Il existe trois façons pour le client de signer le manifeste de déploiement dans cette situation :

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

  2. En guise de 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 les mots « Serveur de publication inconnu » lorsque l’utilisateur est invité à l’installer. Toutefois, l’avantage est qu’il empêche les clients plus petits d’avoir à passer le temps et l’argent requis pour un certificat émis par une autorité de certification.

  3. Enfin, le développeur peut inclure son propre certificat auto-signé dans le package d’installation. Cela présente les problèmes potentiels liés à l’identité d’application abordés précédemment dans cette rubrique.

    L’inconvénient de la méthode de 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.

Avoir un manifeste de déploiement généré par le client

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

L’inconvénient de cette méthode est qu’il exige que le client installe les outils du Kit de développement logiciel (SDK) .NET Framework et qu’il dispose d’un développeur ou d’un administrateur système qualifié pour les utiliser. Certains clients peuvent demander une solution qui nécessite peu ou pas d’effort technique de leur part.

Contenu connexe

  • Last updated on