Как установить с повышенными разрешениями с помощью установщика WiX? - PullRequest
12 голосов
/ 04 января 2012

В настоящее время у нас есть MSI, созданный с WiX 3.5. Приложение находится в .NET 3.5. Мы генерируем загрузчик с помощью задачи boostrapper в файле MSBuild . Он указывает на файлы 6.0a SDK .

Когда пользователи имеют UAC и они устанавливают, они должны щелкнуть правой кнопкой мыши на setup.exe и выбрать администратор запуска.

Что мне действительно нужно, так это чтобы setup.exe автоматически предлагал повысить (используя тот желтый диалог, который я вижу в других установках).

Еще лучше, я бы хотел, чтобы MSI сделал это и полностью покончил с setup.exe, но я думаю, что это и есть WiX 3.6, верно?

Если я создаю ускоритель, используя ApplicationRequiresElevation="true", это требует 7.0a SDK, правильно? Будет ли начальный загрузчик предлагать автоматическое повышение? Означает ли это, что приложение должно быть приложением .NET 4? Я бы так не думал ...

Ответы [ 2 ]

14 голосов
/ 04 января 2012

Мы использовали WiX 3.0 и смогли повысить привилегии. Тем не менее, мы не подняли наш загрузчик. Мы подняли сам файл MSI через свойство Package:

<Package Id="$(var.PackageCode)"
         Description="$(var.ProductName) $(var.Version)"
         InstallerVersion="301"
         Compressed="yes"
         InstallPrivileges="elevated"  <!-- Elevated right here -->
         InstallScope="perMachine"
         Platform="x86"/>

В качестве примечания, наш загрузчик подписан (с помощью signtool.exe из SDK v6.0A) нашим официальным сертификатом. Я не уверен, заставляет ли это загрузчик также требовать повышенных привилегий.

UPDATE:

В нашем проекте загрузчика setup.exe есть файл app.manifest, который требует запуска исполняемого файла на уровне администратора. Смотрите образец ниже:

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"
                xmlns:asmv1="urn:schemas-microsoft-com:asm.v1"
                xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
        <!-- UAC Manifest Options
            If you want to change the Windows User Account Control level replace
            the requestedExecutionLevel node with one of the following.

        <requestedExecutionLevel  level="asInvoker" uiAccess="false" />
        <requestedExecutionLevel  level="requireAdministrator" uiAccess="false" />
        <requestedExecutionLevel  level="highestAvailable" uiAccess="false" />

            If you want to utilize File and Registry Virtualization for backward
            compatibility then delete the requestedExecutionLevel node.
        -->
        <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
      </requestedPrivileges>
    </security>
  </trustInfo>
</asmv1:assembly>
0 голосов
/ 21 сентября 2017

Я знаю, что это старая тема, но может сэкономить время на следующую.Мне пришлось прочитать все комментарии, особенно custom action had Impersonate=yes...

. С другой стороны, пользовательские действия имеют атрибут Execute, связанный с привилегиями:

<CustomAction Id = "CA.First"  Execute ="immediate" ... />
<CustomAction Id = "CA.Second" Execute ="deferred"  ... />

CA.First всегда будет выполняться в пользовательском режиме,но CA.Second может иметь повышенные привилегии.

Может быть, здесь есть и другие приемы, связанные с привилегиями,
главное здесь - WiX позволяет управлять привилегиями на уровне CustomAction, поэтому убедитесь, что вы установили его правильно.

Элемент CustomAction

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...