Quoi de neuf dans le Framework 3.5 : ClickOnce et le déploiement

Par Eric Vernié, Relation technique développeurs

Le déploiement d'application Windows avec le Framework .NET a été introduit, avec Visual Studio 2005 Arrive la version 2008 de Visual Studio et le Framework 3.5, et leurs lots de nouveautés. ClickOnce en fait partie, en voici un rapide aperçu.

Chemin d'installation et deploymentProvider

Dans la précédente version, lorsque vous deviez changer de chemin d'installation, il était alors obligatoire de signer à nouveau le manifeste ou carrément de le changer. Même si-il reste préférable et conseiller de le faire, avec la version 3.5 ce n'est plus nécessaire. Cette nouvelle fonctionnalité permet aux clients des applications installées une plus grande souplesse.

Avec les Framework 2.0 et 3.0, chaque manifeste de déploiement devait spécifier le tag deploymentProvider afin de pouvoir déployer les applications localement pour une utilisation hors ligne (offline). Ce tag faisant référence à l'emplacement de mise à jour.

Exemple :

    <deploymentProvider codebase="http://www.quarante2.fr/WindowsApplication1/WindowsApplication1.application" />

Couplé avec le besoin de signer le manifeste, il était difficile pour une société de modifier l'emplacement de déploiement sans faire appel à l'auteur de l'application. Il était également plus difficile de permettre à une application d'être déployée à partir de multiples emplacements.

Avec la version 3.5 du Framework, ce tag est désormais par défaut, exclu du manifeste permettant à tout un chacun de modifier simplement l'emplacement de déploiement.

Pour prendre en compte cette nouvelle fonctionnalité, les développeurs d'applications doivent exclure le deploymentProvider de leur manifeste, en n'utilisant pas l'option -providerUrl de l'outil mage.exe, ou en laissant le text box "Start location" à blanc avec l'outil mageui.exe lors de la création du manifeste.

Néanmoins, en tant que développeurs d'application, si vous n'utilisez pas le tag deploymentProvider, il vous sera alors impossible de modifier l'emplacement lors de la prochaine mise à jour, jusqu'a ce que vous publiez une mise à jour qui réintroduit ce tag.

Voici deux exemples qui clarifient ce point :

Dans le premier exemple, vous publiez une application avec ClickOnce d'ou vous avez exclu le tag deploymentProvider, et vous demandez à l'utilisateur de l'installer à partir de l'url http://www.adatum.com/MyApplication. Si vous décidez de publier la prochaine mise à jour de l'application à partir de http://subdomain.adatum.com/MyApplication/, il n'y a alors aucun moyen de signifier cette modification dans le fichier manifeste qui pointe sur http://www.adatum.com/MyApplication.

Vous devez alors utiliser une des deux solutions suivantes :

1. Indiquez à vos utilisateurs de de-installer l'ancienne version, et d'installer la nouvelle à partir du nouvel emplacement.
2. Inclure une mise à jour à l'emplacement http://www.adatum.com/MyApplication en ajoutant le tag deployementProvider dans le manifeste. Puis faire une autre mise à jour plus tard toujours avec le tag deploymentProvider, pointant cette fois-ci sur http://subdomain.adatum.com/MyApplication/

Dans ce second exemple, vous décidez de publier une application qui inclue le tag deploymentProvider, puis vous décidez de le retirer. Comme dans le 1er exemple, il ne sera alors plus possible de mettre à jour l'emplacement de publication de l'application. Vous devrez réitérer soit la solution 1, soit la solution 2.

Use Application Manifest for trust information

Tous les développeurs qui utilisent ClickOnce, ne décident pas de déployer leurs applications eux même. Plusieurs d'entre eux, crées tout simplement des packages ClickOnce, et les fournissent à leurs clients surtout des clients qui ont de grosses contraintes de déploiements. Le client devient alors responsable de l'hébergement de l'application sur son propre réseau.

Néanmoins, dans ce scénario, plusieurs contraintes apparaissent.

 Pour déployer au travers d'un réseau, les manifestes de l'application et de déploiement doivent être tous les deux signés avec un certificat digital. Ceci lève la question, quel certificat utiliser ? Celui du développeur, ou celui du client ?

La question est cruciale, car l'identité de l'application ClickOnce est basée sur cette signature digitale. Si le développeur utilise son certificat, cela peut entrainer des conflits, surtout dans une grande entreprise qui décide de déployer des versions personnalisées de l'application dans différentes divisions.

Par exemple, imaginons, que la société Adventure Works, à des départements finance et ressources humaines. Ces deux départements obtiennent des licences d'une application de Microsoft Corporation qui génère des états à partir d'une base de données SQL.

Microsoft fournis aux deux départements une version personnalisée de l'application, mais avec un jeu de données différentes et propre à chaque département. Si les applications sont signées avec le même certificat, un utilisateur qui utilisera les deux applications en même temps risque fort de rencontrer une erreur. En effet ClickOnce ne sera pas faire la différence entre les deux applications. Il est donc possible de saisir alors des données dans une base qui ne soit pas la bonne.

Un autre problème vient de la signature de code avec le tag deploymentProvider qui dit à ClickOnce ou se trouve l'emplacement de mise à jour. Si on le modifie après coup, le manifeste de déploiement devra alors être signé à nouveau (cf plus haut).

Une solution à ce problème consisterait alors, que le développeur signe avec son certificat le manifeste de l'application, et le client signe le manifeste de déploiement avec son certificat. Bien que cette approche fonctionne, elle introduit d'autres contraintes. Le certificat étant privé le client ne peut pas juste le donner au développeur pour signer le manifeste de déploiement.

Il doit alors le signer lui même. Pour ce faire le client, peu utiliser des outils livrés dans le SDK du Framework. Néanmoins, c'est une tâche longue et difficile. Très souvent, le développeur crée une application, un site web ou tout autre mécanisme, permettant aux clients de soumettre leur version d'application pour signature.

ClickOnce a introduit de la flexibilité en terme de déploiement, mais certain scénarios deviennent très vite compliqués à mettre en place.

Pour répondre alors à la question qui doit signer et avec quel certificat ? Le Framework 3.5 et ClickOnce ont introduit une nouvelle fonctionnalité "Using Application Manifest for Trust", qui donne aux développeurs et aux clients une nouvelle solution à la manière dont les manifestes doivent être signés.

Lors de l'utilisation de cette fonctionnalité qui se caractérise par l'ajout d'un tag  <useManifestForTrust> dans le manifeste de déploiement (Les outils mage.exe, mageui.exe et Visual Studio 2008 permettent de l'ajouter automatiquement), évite que le manifeste de déploiement soit signé avec un certificat d'authentification provenant d'une autorité de certification, ce qui simplifie grandement la tâche du client. A la place, il peut être signé par un certificat dit "self-signed" crée par l'outil MakeCert.exe. Ce certificat permet également aux développeurs de garder la main mise sur l'identité de leurs applications.

Pour finir, il est désormais possible avec ClickOnce de déployer des applications dites XBAP (Windows Presentation Foundation tournant dans un explorateur)