Problèmes liés à la sécurité, à la gestion de version et aux manifestes dans les déploiements ClickOnce

Plusieurs problèmes liés à la sécurité ClickOnce, au contrôle de version des applications et à la syntaxe et à la sémantique du manifeste peuvent entraîner l’échec d’un déploiement ClickOnce.

Contrôle de compte d'utilisateur ClickOnce et Windows

Dans Windows Vista et les versions ultérieures de Windows, les applications s'exécutent par défaut en tant qu'utilisateur standard, même si l'utilisateur actuel est connecté avec un compte disposant d'autorisations d'administrateur. Si une application doit effectuer une action qui nécessite des autorisations d’administrateur, elle en informe le système d’exploitation, qui invite alors l’utilisateur à saisir ses informations d’identification d’administrateur. Cette fonctionnalité, appelée Contrôle de compte d’utilisateur (UAC), empêche les applications d’apporter des modifications susceptibles d’affecter l’ensemble du système d’exploitation sans l’approbation explicite d’un utilisateur. Les applications Windows déclarent avoir besoin de cette élévation d’autorisation en spécifiant l’attribut requestedExecutionLevel dans la section trustInfo de leur manifeste d’application.

En raison du risque d'exposer les applications à des attaques d'élévation de sécurité, les applications ClickOnce ne peuvent pas demander d'élévation d'autorisation si l'UAC est activée pour le client. Toute application ClickOnce qui tente de définir son attribut requestedExecutionLevel sur requireAdministrator ou highestAvailable ne sera pas installée sur Windows Vista et les versions ultérieures.

Dans certains cas, votre application ClickOnce peut tenter de s’exécuter avec des autorisations d’administrateur en raison de la logique de détection du programme d’installation sur Windows. Dans ce cas, vous pouvez définir l’attribut requestedExecutionLevel dans le manifeste de l’application sur asInvoker. Cela entraînera l’exécution de l’application elle-même sans élévation. Visual Studio ajoute automatiquement cet attribut à tous les manifestes de l’application.

Si vous développez une application qui nécessite des autorisations d'administrateur pour toute la durée de vie de l'application, vous devriez plutôt envisager de déployer l'application à l'aide de la technologie Windows Installer (MSI). Pour plus d’informations, consultez Principes de base de Windows Installer.

Quotas d’applications en ligne et applications de confiance partielle

Si votre application ClickOnce s’exécute en ligne et non par le biais d’une installation, elle doit s’adapter au quota réservé aux applications en ligne. En outre, une application réseau qui s'exécute en confiance partielle, par exemple avec un ensemble restreint d'autorisations de sécurité, ne peut pas dépasser la moitié de la taille du quota.

Pour plus d’informations et pour savoir comment modifier le quota d’application en ligne, consultez Vue d’ensemble du cache ClickOnce.

Problèmes de gestion des versions

Vous pouvez rencontrer des problèmes si vous attribuez des noms forts à votre assembly et incrémentez le numéro de version de l’assembly pour refléter une mise à jour d’application. Tout assembly compilé avec une référence à un assembly à nom fort doit lui-même être recompilé, sinon l’assembly essaie de référencer l’ancienne version. L’assembly essaie de le faire, car il utilise l’ancienne valeur de version dans sa demande de liaison.

Par exemple, supposons que vous disposez d’un assembly à nom fort dans son propre projet avec la version 1.0.0.0. Après avoir compilé l’assembly, vous l’ajoutez en tant que référence au projet qui contient votre application principale. Si vous mettez à jour l'assembly, incrémentez la version vers 1.0.0.1 et essayez de le déployer sans recompiler l'application, l'application ne pourra pas charger l'assembly au moment de l'exécution.

Cette erreur ne peut se produire que si vous modifiez vos manifestes ClickOnce manuellement ; vous ne devriez pas rencontrer cette erreur si vous générez votre déploiement à l'aide de Visual Studio.

Spécifier des assemblys .NET Framework individuels dans le manifeste

