Ce n'est pas une bonne solution. Rien ne garantit que l'utilisateur courant est administrateur (requis par ton installateur) et s'il ne l'est pas, ce n'est pas son répertoire qui sera supprimé mais bien celui de l'admin. Comme déjà dit, il faudrait passer par Active setup pour cela.
Cela dit, si l'utilisateur a apporté des modifications, est-ce bien judicieux de les écraser ?
Le manifest peut être interne (compilé dans l'exe) ou externe (fichier séparé).
A l'aide du bloc-notes, crée ce fichier (ce qui est en rouge peut être personnalisé) :
Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20 <?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="MonProg" type="win32"/> <description>Mon programme</description> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"/> </dependentAssembly> </dependency> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly>
Nomme-le du nom de ton app avec l'extension .manifest. Si le programme s'appelle monprog.exe, il se nommera monprog.exe.manifest.
Voilà, à installer dans le même répertoire que ton application
Certaines informations peuvent être en cache, il faudra peut-être un reboot.
Dernier détail mais... de taille. Si ce programme écrit dans Program Files, tu n'es pas au bout de tes soucis. Il faudra soit désactiver l'UAC, soit le lancer en admin. Sinon erreur 5 (access denied).
Empêcher la virtualisation est une chose mais cela ne corrigera pas des erreurs de conception !
Partager