As I understand it, UAC elevation in Vista and Win 7 can be done by the application through its manifest file, or programmatically.
Setting the UAC level in the manifest file can be done with a simple parameter change to one of the attributes:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="22.214.171.124" name="MyFancyApp" type="win32"/>
The manifest file can be exposed (file MyFancyApp.exe.manifest) or it can be embedded in the application exe. I believe that for security purposes, the manifest must be embedded for an admin rights request to be granted.
The other way is to request it programmatically:
ProcessStartInfo proc = new ProcessStartInfo();
proc.WorkingDirectory = Directory.GetCurrentDirectory();
Doing this programmatically is useful if you need to elevate for a particular reason (e.g., adding files to a folder that requires admin rights to access) temporarily, and then later wanting to reduce the access level.
With dotNetZip, I couldn't figure out which manifest file to manipulate (nor could I find a manifest file), so I thought I'd try a programmatic UAC elevation. Unfortunately, this didn't work. It could be my problem (e.g., I'm doing it wrong),
but I'm not sure.
As to elevating EXEs that are not Vista/Win7 -aware, I suppose you could inform the user (using written instructions sent via email) to right-click the exe and click, "run as administrator". This will work. Unfortunately, for my particular
application, the self-extracting exe is being sent to a remote factory located half-way around the world where it is to be installed by someone who is neither computer literate nor a native English speaker, so anything I can do to reduce the level of user
interaction is important. Previously, the staff at this factory was having trouble copying files sent via email in a zip file and putting them into a particular folder on a PC in an assembly line environment.