If in your authoring you associate the created user with a specific component AND you use so-called "late" scheduling of RemoveExistingProducts you will get what you want (because the component will remain during the entire upgrade). If you change the user data and need to "recreate" it to effect a change then you will need to have your component's keypath's "versioning" reflect the state of that user (so it will "recreate" the user using the new information only when the keypath is made "newer").
If you absolutely must use so-called "early" scheduling of RemoveExistingProducts then you will lose the ability to service the user account (you won't easily be able to reliably "recreate" the user using the newer definition). To do that, you will need to condition the custom action(s) that schedule the user-and-group operations to not run in both the install and uninstall phases of major upgrades. That is a heavy hammer, however: all user and group operations will be "frozen" in your entire MSI. Anything else will likely be fragile. The first is the recommended route. If you already follow the component rules, you should be able to use the that first method. -----Original Message----- From: Tony [mailto:yellowjacketl...@gmail.com] Sent: Tuesday, December 15, 2009 7:24 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] util:User, util:Group controlling sequencing... Couple more questions... What if we want the user created on install, removed during uninstall, but NOT removed during the "uninstall" that occurs during major upgrade? Do we create two components with a <util:User> component one with RemoveOnUninstall="yes" and the other with RemoveOnUninstall="no" and use a condition (where?) to select the correct component during the correct scenario? The add user to group mechanism seems fine, but the issue I see with the create user function being performed as a deferred action is that the end user feed back is horrible. What if we are given an invalid name, Password complexity, etc. All the user gets to see is a "error creating user account -2234234342". And rollback starts. Whereas if we were to create the user during the UI sequence, we can show the user the crazy error and dump them back on the account dialog asking them to verify the information they provided. This isn't as much of an issue for the group membership function as we can only add the user to existing groups. So, a simple type-o won't fail the install. On Mon, Dec 14, 2009 at 4:11 PM, Blair <os...@live.com> wrote: > None of those actions should ever occur during the UI sequence. The UI > sequence is intended exclusively for gathering information from the user to > guide the installation. -- Tony ---------------------------------------------------------------------------- -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
