Wix 3.0: link error when using '*' in the component's GUID field

[little.forest]

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Blair-2]

Identity theft is always such a pain.

Component\@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:[hidden email]]
Sent: Friday, October 30, 2009 2:27 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[little.forest]

Thanks Blair.

Your code example makes sense. I'm going to try it.

However, you also said "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. " - I'm not quite getting this one.
We use major upgrade. I'm not sure this would apply. Could you tell me how to preserve RUNWHENWINDOWSSTART and restore it?

Thanks.




________________________________
From: Blair <[hidden email]>
To: General discussion for Windows Installer XML toolset. <[hidden email]>
Sent: Fri, 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.

Component\@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:[hidden email]]
Sent: Friday, October 30, 2009 2:27 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users



      __________________________________________________________________
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Andreas Mertens]

I have an interesting scenario that I cannot figure out.  This takes place
under Vista - XP doesn't seem to have this problem.
The application I have is using a slightly modified version of the
WixUI_Advanced installer - all I have done is add an addition, very simple
dialog.

I have two user accounts on the same Vista machine.  User A is an admin, and
User B has a standard user account.
My install has two parts: the first is a bootstrap install that requires
admin privileges, and the second part that can be installed for either the
current user or all users.  The idea is that the bootstrap install should
only need to be done once (by an admin), then everyone on that machine can
chose to install the second part as they wish.

I start with User A, and do the install.  The bootstrap install runs fine,
and when I then install the second part, I choose to do a PerUser install.
No problems, all installs well.

I now switch to User B (non-admin).  I run the same installer, which skips
the bootstrap install (already there for all users) and goes straight to the
second part.  I notice that as I go through the install, when I get to the
InstallScopeDlg, that it gives me the choice of installing for either the
current user or all users.  This in itself is kind of odd, because User B
(as a non-admin) should not be offered the choice.  In XP the user is shown
a screen that states that he can only install for the current user.

I choose to install for the current user (PerUser), and when the install is
executed, it prompts me for the admin credentials of User A (admin). ???  If
I provide these credentials, the install completes, with the file installed
correctly for the current user.

When I check the install log for User B, I see the following (I have "XXXX"
the text that is specific to my client's product):

...
MSI (c) (10:78) [18:54:32:252]: SHELL32::SHGetFolderPath returned:
C:\Users\Public\Desktop
MSI (c) (10:78) [18:54:32:252]: SHELL32::SHGetFolderPath returned:
C:\Windows\Fonts
MSI (c) (10:78) [18:54:32:252]: Note: 1: 2898 2: MS Sans Serif 3: MS Sans
Serif 4: 0 5: 16
MSI (c) (10:78) [18:54:32:262]: MSI_LUA: Setting AdminUser property to 1
because this is the client or the user has already permitted elevation
MSI (c) (10:78) [18:54:32:262]: PROPERTY CHANGE: Adding AdminUser property.
Its value is '1'.
MSI (c) (10:78) [18:54:32:262]: PROPERTY CHANGE: Adding Privileged property.
Its value is '1'.
MSI (c) (10:78) [18:54:32:262]: Note: 1: 1402 2:
HKEY_CURRENT_USER\Software\Microsoft\MS Setup (ACME)\User Info 3: 2
MSI (c) (10:78) [18:54:32:262]: PROPERTY CHANGE: Adding USERNAME property.
Its value is 'IETester'.
MSI (c) (10:78) [18:54:32:262]: Note: 1: 1402 2:
HKEY_CURRENT_USER\Software\Microsoft\MS Setup (ACME)\User Info 3: 2
MSI (c) (10:78) [18:54:32:262]: PROPERTY CHANGE: Adding DATABASE property.
Its value is 'C:\Users\TestAcct\AppData\Local\Temp\61d10b.msi'.
MSI (c) (10:78) [18:54:32:262]: PROPERTY CHANGE: Adding OriginalDatabase
property. Its value is
'C:\Users\TestAcct\Desktop\XXXX-setup-0.9.1.1-Oct242009-1615hrsPST\New
Folder\Theme.msi'.
MSI (c) (10:78) [18:54:32:262]: PROPERTY CHANGE: Adding SourceDir property.
Its value is
'C:\Users\TestAcct\Desktop\XXXX-setup-0.9.1.1-Oct242009-1615hrsPST\New
Folder\'.
MSI (c) (10:78) [18:54:32:262]: PROPERTY CHANGE: Adding SOURCEDIR property.
Its value is
'C:\Users\TestAcct\Desktop\XXXX-setup-0.9.1.1-Oct242009-1615hrsPST\New
Folder\'.
MSI (c) (10:0C) [18:54:32:272]: PROPERTY CHANGE: Adding VersionHandler
property. Its value is '4.00'.
...

>From above I see that:
- IETester is the name of the Admin User A, not User B (which is TestAcct).
- AdminUser property is set to 1
- Privileged property is set to 1

So it appears that even though I am installing for just the current user
(User B), the install is using the credentials and permissions of UserA to
perform the install.  Even though it does later determine the correct paths
for UserB when copying the various files for the install.

So what I need to know is:
1) Why is this happening?
2) Is there a way to turn this off?  We don't want users to be presented
with the prompt to verify admin credentials when doing a PerUser install.
In fact a non-admin should not get the choice in the InstallScopeDlg (just
as in XP).
3) If UserA (admin) does do a PerMachine install, then installations by
later users should go to Maintenance mode directly.

