Re: [WiX-users] WOW6432Node registry trouble for 64 bit MSI
I now know the issue lies in our build script (which changes the attribute value) & the fact that I also created another 64 bit component to write to the same registry (I intend to write to both WOW6432 and counter part outside WOW6432, but seems I have to use different regkey name). From: Fei Cao Sent: Thursday, July 19, 2007 12:16 PM To: 'wix-users@lists.sourceforge.net' Subject: WOW6432Node registry trouble for 64 bit MSI Hi, I want the 64 bit installer to write to WOW6432Node registry, which is used for 32 bit application, and the 64 bit components will not write to registries under WOW6432Node. >From WIX help file for element: Win64 YesNoType Set this attribute to 'yes' to mark this as a 64-bit component. This attribute facilitates the installation of packages that include both 32-bit and 64-bit components. If this bit is not set, the component is registered as a 32-bit component. If this is a 64-bit component replacing a 32-bit component, set this bit and assign a new GUID in the Guid attribute. So I created the following component with win64 attribute set to NO to indicate this is 32 bit component, but after build the amd64 MSI still has the attribute value for this component as 260 (256+4). Consequently the setup didn't really write to the WOW6432NODE. #ifndef _X86_ #endif >From the help on Component Table at >http://msdn2.microsoft.com/en-us/library/aa368007.aspx msidbComponentAttributes64bit 256 0x0100 Set this bit to mark this as a 64-bit component. This attribute facilitates the installation of packages that include both 32-bit and 64-bit components. If this bit is not set, the component is registered as a 32-bit component. If this is a 64-bit component replacing a 32-bit component, set this bit and assign a new GUID in the ComponentId column. I even tried to manually change the 260 to 4, but still didn't work. Any clue ? thanks! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WOW6432Node registry trouble for 64 bit MSI
Hi, I want the 64 bit installer to write to WOW6432Node registry, which is used for 32 bit application, and the 64 bit components will not write to registries under WOW6432Node. >From WIX help file for element: Win64 YesNoType Set this attribute to 'yes' to mark this as a 64-bit component. This attribute facilitates the installation of packages that include both 32-bit and 64-bit components. If this bit is not set, the component is registered as a 32-bit component. If this is a 64-bit component replacing a 32-bit component, set this bit and assign a new GUID in the Guid attribute. So I created the following component with win64 attribute set to NO to indicate this is 32 bit component, but after build the amd64 MSI still has the attribute value for this component as 260 (256+4). Consequently the setup didn't really write to the WOW6432NODE. #ifndef _X86_ #endif >From the help on Component Table at >http://msdn2.microsoft.com/en-us/library/aa368007.aspx msidbComponentAttributes64bit 256 0x0100 Set this bit to mark this as a 64-bit component. This attribute facilitates the installation of packages that include both 32-bit and 64-bit components. If this bit is not set, the component is registered as a 32-bit component. If this is a 64-bit component replacing a 32-bit component, set this bit and assign a new GUID in the ComponentId column. I even tried to manually change the 260 to 4, but still didn't work. Any clue ? thanks! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] how to alwyas overwrite GAC assembly in fresh setup
It looks like if we want to specify an install for GAC assembly dll, we have to use Assembly='.net' in the element, which will require KeyPath has to be set as "yes" (otherwise we'll have a build error when running candle.exe). Then this way, if GAC assembly has been left behind, then another fresh install wont overwrite that dll. How can we ensure the GAC assembly can always be overwritten? Below is just an example. Thanks, Fei - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] conditionally ACL folder with embedded in a possible?
http://www.mail-archive.com/wix-devs@lists.sourceforge.net/msg01483.html I found the above link gave an account regarding the issue that WIX is not able to conditional ACL a folder using in a ,e.g., ... . . I bumped into a similar issue: The component 'c_LogFiles', 'c_LogFilesForConsoleOnly' and 'c_LogFilesForFullInstallOnly' belong to different . That are conditinally switched on/off. The [WUS_ADMINISTRATORS] and [WSUS_REPORTERS] are conditionally created also. When installing with console only option, the LogFilesForFullInstallOnly' is switched off, and [WUS_ADMINISTRATORS] [WSUS_REPORTERS] are not to be created. Therefore, shouldn't the SID checking for those group be skipped? Yet I got the following errors: ExecSecureObjects: Error 0x80070534: failed to get sid for account: WSUS Administrators -they should not be created nor should the SID for that group be checked accordingly. Note here I set Extended='yes" (in order to avoid using LockPermission table) for the two security groups [WUS_ADMINISTRATORS], [WSUS_REPORTERS] as they are not pre-existent users, while LockPermission table requires the user exists beforehand. Actually my earlier test even showed that with the Extended='yes' set for [NETWORKSERVICE_ACCOUNT], the following errors will be generated: ExecSecureObjects: Error 0x80070534: failed to get sid for account: NT AUTHORITY\NETWORK SERVICE I am not sure if the WIX can recognize the sid for network services by now in ExecSecureObjects Thanks, Fei - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
