Not to flog a dead horse or anything, but consider this scenario I create my single installer package. Inside I provide two different features: - Feature 1: All Users (Per Machine) install, will required elevation - Feature 2: Per User install, can be installed by any standard user or better.
Structure the UI so that only one of the two features can be set. So here are a few scenarios: Scenario A: - I install for All Users (as admin). Everyone can use it. - If another user tries to install again, it goes to Maintenance mode as per usual. - Only if the user is an admin could he change it from All Users to Current User in maintenance mode. Or Uninstall, Repair, etc. Scenario B: - I install for Current User. Only I can see the install - If another (standard) user performs the installation, they can perform the Current User install (only) and can access the installation. Either I or the other user can uninstall our instances without impact on the other. - If a user (admin) performs an install for All Users, I am not sure what would happen. But all users should be able to access the installation. My installation would either still be my primary installation, or it would be superseded by the All Users install. Either way I could still run the installed product. I could later uninstall my installation and still have access to the All Users installation. Does this make any sense? Are there any drawbacks to this thinking? Thanks, Andreas Mertens -----Original Message----- From: Blair [mailto:os...@live.com] Sent: November-03-09 9:47 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine Sorry if I am confusing you. I recommend you decide upfront if your installation will be per-user or per-machine. Don't try to make a package that is intended to be switchable. Then author the package based on your decision. MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make workable packages that can be switched during installation. However, the advice is still: don't do it. Make it one or the other and prevent the one you don't support. -----Original Message----- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Tuesday, November 03, 2009 9:28 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Per User / Per Machine Blair, now I am more confused than before. On one hand you say, I shall write a .msi that is either perUser OR perMachine, on the other hand you say that it is very hard to do when not using MSI 5 (which is only available on Windows 7). So for me this reads like: "For a MSI beginner it is impossible to write a correctly working setup on any OS before W7.";-( Regards Markus > -----Original Message----- > From: Blair [mailto:os...@live.com] > Sent: Montag, 2. November 2009 21:43 > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Per User / Per Machine > > All resources (files, registry entries, etc.) can generally be divided > into > three spaces: those that live in administrator per-machine areas > (C:\Program > Files, etc.), those that live in the user profile, and those very few > that > live in shared document regions. > > If your installation requires access to administrator-controlled > regions of > the computer, it should be a pure perMachine and NOT place anything in > perUser (profile) areas, and vice-versa. Until MSI 5.0 (which is > currently > only available on Windows 7 AFAIK) it has been extremely difficult to > author > a package that can go either way, although it was somewhat easier > before > Vista/UAC entered the picture. > > Administrators are supposed to follow author's guidelines when using > advertising to make a program available to users. /ju and /jm don't > actually > install the software and they don't set ALLUSERS. > > Also, personally, I haven't found /ju to be very useful: it doesn't > provide > a place to designate the user to advertise to, and if that user doesn't > already have admin privileges, the command will fail while if the user > does > have those privileges, the command isn't needed. Then again, maybe I > haven't > found the magic incantation yet. > > -----Original Message----- > From: Markus Karg [mailto:markus.k...@gmx.net] > Sent: Monday, November 02, 2009 11:01 AM > To: 'General discussion for Windows Installer XML toolset.' > Subject: [WiX-users] Per User / Per Machine > > Blair, > > in a different context you wrote: > > > It is best to make your installations pure-perMachine or pure- > > perUser > > and never mix them > > There is one thing I do not understand in that context: I always had > the > impression that it is up to the *administrator* to decide whether to > install > a software Per User / Per Machine: Isn't that what msiexec's /ju and > /jm > options are good for? > > Now reading your above comment (and the MSDN chapter about the ALLUSERS > property) I am a bit confused. > > If it is up to the .msi *author* to decide about Per User / Per Machine > (using the ALLUSERS property), for what is /ju and /jm good then? And > what > will happen if my .msi file is for Per User, but the administrator is > using > /jm (or vice versa)? > > Thanks > Markus > > > ----------------------------------------------------------------------- > ----- > -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ----------------------------------------------------------------------- > ------- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ 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 ------------------------------------------------------------------------------ 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
