2016-02-17 18 views
8

Mamy aplikację desktopową x 86 Win32. Gdy instalator jest uruchamiany przez użytkownika standardowego (nie administratora), unikamy podnoszenia i/lub pokazywania komunikatu UAC i instalowania pod numerem C:\Users\username\AppData\Roaming\... zamiast zwykłego katalogu Program Files.Jak zabezpieczyć dezinstalator przed standardowym użytkownikiem systemu Windows 10?

W systemie Windows 10 po uruchomieniu naszego deinstalatora pod numerem Control Panel -> Programs -> Programs and Features nie pojawi się monit UAC, a deinstalator działa bez podnoszenia. To pożądane zachowanie. Po uruchomieniu tego samego deinstalatora z poziomu Start -> Settings -> System -> Apps & features wyświetlany jest monit UAC.

(To samo zachowanie można zaobserwować w Opera przeglądarka instalatora/deinstalatora. Testowałem v35.0.2066.37.)

Dlaczego sama Uninstaller zachowują się inaczej, gdy uruchomiony z Apps & features kontra Programs and Features?

W jaki sposób można uniknąć monitu UAC, gdy deinstalator jest uruchamiany z funkcji Aplikacji &?

Manifest naszego deinstalatora Obejmuje to:

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

Próbowałem zmieniając requestedExecutionLevel, a także próbował usuwania trustInfo całkowicie, ale nie było żadnych zmian w zachowaniu obu kierunkach.

Testowane w systemie Windows 10 wersja 1511 kompilacja 10586.104.

Edit: prostu do wyjaśnienia sprawa Próbuję sobie to, gdzie użytkownik ma konto w normie i nie znać hasło konta administratora. Jeśli widzą monit UAC, gdy próbują odinstalować, nie mają wyboru, ale muszą go anulować, a nasz deinstalator nie uruchamia się.

+0

Właśnie spędziłem poranek zajmując się tą "funkcją". Jedynym podejściem, które zadziałało, było to, aby deinstalator ponownie uruchomił się jako bieżący użytkownik. Oto opis podejścia, które wykorzystuje program Explorer do ponownego uruchomienia pliku wykonywalnego: http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you -part-2-how/ używamy NSIS, więc byliśmy w stanie wykorzystać ShellExecAsUser plug-in, który jest oparty na pierwszym linkiem: http://nsis.sourceforge.net/ShellExecAsUser_plug-in –

+0

I załóżmy, że nie rozwiązuje to podstawowego problemu, ale dla nas problem polega na tym, że deinstalacja kończy się niepowodzeniem, gdy uruchamiany jest podniesiony, ponieważ musi uzyskać dostęp do HKCU i LocalAppData.Nie rozwiązuje to problemu zapobiegania podwyższeniu poziomu głośności, ale nawet instalacja przeglądarki Chrome (i jak wspomniałeś Opera) w wersji CurrentUser cierpi z powodu tego samego problemu z podniesieniem w systemie Windows 10 po odinstalowaniu z Google Apps i funkcji, więc uważamy, że wystarczy, aby nie fail i do wykonania jako bieżący użytkownik, niezależnie od tego, czy został uruchomiony, czy też nie. –

Odpowiedz

3

To jest błąd w "Apps & funkcji", o ile wiem. Ludzie z WiX mają closed this issue jako błąd Windowsa i przypuszczam, że powiadomili o tym poprawnych ludzi @ Microsoft. Zachowanie jest nadal takie samo w wersji Insider 15042, więc prawdopodobnie nie zostanie ustalone na czas w aktualizacji Creators.

Nie istnieje obejście, które można zastosować, jeśli standardowy użytkownik nie może podwyższyć.

Jeśli mogą podnieść, możesz użyć re-spawn workaround opublikowanego w komentarzach lub ręcznie załadować profil użytkownika i zadzwonić pod numer RegOverridePredefKey, ale oba są brzydkimi hakerami (IMHO).

+0

Właśnie uratowałeś mi śmieszną ilość debugowania, dziękuję. – johnwbyrd

Powiązane problemy