Even with WIXUI_INSTALLDIR you can set the default to a per-user location, and launching the app after installation generally also does not generally require admin privs so that also does not prevent perUser. In that pure perUser package, they would get an error if they tried to navigate to and install under ProgramFiles.
It is true that using the VC .msm modules does require perMachine. However, you can use the "Deploying Visual C++ library DLLs as private assemblies" method instead of using the MSM modules to use the CRT for perUser applications, but you lose the ability to have Microsoft service your CRT DLLs using publisher's redirection that way (you will have to update your packages and ship the updates yourself to your users whenever MSFT updates them just like any other security fix). http://msdn.microsoft.com/en-us/library/ms235291.aspx : last section http://msdn.microsoft.com/en-us/library/ms235316.aspx : scenario #3 The mail you linked to shows just some of the grief caused by mixing perUser with perMachine, not by pure perUser. You can set a launch condition to prevent a user from setting ALLUSERS and running your installation package (assuming they don't modify the MSI), which would help mitigate the grief by preventing it in the first place. The intigorose.com page's list of grief is also caused by mixing perUser and perMachine (which is usually caused by setting ALLUSERS=2, which some tutorials/examples/other environments did/do by default) which is NOT a recommended practice (in fact, I remember reading someone's blog about ALLUSERS=2 being broken under UAC and recommending all computer shops ban that value, but I didn't notice it doing a quick search). You need to know the technologies and platforms you support, and how to limit your packages to the kinds of deployments you intend to support on those platforms. That includes adding launch conditions to prevent other's attempts to install things in a different way than you intend them to be deployed. Know also that each team at MSFT has their own goals and don't always coordinate with each other on making sure that the results are truly best practice or even possible on all the various platforms they collectively produce. Deployment is a technology platform area as large as .NET or Java or LAMP or any other, yet it often doesn't get the respect that is required to have it addressed in projects as it should to prevent these kinds of issues. Just as that happens at most other companies on the planet, it also happens at MSFT (they are humans more-or-less like the rest of us after all<grin/>). Also, often things are "supported" that are no longer really supported or recommended because they go against newer knowledge about how to maintain platform security, and so some advice given 10 years ago is now considered exactly counter to how it should be done today. -----Original Message----- From: warne warne [mailto:warne...@hotmail.com] Sent: Friday, September 11, 2009 6:11 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Vista Standard User and perMachine install Thanks thats certainly clarified it. My install is a 'WIXUI_INSTALLDIR' type so from what I read here: http://www.indigorose.com/webhelp/msifact/Concepts/Per-Machine_vs._Per-User_ Installations.htm that rules out perUser install. I also use a custom action to launch my app after install and Visual C merge .msm modules which, as Blair mentioned, may also rule out the perUser install. Would I be wrong then in thinking perUser installs are to be avoided generally speaking? Just perUser seems to cause grief. For example: http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg26517.html _________________________________________________________________ Use Hotmail to send and receive mail from your different email accounts. http://clk.atdmt.com/UKM/go/167688463/direct/01/ ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
