Re: [WiX-users] backing up old file before removal
Sounds like you should probably schedule CopyFiles before RemoveFiles and/or InstallFiles (not sure of their default sequencing relative to one another), and re-schedule RemoveExistingProducts to just before or after InstallFinalize (instead of InstallInitialize). This is all done in the InstallExecute sequence. Cody On 10/7/08 4:03 PM, Joshua Chambers [EMAIL PROTECTED] wrote: Hello! So I am working on a new version of a program already out in the field. Thanks to a finger pointing in the right direction I have gotten the new installer to run when clicked on (before, the old one ran), now I have my upgrade stuff working fine and dandy, though I have just one problem. There is one file from the old version that I want to back up before it's removed. I see this CopyFile action, but I don't see where I can use it productively since the removing of the old version seems to happen pretty much behind the scenes, and the Component tag for the replacement file is not active until the installer part is running, after FindRelatedProducts has already run and removed the file. At what point can I stick an action in here to back this file up before the uninstall carries on? Thank you! Joshua - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Anyone have XSL for fixing up nested registry values?
What are you trying to do? That WiX snippet you describe below tells Windows Installer to write two separate strings to the same registry value. Do you mean to write a REG_MULTI_SZ? Or append Bar to ? Or are you just confusing the Value attribute and the Name attribute? For HKCR Foo @= , Bar (REG_MULTI_SZ, @ is the default value) Use RegistryKey Root=HKCR Key=Foo RegistryValue Type=multiString MultiStringValue/MultiStringValue MultiStringValueBar/MultiStringValue /RegistryValue /RegistryKey For HKCR Foo @= Bar= Use RegistryKey Root=HKCR Key=Foo RegistryValue Type=string Value=/ RegistryValue Name=Bar Type=string/ /RegistryKey Cody On 9/30/08 12:38 AM, Troy Howard [EMAIL PROTECTED] wrote: I read a message on here a while back where someone had written an XSL to fixup the primary key is duplicated errors caused by nested registry value elements like this example: RegistryKey Root=HKCR Key=Foo RegistryValue Type=string Value= / RegistryValue Value=Bar Type=string / /RegistryKey The XSL would convert these to single line RegistryValue tags. Anyone have an XSL or script that does this fixup? I'm trying not to reinvent the wheel. Thanks, Troy - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Directory Filesystem Attributes
Is there any way to set the system attribute on a directory that is created by the installer? The Directory element doesn't have Hidden and System attributes. Also, the File element does have Hidden and System attributes. Is there a way to set the attributes on an existing file not installed (or overwritten) by the installer? Cody Cutrer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] PermissionEx and WixQueryOsWellKnownSID properties
Are you running on Windows 2000? The Network Service account only exists on Windows XP and above. WIX_ACCOUNT_NETWORKSERVICE relies on a custom action in WixUtilExtension that creates the well-known SIDs for common accounts, and then uses an API call to get the localized names for them. This is so you can use them with the Permission element (which uses a built in Windows Installer action, which only recognizes Everyone and Administrators regardless of OS localization). However, the PermissionEx element is implemented as a WiX custom action, and supports using Everyone, Administrators, LocalSystem, LocalService, NetworkService, AuthenticatedUser, Guests, CREATOR OWNER, INTERACTIVE, and Users regardless of OS localization. The problem with the custom action that sets the well-known account localized names (WIX_ACCOUNT_NETWORKSERVICE, etc.), is that it fails on Windows 2000 because those accounts don't exist. This happens even if you have a condition that you never use those properties on a Windows 2000 system. So... If you need to use anything besides Administrators or Everyone, and you need to run your installer on Windows 2000, then it's best to use the PermissionEx element, and use the English names directly. Btw... Your error code is the HRESULT for Win32 error code 1789: ERROR_TRUSTED_RELATIONSHIP_FAILURE The trust relationship between this workstation and the primary domain failed, as a result of a call to LookupAccountNameW. Are you running this installer per-user or per-machine? I can't see how that could ever fail if you're doing it per-machine and the installer is running as SYSTEM. If it was per-user, I could see something weird like this happening, but probably means a weird security misconfiguration, or maybe just can't contact a domain controller or something. Generally even using WIX_ACCOUNT_NETWORKSERVICE should work with PermissionEx (it just looks up the SID directly from the name, instead of building a well-known SID). Cody Cutrer On 8/27/08 5:07 PM, Rob Mensching [EMAIL PROTECTED] wrote: Did you try NetworkService? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sleightholm Sent: Wednesday, August 27, 2008 15:26 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] PermissionEx and WixQueryOsWellKnownSID properties I am trying to change the permissions on a registry key like so: RegistryKey Id=RegCommon Root=HKLM Key=SOFTWARE\ACME\Common Action=create util:PermissionEx GenericAll=yes User=[WIX_ACCOUNT_NETWORKSERVICE] / /RegistryKey But when I run it I get this error in the log: ExecSecureObjects: Error 0x800706fd: failed to get sid for account: NT AUTHORITY\NETWORK SERVICE Action ended 23:15:46: InstallFinalize. Return value 3. Is it possible to use the WixQueryOsWellKnownSID properties with PermissionEx? Alternatively can I specify a SID (e.g. S-1-5-20) for the value of PermissionEx/@User? (I can't hardcode the network service account name as it changes on international versions of Windows.) Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ 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 Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Permission vs. PermissionEx and Users Group
According to http://msdn.microsoft.com/en-us/library/aa369774.aspx, you cannot specify the Users group, only Administrators or Everyone as the username for a Permission element. My first try for this was to use the WIX_ACCOUNT_USERS property, which is set as part of the WixQueryOsWellKnownSID custom action. This works great on Windows XP and Windows Vista. The problem is that under Windows 2000, the LocalService and NetworkService accounts don't exist, so the CA fails, even though I'm not referencing those properties (they get set in the same CA). I see two solutions... Either split the CA into WixQueryOsWellKnownSID and WixQueryOsWellKnownServiceSIDs so that if you don't need those ones, they won't run on Windows 2000 and won't have a problem. OR... Looking at the source code for CaExecSecureObjects which processes the PermissionEx element, it will properly lookup the SIDs for Users group, etc. So is WiX's PermissionEx as reliable as MSI's native LockObjects t able? If so, I can just use that and not worry about the CA working or failing. Cody Cutrer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
