Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
800 views
in Technique[技术] by (71.8m points)

installation - Run ExeCommand in customAction as Administrator mode in Wix Installer

I am new to wix installer. I have developed a set-up using wix installer for my application and I need to execute a Custom Action to run a command in cmd.exe. In XP it works fine. But in Windows 8 & 7 the cmd prompt needs to be run as administrator.

I have googled and found the keywords Elevated Privileges and impersonate might help me.

<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine"   InstallPrivileges="elevated"></Package>

As you can see above, I used the InstallScope attribute set to perMachine, and I have used Impersonate="No" in the CustomAction element:

 <CustomAction Id='comReg' Directory='INSTALLLOCATION'  Impersonate='no'  
  ExeCommand='"[NETFRAMEWORK40CLIENTINSTALLROOTDIR]regasm.exe" "[INSTALLLOCATION]myProduct.dll"  /codebase' Return='check' />

But I didn't get any changes while installating. I need the command prompt to open and run the above command in Administrator Mode.

And can anyone please tell me about these keywords "Elevated Privileges & impersonate"

<InstallExecuteSequence>
  <Custom Action='comReg' After='InstallFinalize'>NOT REMOVE</Custom>
  <Custom Action='comUnreg' Before='RemoveFiles'>REMOVE</Custom>
</InstallExecuteSequence>

How to do it?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

The wix documentation here explains the Impersonate attribute:

This attribute specifies whether the Windows Installer, which executes as LocalSystem, should impersonate the user context of the installing user when executing this custom action. Typically the value should be 'yes', except when the custom action needs elevated privileges to apply changes to the machine.

You also need to understand the difference between deferred and immediate custom actions. See the Execute attribute on the same help page:

This attribute indicates the scheduling of the custom action. This attribute's value must be one of the following:

deferred Indicates that the custom action runs in-script (possibly with elevated privileges). immediate Indicates that the custom action will run during normal processing time with user privileges. This is the default.

At present your custom action is immediate, which means it is running with user privileges. See this blog post for lots of details, but particularly:

Any immediate custom actions impersonate the invoking user. Before Windows Vista this wasn't a problem since at this point the installing administrative user had a privileged token. With the introduction of UAC in Windows Vista the default administrative token with UAC enabled is a filtered token and does not hold all privileges. Since immediate custom actions are not supposed to modify machine state - only to gather state data and schedule custom actions to run deferred - this still shouldn't be a problem. After all, at this point the generation of the installation and rollback scripts is all that should be going on.

You should never modify machine state with an immediate custom action. Use a deferred one, and keep impersonate to no, and it should work:

<CustomAction Id='comReg' Directory='INSTALLLOCATION' Execute='deferred' Impersonate='no' ExeCommand='"[NETFRAMEWORK40CLIENTINSTALLROOTDIR]regasm.exe" "[INSTALLLOCATION]EAWordImporter.dll" /codebase' Return='check' />

EDIT: Schedule the custom action using the InstallExecuteSequence element:

<InstallExecuteSequence>
    <Custom Action='comReg' Before='InstallFinalize'/>
</InstallExecuteSequence>

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...