Как установить с повышенными разрешениями с помощью установщика WiX?

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

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

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

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

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

ОТВЕТЫ

Ответ 1

Мы использовали 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) с нашим официальным сертификатом. Я не уверен, что это заставляет bootstrapper также требовать повышенные привилегии.

UPDATE:

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

<?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>

Ответ 2

Я знаю, что это старая тема, но может ли она сэкономить некоторое время на следующий.
Я должен был прочитать все комментарии, особенно 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