Compartir a través de

Link to an article describing how to create an MSI that does not prompt for elevation

  • Artículo

As I previously described in this blog post, Windows Installer will prompt users for elevation by default when running MSI-based setups on Windows Vista, but it is possible to opt out of this behavior by making some changes to your MSI.  If you choose to opt out though, you need to make sure that none of the actions in your MSI will require elevation (such as installing files to the GAC, writing registry values under the HKEY_LOCAL_MACHINE hive, etc).

This week, I ran across an interesting blog post that provides step-by-step instructions and example syntax that can be used to create an MSI in WiX v3.0 that does not prompt for elevation on Windows Vista.  This blog post can be found at this location:

https://blogs.msdn.com/jamesfi/archive/2007/05/02/making-an-msi-that-doesn-t-need-a-uac-lua-prompt.aspx

The author of this blog post also describes options for supporting both a per-user install (that does not prompt for elevation) and a per-machine install (that does prompt for elevation).  He demonstrates how to accomplish this within a single MSI, but points out some functional limitations that you will run into if you pursue this option.  The recommended alternative is to create separate MSIs - one for per-user installations and the other for per-machine installations.  Then you can use a bootstrapper setup.exe to determine at install time which MSI to install.

There is some really helpful information in this blog post, and I encourage setup developers who are interested in how to manage elevation prompts on Windows Vista to take a look at the example WiX code and documentation contained in this post.

Comments

  • Anonymous
    May 10, 2007
    Aaron, I have been reading your blog for a few months now and have modified all my msi packages to comply with UAC guidelines.  Thanks for your (and your teams) detailed notes. My app will need systemwide changes, so the above article will not work for me. But I have a related question regarding VCRTSP1 and UAC. Is it true that if I have a custom action dll which needs Visual studio runtime, I cannot comply with UAC guidelines (without using an external setup.exe?) I got redirected here from Nikola Dudar's blog http://blogs.msdn.com/nikolad/archive/2007/03/29/a-solution-to-two-references-to-different-versions-of-crt-mfc-atl-in-one-application-manifest-file.aspx#2524470 Thanks Raj

  • Anonymous
    May 11, 2007
    Hi Raj_vj - If you have a custom action DLL that depends on the VC 8.0 runtime files and you include the VC runtime files MSMs in your MSI, then you have to use a commit custom action on Windows Vista to ensure that the VC runtime files are fully installed.  I don't think that will automatically mean, however, that you will lose the UAC functionality that you need.  You should be able to use the flags msidbCustomActionTypeInScript + msidbCustomActionTypeNoImpersonate + msidbCustomActionTypeCommit (type 3584) in your custom action. There is more information about these flags at http://msdn2.microsoft.com/en-us/library/aa368069.aspx, and links to more general UAC information at http://blogs.msdn.com/astebner/archive/2006/12/13/some-useful-things-i-have-learned-about-windows-installer-and-uac.aspx that might be helpful in this scenario. One other note here - it would be best to try to avoid needing this custom action at all if possible.  Also, it is a best practice to not depend on something in your setup that is installed earlier in the same setup, so you may want to try to eliminate the VC 8.0 runtime dependency for this custom action if you can't get rid of the custom action altogether.  It might also be an option for you to statically link to the VC runtimes.