Does anyone have any insight into this?

Thanks,

Andreas Mertens


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Rob Mensching-7]

(hmm, I really need to post this blog entry)

I typically write the value to a registry key and then use a RegistrySearch
to read the value back into the Property. That way on repair the value that
is on the machine will get written back to the registry (otherwise, repair
might reset the value back to its default).

On Sat, Oct 31, 2009 at 12:16 AM, little.forest <[hidden email]>wrote:

> Thanks Blair.
>
> Your code example makes sense. I'm going to try it.
>
> However, you also said "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. " - I'm not quite getting this one.
> We use major upgrade. I'm not sure this would apply. Could you tell me how
> to preserve RUNWHENWINDOWSSTART and restore it?
>
> Thanks.
>
>
>
>
> ________________________________
> From: Blair <[hidden email]>
> To: General discussion for Windows Installer XML toolset. <
> [hidden email]>
> Sent: Fri, 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.
>
> Component\@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:[hidden email]]
> Sent: Friday, October 30, 2009 2:27 PM
> To: [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>       __________________________________________________________________
> The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!
>  Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

--
virtually, Rob Mensching - http://RobMensching.com LLC
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Bob Arnson-6]

Andreas Mertens wrote:
> I choose to install for the current user (PerUser), and when the install is
> executed, it prompts me for the admin credentials of User A (admin). ???  If
> I provide these credentials, the install completes, with the file installed
> correctly for the current user.
>  

Before MSI 5.0 on Windows 7, there's no way to do both per-user and
per-machine installs from the same package without prompting for
elevation: The bit that tells MSI the package is per-user is set on the
package and can't be modified during installation. It's also entirely
possible that WixUI_Advanced doesn't handle per-user installs correctly;
I wrote it originally for the WiX installer, which is per-machine, and
never had opportunity to test a real per-user package.

> 2) Is there a way to turn this off?  We don't want users to be presented
> with the prompt to verify admin credentials when doing a PerUser install.
>  

On Vista, that requires two packages, one per-machine and one per-user.

--
sig://boB
http://joyofsetup.com/



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[little.forest]

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 <[hidden email]>
To: General discussion for Windows Installer XML toolset. <[hidden email]>
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.

Component\@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:[hidden email]]
Sent: Friday, October 30, 2009 2:27 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Blair-2]

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:[hidden email]]
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 <[hidden email]>
To: General discussion for Windows Installer XML toolset.
<[hidden email]>
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.

Component\@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:[hidden email]]
Sent: Friday, October 30, 2009 2:27 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users