Comment faire de la setup.exe à partir d'un VS2010 Projet d'Installation de demander des Privilèges d'Administrateur?
J'ai un problème que j'ai deviné serait vraiment simple à résoudre... mais duh.
Je suis le déploiement d'un .NET application avec VS2010. J'ai un Windows en C# Formulaires de projet et un Projet de Déploiement. J'ai besoin de l'installer pour exécuter avec des privilèges d'administrateur, car l'application est installé pour tous les utilisateurs et l'inscription sur le registre est fait.
Lors du démarrage de l'setup.exe je ne suis pas invité pour l'élévation de privilèges. Le programme d'installation va démarrer et suggèrent d'installer dans Program Files (x86) ce qui est bon. Après avoir cliqué sur suivant, le programme d'installation s'exécute et fini avec un message de succès. Qui est en fait un mensonge, car il n'a pas réussi à l'installer. Au lieu de cela il met les applications exe directement sur C:\.
Comment puis-je faire le programme d'installation de demander des privilèges d'administrateur. Ou dois-je me fier à mon client de faire un clic droit le programme d'installation et sélectionnez "Exécuter en tant qu'Administrateur" qui est très enclins à faire des erreurs?
Précisions sur ma configuration:
- Dans le Système de Fichiers affichage de la configuration du projet, j'ai ajouté (entre autres choses) "Sortie Principale de project01 (Actif)" et "Construire des Sorties de project01 (Actif) à l'Application "Dossier". J'ai également ajouté un raccourci de "production Primaire" en "User Menu Programmes\CompanyName\Programme".
- Dans le Registre de la Vue, j'ai ajouté une entrée dans HKEY_CLASSES_ROOT parce que j'ai besoin d'enregistrer un gestionnaire d'url.
J'ai aussi modifié la configuration des paramètres d': j'ai mis InstallAllUsers à Vrai parce qu'il est censé faire.
Quand je créer et démarrer le setup.exe en double-cliquant (ou en sélectionnant l'Installer à partir du menu contextuel du projet), je reçois toujours le même résultat: Le programme d'installation s'exécute sans demander des privilèges d'administrateur, demandez à un emplacement de l'installation (que je laisse à la valeur par défaut C:\Program Files(x86)\Company\ProgramName) et puis procedes après avoir cliqué sur Suivant. En conséquence, l'exe est placé directement dans C:\ et le raccourci créé des points de parcours dans le Nirvana.
Si je lance le setup.exe manuellement en tant qu'Administrateur choses fonctionnent bien. Mais cela ne peut pas sérieusement être le chemin à parcourir.
Alors, comment puis-je déterminer la configuration de toujours exécuter en tant qu'Admin?
- Tout d'abord, vous devez corriger votre installateur d'écrire des fichiers dans les Fichiers de Programme plutôt que sur C:. Est UAC activé? Est la racine de C: en écriture pour les utilisateurs limités?
- Comme je l'ai dit, le programme d'installation fonctionne très bien (et s'installe dans Program Files) quand manuellement lancé en tant qu'administrateur. L'UAC est activé, bien sûr. Et non, C:\ n'est pas accessible en écriture qui est la norme autant que je sache, mais encore le MSI met les fichiers si on commence avec des droits limités.
- C'est impossible. Un processus d'installation ne peut pas écrire dans le répertoire C:\ sans élévation ou autorisations appropriées sur C:\. Donc, soit le colis est élevée, d'une certaine façon, ou C:\ dispose des autorisations qui donne à tous un accès complet.
- Le pouvoir normatif de faits battements de votre déclaration. Il se passe. Sur ma machine. Plus d'une fois. J'ai renoncé.
- Les autorisations par défaut ne permettent pas la création de fichiers dans la racine, mais permettent de créer des dossiers. Ce genre d', explique pourquoi le programme d'installation peut écrire des fichiers-t-il sans élever. Je suppose que dans votre cas, une action personnalisée ou quelque chose échoue et INSTALLLOCATION est réglé sur C:\. Je vous suggère de l'exécution de l'installer avec la journalisation détaillée: les deux non élevés et élevés, et de comparer les journaux. La magie qui se passe, mais il y a toujours une explication logique à la magie (*presque toujours).
Vous devez vous connecter pour publier un commentaire.
Je pense que c'est une question tout à fait pertinente, est un réel problème, et a une véritable explication.
Récemment, j'ai couru à travers ce problème. Dans mon cas, la cause est que la
AlwaysInstallElevated
la politique sur l'ordinateur par le biais d'objet de stratégie de groupe. La politique a été mis à 1 dans la machine politique et 0 dans la stratégie de l'utilisateur. Ces politiques peut être réglé manuellement pour reproduire l'effet qu'elle a sur MSI installateursÀ l'aide de
msexec /log install.log /i Deploy.msi
, j'avais un journal d'installation et il y avait des chaînes dans comme ceci:Il semble que Visual Studio ne permet pas de définir la
SecureCustomProperties
dans la MSI correctement et de post-traitement de certains tri est nécessaire. Je pense que le passage à la WiX peut-être une meilleure solution à long terme au lieu.Un blog sur MSDN est ce que j'ai trouvé qui m'a aidé à trouver la cause de ce problème.
J'ai rencontré le même problème que vous, et nous avons trouvé une très bonne solution pour elle. Donc, il pourrait fonctionner pour vous aussi. La solution est documenté ici:
VS2010 Projet d'Installation - Exécuter en tant Qu'Administrateur
Je vais ré-itérer la solution brièvement ici. Fondamentalement, vous avez besoin de modifier manuellement la configuration du fichier de projet (.vdproj) et la propriété suivante VRAI:
C'est le comportement normal. Le boostrapper n'a pas besoin d'élévation.
Ainsi, il a fait installer votre application, mais dans le mauvais emplacement. Ce n'est pas lié à l'altitude. Dans l'éditeur de Système de Fichiers dans votre projet d'installation où avez-vous d'ajouter les fichiers de votre application? Avez-vous les ajouter dans l'Application "Dossier"?
Un package MSI installé pour tous les utilisateurs automatiquement les invites d'élévation lorsque vous cliquez sur le bouton Installer. Si ce n'est pas élever automatiquement et installe dans un emplacement de la machine (comme C:), l'installation échoue et rien n'est copié sur la machine cible.