For the test scenario, go to Add/Remove Programs and select "Repair", and make sure that the registry value doesn't change (test from each of the two initial states).
Not sure why it doesn't delete, but you could try adding a RemoveRegistryKey element to the same component. -----Original Message----- From: little.forest [mailto:little.for...@ymail.com] Sent: Thursday, November 05, 2009 5:35 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix 3.0: link error when using '*' in the component's GUID field Thanks Blair. I tried it by using your code example. It works! But I found a problem, after uninstallation, this registry entry is still in the registry. Even if I use "createAndRemoveOnUninstall", it's still there. I checked the uninstall log, it doesn't say if the delete key operation is okay or not: MSI (s) (D0:C0) [17:25:45:891]: Executing op: RegRemoveValue(Name=MyApp 3.0,Value="[INSTALLLOCATION]MyApp30.exe"[RunWhenWindowsStartsArgument],) MSI (s) (D0:C0) [17:25:45:891]: Note: 1: 1402 2: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run 3: 2 MSI (s) (D0:C0) [17:25:45:891]: Executing op: RegRemoveKey() What can I do to make sure this registry entry is deleted upon uninstalling? Also, you mentioned "You may need to preserve RUNWHENWINDOWSSTART and restore it during repairs and/or small updates/minor upgrades so that the value doesn't change during a repair." - we use major upgrade, does it matter for us? If so, what is the use case or test scenario to verify our install is fine with this restraint? Thanks. ________________________________ From: Blair <os...@live.com> To: General discussion for Windows Installer XML toolset. <wix-users@lists.sourceforge.net> Sent: Friday, October 30, 2009 5:54:06 PM Subject: Re: [WiX-users] Wix 3.0: link error when using '*' in the component's GUID field Identity theft is always such a pain. compone...@guid='*' is required to generate a "stable" guid. That means that if the component's keypath didn't change, it is the same component. As a result, both of your components, which share the exact same keypath, are the same component as far as Windows Installer is concerned (they share the same identity). The value isn't part of the keypath, unfortunately. What you may consider doing instead is (since your components are currently not transitive and are mutually exclusive) is something like this: <SetProperty Id='RunValueArgument' Value=' -bootload' Sequence='execute' Before='WriteRegistryValues'><![CDATA[RUNWHENWINDOWSSTART <> 1]]></SetProperty> <Component Id="RunRegistry" Guid="*"> <RegistryKey Root="HKCU" Key="Software\Microsoft\Windows\CurrentVersion\Run" Action="create"> <RegistryValue Type="string" Name="$(var.ProductName)" Value='"[INSTALLLOCATION]$(var.FileOutput)"[RunValueArgument]' KeyPath="yes" /> </RegistryKey> </Component> You may need to preserve RUNWHENWINDOWSSTART and restore it during repairs and/or small updates/minor upgrades so that the value doesn't change during a repair. -----Original Message----- From: little.forest [mailto:little.for...@ymail.com] Sent: Friday, October 30, 2009 2:27 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0: link error when using '*' in the component's GUID field We use Wix 3.0.4805.0. We run into a very strange link error: we have a component that uses "*" as the GUID. But when we link it, it reports an error: error LGHT0204 : ICE08: Component: RegistrySpecial has a duplicate GUID: {A7C1768B-FF73-5DFC-8E76-E810E013F78A} But I searched all of our source code, there is no GUID "{A7C1768B-FF73-5DFC-8E76-E810E013F78A}" defined anywhere. Here is the command line to compile and link it: candle.exe -dRelease -out <.wixobj file> -arch x86 -ext <ext dll files> myapp.wxs light.exe -ext <EXT_DLL_FILE> -cultures:en-us -out myapp.msi -pdbout <PDB_FILE> -loc <LANG_FILE> <some .wixobj files> Basically, this is what we'd like to do: there is an option called "Start application when Windows starts". If the end user select this option, we'll write the application's file path to a registry entry; if the end user doesn't select this option, we'll also write the entry with a parameter. The logic is just like this: if (RUNWHENWINDOWSSTART) { write registry with "[PATH_TO_APP]" } else { write registry with "[PATH_TO_APP] -bootload" } Here is the code: <Component Id="RegistryNormal" Guid="*"> <Condition>RUNWHENWINDOWSSTART = 1</Condition> <RegistryKey Root="HKCU" Key="Software\Microsoft\Windows\CurrentVersion\Run" Action="create"> <RegistryValue Type="string" Name="$(var.ProductName)" Value='"[INSTALLLOCATION]$(var.FileOutput)"' KeyPath="yes" /> </RegistryKey> </Component> <Component Id="RegistrySpecial" Guid="*"> <Condition><![CDATA[RUNWHENWINDOWSSTART <> 1]]></Condition> <RegistryKey Root="HKCU" Key="Software\Microsoft\Windows\CurrentVersion\Run" Action="create"> <RegistryValue Type="string" Name="$(var.ProductName)" Value='"[INSTALLLOCATION]$(var.FileOutput)" -bootload' KeyPath="yes" /> </RegistryKey> </Component> I thought "*" will generate GUID for each component. But how come it reports that error? And it's always that ID. What is special about that ID? The interesting thing is, if I delete one of the two components from the code, the compile/link is fine. So it seems the root of the problem is that I'm having these two components at the same time. Why I can't have these two components at the same time? This is really a if-then-else scenario. Maybe I shouldn't have two components to implement the logic? Is there any other way to implement this? Thanks. /Brian __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ ---------------------------------------------------------------------------- -- 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 __________________________________________________________________ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca ---------------------------------------------------------------------------- -- 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
