Quasi sicuramente si sta verificando una euristica di compatibilità con Windows Installer Detection Technology. Windows cercherà di rilevare quando un'applicazione è un programma di installazione e probabilmente deve essere elevata.
Installer Detection si applica solo a:
- 32 eseguibili bit
- Applicazioni senza un
requestedExecutionLevel
- processi interattivi in esecuzione come utente standard con LUA abilitato
Prima di una 32 processo di bit viene creato, i seguenti attributi vengono controllati per determinare se si tratta di un programma di installazione:
- Nome file include parole chiave come "installazione", "messa a punto", "aggiornamento", ecc
- Parole nei seguenti settori delle versioni di risorse: fornitore, il nome dell'azienda, il nome del prodotto, file di descrizione, originale nome del file, interno Nome ed Esporta nome.
- Parole chiave nel file side-by-side incorporato nell'eseguibile.
- Parole chiave in voci StringTable specifiche collegate nell'eseguibile.
- Attributi chiave nei dati RC collegati nell'eseguibile.
- Sequenze mirate di byte all'interno dell'eseguibile.
Quindi, come ha detto lei:
ma ho un exe che controlla la disponibilità di aggiornamenti per il software
La mia ipotesi è che questo CheckForUpdates.exe sta provocando l'euristica di compatibilità.
Il corretta cosa da fare è quella di un un'assemblea manifesta al "controllo" eseguibile, informando di Windows che dovrebbe non elevare l'utilità. Questo viene fatto con un requestedExecutionLevel di asInvoker nel manifesto:
AssemblyManifest.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="client"
type="win32"
/>
<description>Update checker</description>
<!-- Run as standard user. Disable file and registry virtualization -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
In questo modo il "Check for Updates" applicazione sarà mai elevare, e mai ottenere erroneamente privilegi amministrativi .
Se si desidera che il programma di aggiornamento sia effettivamente applicare gli aggiornamenti (aggiornamenti che richiedono privilegi di amministratore), si avvia l'applicazione di aggiornamento come amministratore.
codice di esempio
//Check if there are updates available
if (!CheckForUpdatesAvailable())
return; //no updates. We're done
//If the user is an administrator, then get the update
if (IsUserAnAdmin())
{
//Maybe throw in a "Hey, user, wanna get the update now?" dialog
DownloadAndApplyUpdates();
return;
}
//The user is not an admin.
//Relaunch ourselves as administrator so we can download the update
//Maybe throw in a "Hey, user, wanna get the update now?" dialog. A button with a UAC shield on it
ExecuteAsAdmin(Application.ExecutablePath, "/downloadUpdate");
con le funzioni di supporto:
private Boolean IsUserAnAdmin()
{
//A user can be a member of the Administrator group, but not an administrator.
//Conversely, the user can be an administrator and not a member of the administrators group.
var identity = WindowsIdentity.GetCurrent();
return (null != identity && new WindowsPrincipal(identity).IsInRole(WindowsBuiltInRole.Administrator));
}
private void ExecuteAsAdmin(string Filename, string Arguments)
{
ProcessStartInfo startInfo = new ProcessStartInfo(Filename, Arguments);
startInfo.Verb = "runas";
System.Diagnostics.Process.Start(startInfo);
}
Allora non vi resta che cercare il parametro di riga /downloadUpdate comando all'avvio per sapere che sei lavoro è effettivamente fare il lavoro:
public Form1()
{
InitializeComponent();
//Ideally this would be in program.cs, before the call to Application.Run()
//But that would require me to refactor code out of the Form file, which is overkill for a demo
if (FindCmdLineSwitch("downloadUpdate", true))
{
DownloadAndApplyUpdates();
Environment.Exit(0);
}
}
Nota: Qualsiasi codice è rilasciato nel pubblico dominio. Nessuna attribuzione richiesta.
Aggiungerò che le regole dei nomi dei file sopra elencate sono quasi certamente incomplete. Aneddoticamente un'app che richiede UAC se denominata come APP123.exe NON reqiure UAC se rinominata in APP.exe. – DaveInCaz