Problèmes de déploiement ClickOnce

Question

Je travaille sur un projet déployé avec ClickOnce et je rencontre plusieurs problèmes.

Ma solution logicielle comporte deux composants: un client de bureau nécessitant un .NET . Framework 3.5 à exécuter et un serveur ( application ASP.NET ) qui répertorie les documents disponibles et fournit un moyen d'installer le client de bureau avec ClickOnce.

Mon premier problème est celui des conditions préalables: j'ai besoin d'un moyen d'installer le framework 3.5 avant l'installation du client. Visual studio crée un setup.exe qui s'en occupe, mais pour le faire fonctionner, il doit être exécuté directement (au lieu de créer un lien vers le fichier .application . ), ainsi que le URL de déploiement doivent être connus lors de la création du manifeste ClickOnce.

J'ai donc deux autres problèmes: il n'y a apparemment aucun moyen d'exécuter l'application cliente avec des arguments de chaîne de requête après l'avoir installée avec setup.exe , donc au lieu d'avoir un serveur affichant la liaison à la liste de documents vers une URL du type "... ... / client.application? document = doc1". Je ne peux avoir qu'un lien vers setup.exe .

L’autre problème est le pire: le serveur est destiné à être utilisé dans des réseaux privés relativement petits, et non sur un seul serveur Web. Le problème est le suivant: je ne connais pas l'URL de déploiement du client ClickOnce au moment de la génération. Par conséquent, setup.exe ne peut pas s'exécuter correctement lorsque l'option "installer à partir d'un site Web" est l'option est cochée. Pour l’instant, la solution consiste à installer un programme d’installation hors ligne contenant les setup.exe , les composants requis et les fichiers de déploiement ClickOnce dans un grand fichier ZIP.

Un utilisateur disposant de la version de structure appropriée peut toujours utiliser le lien .application avec chaîne de requête au document pour installer / mettre à jour le client et ouvrir le document. Un utilisateur sans la structure reçoit un message d'erreur ("Mise à jour système requise blablabla 3.5.0.0 blabla GAC"), il doit télécharger le fichier ZIP, l'extraire sur sa machine locale et exécuter le setup.exe fichier pour installer le framework, puis le client. Et après cela, il doit retourner à la liste des documents et utiliser le lien pour lancer le client avec les arguments appropriés.

Inutile de dire que je ne suis pas très fier de cette stratégie, qui gâche tous les avantages du déploiement de ClickOnce.

Est-il possible de supprimer le problème des conditions préalables de manière plus élégante? Existe-t-il un moyen simple de modifier l’URL d’installation de l’application ClickOnce lors du déploiement du serveur sur un réseau (par exemple, l’écriture de l’URL dans un fichier de configuration ou autre)?

Answer 1

J’ai moi aussi essayé de résoudre le " Je ne connais pas l’URL de déploiement du client clickonce au moment de la compilation " problème.

Le mieux que je puisse faire (je viens de commencer à l'écrire, donc ce n'est encore que de la spéculation) est d'écrire un utilitaire que l'utilisateur final exécutera pour définir le déploiementURL. Cela semble être possible dans .NET, mais vous devez:

• Lisez le manifeste avec ManifestReader.ReadManifest
• définir le DeploymentUrl
• ManifestWriter.WriteManifest

Vous devez ensuite signer à nouveau le manifeste à l'aide de SecurityUtilities.SignFile

Le processus de signature me dérange. Soit je dois utiliser un certificat jetable (ce qui rend la signature insignifiante) ou j'ai besoin d'un certificat provenant d'une autorité de certification, puis je dois distribuer mon mot de passe pour pouvoir démissionner le manifeste (ce qui est stupide, car cela rend mon certificat non sécurisé). . Il semble donc que je reste avec l'utilisateur qui voit "Editeur inconnu". et un point d'exclamation jaune ...

Answer 2

Afin de créer des applications ClickOnce dans notre système de génération continue et de les déployer sur plusieurs serveurs de test, j'ai passé un peu de temps avec Mage et l'article Procédure pas à pas: déploiement manuel d'une application ClickOnce .

Je ne sais pas si cela résoudra votre deuxième problème, mais le processus de construction risque au moins d’être éprouvé si vous effectuez un déploiement sur plusieurs serveurs. Si vous pouvez distribuer mage.exe (sans savoir si Microsoft le permet), vous pourrez modifier vos manifestes sur site lors de l'installation.

Answer 3

Peut-être qu'une solution serait:

Utilisez PublishUrl = http: // cliquez une fois / is / kinda / cool et sur l'ordinateur client, modifiez le fichier d'hôtes Windows situé sur
% windir% \ system32 \ drivers \ etc \ hosts et pointez l'hôte sur la adresse IP fixe du serveur .

Peut-être que ClickOnce devrait avoir une option pour détecter le serveur à partir duquel l’application a été téléchargée; Si quelqu'un sait, merci de poster ici;

Answer 4

Si les utilisateurs se trouvent sur un domaine, le sysadmin push .NET 3.5 aurait alors été utilisé avec Règles de groupe / Windows Update ou toute autre stratégie utilisée pour gérer les ordinateurs de bureau.

Cela ressemble à un problème d’environnement. Si l'organisation est suffisamment grande pour avoir un administrateur système, il devrait incomber à cette personne de fournir un environnement permettant à l'application de s'exécuter.

Si l'organisation ne compte aucune personne dans ce rôle, je pense que vous êtes revenu à votre solution manuelle. De plus, le faire manuellement ne supprime pas nécessairement tous les avantages de ClickOnce ...

Je suppose que l’autre option est d’écrire un script qui récupère et installe .NET 3.5, puis installe l’application. Je ne l’ai jamais fait auparavant ... Je suis pratiquement sûr que cela fonctionnerait ... En fait, vous déployer un script de démarrage via les stratégies de groupe qui obtient également .NET 3.5, ce serait très simple.

Answer 5

Peut-être NAnt pourrait-il être exploité pour automatiser la modification de l'URL de déploiement. Je l'utilise pour automatiser mes générations ClickOnce et modifier la version du manifeste. ClickOnce with NAnt explique comment Je l'ai fait.

Answer 6

Deuxième question:

Vous pouvez utiliser la cible de publication MSBuild sur un projet, une solution ou un fichier MSBuild comme suit:

C:\WINDOWS\Microsoft.NET\Framework\v3.5\msbuild.exe "C:\path\foo.vbproj" /target:Publish /property:"PublishUrl=http://clickonce/is/kinda/cool/" /property:"PublishUrl=http://clickonce/is/kinda/cool/" 

PublishUrl correspond à l'emplacement de publication de l'application dans l'EDI. Il est inséré dans le manifeste de l'application ClickOnce si ni la propriété InstallUrl ni UpdateUrl n'est spécifiée.

InstallUrl (non affiché) est l'emplacement à partir duquel les utilisateurs installeront l'application. Si elle est spécifiée, cette valeur est gravée dans l’amorçage setup.exe si la propriété IsWebBootstrapper est activée. Il est également inséré dans le manifeste de l'application si le UpdateUrl n'est pas spécifié.

Première question:

Si la réponse ci-dessus ne répond pas à vos besoins, il me semble que vous faites face à un problème typique. comment obtenir un exécutable Windows (dans votre cas, le .NET Framework 3.5) installé sur plusieurs bureaux. Il existe plusieurs solutions telles que les scripts Stratégie de groupe (stratégie de groupe) ou WMI .