Le chargement de votre application échoue si vous avez modifié manuellement un déploiement ClickOnce pour référencer une version antérieure d’un assembly .NET Framework. Par exemple, si vous avez ajouté une référence à l’assembly System.Net pour une version de .NET Framework antérieure à la version spécifiée dans le manifeste, une erreur se produit. En général, vous ne devez pas tenter de spécifier des références à des assemblys .NET Framework individuels, car la version de .NET Framework sur laquelle votre application s'exécute est spécifiée en tant que dépendance dans le manifeste de l'application.

Problèmes d’analyse de manifeste

Les fichiers manifeste utilisés par ClickOnce sont des fichiers XML et doivent être à la fois bien formés et valides : ils doivent respecter les règles de syntaxe XML et utiliser uniquement des éléments et des attributs définis dans le schéma XML approprié.

Sélectionner un nom pour votre application qui contient un caractère spécial, tel qu’un guillemet simple ou double, peut poser des problèmes dans un fichier manifeste. Le nom de l’application fait partie de son identité ClickOnce. Actuellement, ClickOnce n'analyse pas les identités qui contiennent des caractères spéciaux. Si votre application ne s'active pas, vérifiez que vous utilisez uniquement des caractères alphabétiques et numériques pour le nom et tentez de la déployer à nouveau.

Si vous avez modifié manuellement vos manifestes de déploiement ou d’application, vous les avez peut-être endommagés involontairement. Un manifeste endommagé empêche une installation correcte de ClickOnce. Vous pouvez déboguer ces erreurs au moment de l’exécution en cliquant sur Détails dans la boîte de dialogue Erreur ClickOnce et en lisant le message d’erreur dans le journal. Le journal répertorie l’un des messages suivants :

• Une description de l’erreur de syntaxe, ainsi que le numéro de ligne et la position du caractère où l’erreur s’est produite.

• Le nom d’un élément ou d’un attribut utilisé en violation du schéma du manifeste. Si vous avez ajouté du code XML manuellement à vos manifestes, vous devrez comparer vos ajouts aux schémas de manifeste. Pour plus d’informations, consultez Manifeste de déploiement ClickOnce et Manifeste de l’application ClickOnce.

• Un conflit d’ID. Les références de dépendance dans les manifestes de déploiement et d’application doivent être uniques dans leurs attributs name et publicKeyToken. Si les deux attributs correspondent entre deux éléments au sein d'un manifeste, l'analyse de manifeste n'aboutira pas.

Précautions à prendre lors de la modification manuelle de manifestes ou d’applications

Lorsque vous mettez à jour un manifeste d’application, vous devez signer à nouveau le manifeste d’application et le manifeste de déploiement. Le manifeste de déploiement contient une référence au manifeste d’application qui inclut le hachage de ce fichier et sa signature numérique.

Précautions à prendre lors de l’utilisation du fournisseur de déploiement

Le manifeste de déploiement ClickOnce a une propriété deploymentProvider qui pointe vers le chemin d’accès complet de l’emplacement à partir duquel l’application doit être installée et entretenue :

<deploymentProvider codebase="http://myserver/myapp.application" />

Ce chemin d’accès est défini lorsque ClickOnce crée l’application et est obligatoire pour les applications installées. Le chemin pointe vers l’emplacement standard à partir duquel le programme d’installation ClickOnce installe l’application et recherche les mises à jour. Si vous utilisez la commande xcopy pour copier une application ClickOnce vers un autre emplacement, mais que vous ne modifiez pas la propriété deploymentProvider, ClickOnce fait toujours référence à l'emplacement d'origine lorsqu'il tente de télécharger l'application.

Si vous souhaitez déplacer ou copier une application, vous devez également mettre à jour le chemin d’accès deploymentProvider afin que le client s’installe réellement à partir du nouvel emplacement. La mise à jour de ce chemin d’accès concerne surtout les applications installées. Pour les applications en ligne qui sont toujours lancées via l’URL d’origine, la définition de deploymentProvider est facultative. Si deploymentProvider est défini, il sera respecté ; sinon, l’URL utilisée pour démarrer l’application sera utilisée comme URL de base pour télécharger les fichiers de l’application.

Contenu connexe

Résoudre les problèmes de déploiements ClickOnceSécuriser les applications ClickOnceChoisir une stratégie de déploiement ClickOnce