Как предотвратить повышение уровня удаления для стандартного пользователя Windows 10?

Question

У нас есть настольное приложение x86 для Win32. Когда установщик запускается обычным пользователем (не администратором), мы избегаем повышения и / или отображения запроса UAC и устанавливаем в C:\Users\username\AppData\Roaming\... вместо общего Program Files каталог.

В Windows 10, когда наш деинсталлятор запускается из Control Panel -> Programs -> Programs and Featuresприглашение UAC не отображается, и программа удаления работает без повышения прав. Это желаемое поведение. Когда тот же самый деинсталлятор запускается из Start -> Settings -> System -> Apps & featuresотображается приглашение UAC.

(Такое же поведение можно увидеть в установщике / удалении браузера Opera. Я протестировал v35.0.2066.37.)

Почему один и тот же деинсталлятор ведет себя по-разному при запуске из Apps & features против Programs and Features?

Как можно избежать запроса UAC при запуске деинсталлятора из приложений и функций?

Манифест нашего деинсталлятора включает в себя следующее:

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
   <security>
      <requestedPrivileges>
         <requestedExecutionLevel level="asInvoker" />
      </requestedPrivileges>
   </security>
</trustInfo>

Я пытался изменить requestedExecutionLevel, а также попытался удалить trustInfo полностью, но не было никаких изменений в поведении в любом случае.

Протестировано на Windows 10 версии 1511, сборка 10586.104.

Редактировать: просто чтобы уточнить, случай, который я пытаюсь решить, это когда пользователь имеет стандартную учетную запись и не знает пароль учетной записи администратора. Если при попытке удаления они увидят приглашение UAC, у них не будет другого выбора, кроме как отменить его, и наш деинсталлятор не запустится.

Answer 1

Насколько я знаю, это ошибка в "Приложениях и функциях". Пользователи WiX закрыли эту проблему как ошибку Windows, и я предполагаю, что они уведомили правильных людей @ Microsoft. Поведение в Инсайдерской сборке 15042 остается таким же, хотя, вероятно, оно не будет исправлено вовремя для Обновления Создателей.

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

Если они могут подняться, то вы можете использовать обходной путь повторного вызова, опубликованный в комментариях, или вручную загрузить профиль пользователя и вызвать RegOverridePredefKey но они оба безобразные хаки (имхо).