Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

2013-12-05 Thread Neil Sleightholm
IIRC WiX 2.0 didn¹t do ICE validation so you probably had the warning just
didn¹t know you did.

Neil


Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0.
Seemed to be working through the compiler and linker errors one by one
just
fine until I hit ICE38 regarding shortcuts.  There are 2 shortcuts created
to the same installed EXE.  One shortcut is in the start menu and the
other
is on the desktop.  WiX 2.0 compiled MSIs install, uninstall, and major
upgrade with proper cleanup of the shortcuts just fine.  Now trying to
tackle in WiX 3.8.

 

error LGHT0204 : ICE38: Component component40 installs to user profile.
It's
Key Path registry key must fall under HKCU.

 

The message states that component40 installs to user profile.  Why does it
think that?  The directory it is within is not user specific and the
overall
MSI is ALLUSERS=1.

 

The following stackoverflow post looked promising but I'm not
understanding
it yet.
http://stackoverflow.com/questions/2058230/wix-create-non-advertised-short
cu
t-for-all-users-per-machine

 

And then another stackoverflow post
http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for
-p
er-machine-install shows a shortcut as a child of the File.  But doesn't
really address the fact that a Directory/ needs to have a
RemoveFolder/
and RegistryValue/ which is HKCU.  Other posts have noted that if HKCU
is
used then when another user uninstalls the registry entries are orphaned
under the other user and some state that when application is run as
another
user it triggers a repair.  I dunno on this.  I also couldn't find what
HKMU
was in the WiX help file or online other than Hubert Kairuki Memorial
University (something tells me that isn't relevant J ).

 

Is it possible to have an ALLUSERS msi and NOT write to user specific
registry, file, or any other user specific resource?

 

 

 

In WiX 2.0 we did the following

 

. various other wxs constructs .

 

  !-- defines the application installation directory and contents --

  Directory Id='TARGETDIR' Name='SourceDir'

 

!-- gets a reference to Desktop so we can use it later to add
shortcuts --

Directory Id='DesktopFolder'/

 

!-- defines start menu group --

Directory Id='ProgramMenuFolder' Name='Programs'

  Directory Id=ProgramMenuCSSIDir Name=CS Software

Directory Id=ProgramMenuCSSIUtilitiesDir Name=Utilities
/

Directory Id=ProgramMenuCSSIServicesDir Name=Services /

Directory Id=ProgramMenuCSSIDocsDir Name=Documents /

  /Directory

/Directory

 

!-- application install group --

Directory Id='ProgramFilesFolder'

  Directory Id='CSSIDIR' Name='CSSI'

  

?include theincludebelow.inc ?

 

  /Directory

/Directory

 

!-- System32 install group --

Directory Id=SystemFolder /

 

  /Directory

 

. various other wxs constructs .

 

 

Include

 

  Directory Id='CSWINDOWSDIR' Name='CLEARS_1' LongName='C s Windows'

. other file components including file2 .

  

Component Id=component40 DiskId=1 Guid=removed.

  Shortcut Id='startMenuCsWindowsExe' Directory='ProgramMenuCSSIDir'
Name='CSW' LongName=C s Windows WorkingDirectory='CSWINDOWSDIR'
Target=[#file2] /

/Component

Component Id=component41 DiskId=1 Guid=removed.

  Shortcut Id='desktopCsWindowsExe' Directory='DesktopFolder'
Name='CSW' LongName=C s Windows WorkingDirectory='CSWINDOWSDIR'
Target=[#file2] /

/Component

 

  /Directory

 

/Include

 

 

 

 

 

 

In WiX 3.8 we are trying the following

 

. various other wxs constructs .

 

  !-- defines the application installation directory and contents --

  Directory Id='TARGETDIR' Name='SourceDir'

 

!-- gets a reference to Desktop so we can use it later to add
shortcuts --

Directory Id='DesktopFolder'/

 

!-- defines start menu group --

Directory Id='ProgramMenuFolder' Name='Programs'

  Directory Id=ProgramMenuCSSIDir Name=CS Software

Directory Id=ProgramMenuCSSIUtilitiesDir Name=Utilities
/

Directory Id=ProgramMenuCSSIServicesDir Name=Services /

Directory Id=ProgramMenuCSSIDocsDir Name=Documents /

  /Directory

/Directory

 

!-- application install group --

Directory Id='ProgramFilesFolder'

  Directory Id='CSSIDIR' Name='CSSI'

  

?include
theequivalentincludeofthe2.0withshortcutcomponentstrippedout.inc ?

 

  /Directory

/Directory

 

!-- System32 install group --

Directory Id=SystemFolder /

 

  /Directory

 

  ?include theincludebelow.inc ?

 

. various other wxs constructs .

 

 

Include

 

  DirectoryRef Id=ProgramMenuCSSIDir

Component Id=component40 DiskId=1 Guid=removed.

  Shortcut Id='startMenuCsWindowsExe' Directory='ProgramMenuCSSIDir'

Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

2013-12-05 Thread Blair Murri
From: http://msdn.microsoft.com/library/aa371168.aspx the meaning of the 
integer in the Root column:
 
The one missing enumeration represents either Machine and User, so 
HKey-(localMachine|currentUser) or HKMU.
 
Someone else expressed it this way: HKMU stands for either HKLM or HKCU 
depeding on setup type. 
(http://www.tech-archive.net/Archive/Visio/microsoft.public.visio.developer/2006-09/msg00048.html)
 
-Blair
 
 To: wix-users@lists.sourceforge.net
 From: d...@clearskysoftware.com
 Date: Wed, 4 Dec 2013 20:30:31 -0500
 Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 -   
 shortcuts   havechanged
 
 Thanks for info on HKMU.  I'll give it a try and suppress ICE57 on the 
 compile.
 
 Is HKMU a WiX thing or did I miss a Windows installer acronym meeting?
 
 Dave Williamson
 
 
 -Original Message-
 From: Hoover, Jacob jacob.hoo...@greenheck.com
 Sent: ‎12/‎4/‎2013 8:11 PM
 To: General discussion about the WiX toolset. 
 wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 -   shortcuts   
 havechanged
 
 HKMU is either HKLM or HKCU depending on if it's a per user or per machine 
 install.
 
   Note, I have disabled ICE57, as I am using HKMU registry resources for the 
 shortcuts. Windows Installer complains 
   about per-user data and a keypath that can be per-user or per-machine.
   
   There are numerous complaints about ICE57, the biggest from Rob M himself 
 saying they neglected to take the
   ALLUSERS property into account when creating it. While I could replace HKMU 
 with HKCU and avoid the ICE57,
   it would then leave behind these registry fragments if user A did the 
 install but user B did the uninstall.
 
 
 Ref: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE57-with-HKMU-td5795201.html
 
 -Original Message-
 From: Dave Williamson [mailto:d...@clearskysoftware.com] 
 Sent: Wednesday, December 04, 2013 6:56 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have 
 changed
 
 Yes there have been. That is why we held at 2.0 and didn't make the jump. We 
 recently ran across the issue where a msi built in 2.0 installs under program 
 files(x86) on x64 machines no matter what. So rather than beat that horse we 
 are putting the time into migrating.
 
 Dave Williamson
 Clear Sky Software
 http://www.clearskysoftware.com
 Support: 704-554-6300
 Sales: 704-568-5544
 
 
 -Original Message-
 From: Christopher Painter chr...@iswix.com
 Sent: ‎12/‎4/‎2013 7:07 PM
 To: General discussion about the WiX toolset. 
 wix-users@lists.sourceforge.net; wix-users@lists.sourceforge.net 
 wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have
 changed
 
 As I recall, there were major language changes from 2.0 to 3.0 and that 
 refactoring would be expected.  3.0 - 3.8 should generally be backwards 
 compatible though.
 
 
  From: Dave Williamson, Clear Sky Software d...@clearskysoftware.com
 Sent: Wednesday, December 04, 2013 4:50 PM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed
 
 Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0.
 Seemed to be working through the compiler and linker errors one by one just 
 fine until I hit ICE38 regarding shortcuts.  There are 2 shortcuts created to 
 the same installed EXE.  One shortcut is in the start menu and the other is 
 on the desktop.  WiX 2.0 compiled MSIs install, uninstall, and major upgrade 
 with proper cleanup of the shortcuts just fine.  Now trying to tackle in WiX 
 3.8.
 
 error LGHT0204 : ICE38: Component component40 installs to user profile. 
 It's
 Key Path registry key must fall under HKCU.
 
 The message states that component40 installs to user profile.  Why does it 
 think that?  The directory it is within is not user specific and the overall 
 MSI is ALLUSERS=1.
 
 The following stackoverflow post looked promising but I'm not understanding 
 it yet.
 http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu
 
 t-for-all-users-per-machine
 
 And then another stackoverflow post
 http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p
 
 er-machine-install shows a shortcut as a child of the File.  But doesn't 
 really address the fact that a Directory/ needs to have a RemoveFolder/ 
 and RegistryValue/ which is HKCU.  Other posts have noted that if HKCU is 
 used then when another user uninstalls the registry entries are orphaned 
 under the other user and some state that when application is run as another 
 user it triggers a repair.  I dunno on this.  I also couldn't find what HKMU 
 was in the WiX help file or online other than Hubert Kairuki Memorial 
 University (something tells me that isn't relevant J ).
 
 Is it possible to have an ALLUSERS

Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

2013-12-05 Thread Dave Williamson, Clear Sky Software
We have changed the shortcuts and suppressed the ICE57.  This went well.  Now 
ICE64 is popping up for the shortcuts in question.

It appears that the Component containing the Shortcut needs to also contain a 
RemoveFolder.

RemoveFolder Id=ProgramMenuCSSIDir On=uninstall/

The RemoveFolder doc says that it removes empty folder if the parent 
component is selected for install/uninstall.  So we added a RemoveFolder to 
each component with a Shortcut.  However that leads to a light error

error LGHT0130 : The primary key 'ProgramMenuCSSIDir' is duplicated in table 
'RemoveFile'.  Please remove one of the entries or rename a part of the primary 
key to avoid the collision.

We realized that there are multiple shortcuts (each in their own component) 
that sit in the same start menu folder.  And each component is part of a 
different feature the user may or may not install.  So we individualized the 
RemoveFolder Ids and used the Directory parameter to override.

RemoveFolder Id=component2RemoveFolderProgramMenuCSSIDir 
Directory=ProgramMenuCSSIDir On=uninstall/

If Feature A  B are both installed and the user uninstalls B then the 
RemoveFolder, for the B component being removed, will see that the folder is 
not empty (I presume empty is in regards to the file system and not the 
internals of the feature) and thus will not remove the folder.  Is this a 
correct assumption on scope (file system versus feature)?


Now that the multiple RemoveFolders are in place ICE64 has been handled but 
ICE69 popped up.

warning LGHT1076 : ICE69: Mismatched component reference. Entry 
'startMenuCSWindowsExe' of the Shortcut table belongs to component 
'component40'. However, the formatted string in column 'Target' references file 
'file2' which belongs to component 'component2'. Components are in the same 
feature.

Derek always said put each thing in its own Component.  Each shortcut is in its 
own component and each file is in its own component.  ICE69 sounds in conflict 
with this.  Would it be better to suppress ICE69 or do we need to tweak the 
single-thing-per-component norm?

It felt dirty to have to separate the shortcut component into a DirectoryRef 
(can't be nested in Directory) and it not be in the same include file with the 
File it referred to.  Not sure how best to proceed on ICE69.  Any guidance is 
welcome.
 
dave williamson




-Original Message-
From: Dave Williamson [mailto:d...@clearskysoftware.com] 
Sent: Wednesday, December 04, 2013 8:31 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have 
changed

Thanks for info on HKMU.  I'll give it a try and suppress ICE57 on the compile.

Is HKMU a WiX thing or did I miss a Windows installer acronym meeting?

Dave Williamson


-Original Message-
From: Hoover, Jacob jacob.hoo...@greenheck.com
Sent: ‎12/‎4/‎2013 8:11 PM
To: General discussion about the WiX toolset. 
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts   
havechanged

HKMU is either HKLM or HKCU depending on if it's a per user or per machine 
install.

  Note, I have disabled ICE57, as I am using HKMU registry resources for the 
shortcuts. Windows Installer complains 
  about per-user data and a keypath that can be per-user or per-machine.
  
  There are numerous complaints about ICE57, the biggest from Rob M himself 
saying they neglected to take the
  ALLUSERS property into account when creating it. While I could replace HKMU 
with HKCU and avoid the ICE57,
  it would then leave behind these registry fragments if user A did the install 
but user B did the uninstall.


Ref: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE57-with-HKMU-td5795201.html

-Original Message-
From: Dave Williamson [mailto:d...@clearskysoftware.com] 
Sent: Wednesday, December 04, 2013 6:56 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have 
changed

Yes there have been. That is why we held at 2.0 and didn't make the jump. We 
recently ran across the issue where a msi built in 2.0 installs under program 
files(x86) on x64 machines no matter what. So rather than beat that horse we 
are putting the time into migrating.

Dave Williamson


-Original Message-
From: Christopher Painter chr...@iswix.com
Sent: ‎12/‎4/‎2013 7:07 PM
To: General discussion about the WiX toolset. 
wix-users@lists.sourceforge.net; wix-users@lists.sourceforge.net 
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have  
changed

As I recall, there were major language changes from 2.0 to 3.0 and that 
refactoring would be expected.  3.0 - 3.8 should generally be backwards 
compatible though.


 From: Dave Williamson, Clear Sky Software d...@clearskysoftware.com
Sent: Wednesday, December 04, 2013 4:50 PM
To: wix

Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

2013-12-05 Thread Nicolás Alvarez
I did some tests on multiple ways to handle shortcuts a few months ago:
http://sourceforge.net/mailarchive/message.php?msg_id=31481614

I didn't really get any authoritative answer on whether my findings
are correct or what option is better, though.

-- 
Nicolás
Leave it to Microsoft to make computer programming an experimental science

2013/12/4 Dave Williamson, Clear Sky Software d...@clearskysoftware.com:
 Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0.
 Seemed to be working through the compiler and linker errors one by one just
 fine until I hit ICE38 regarding shortcuts.  There are 2 shortcuts created
 to the same installed EXE.  One shortcut is in the start menu and the other
 is on the desktop.  WiX 2.0 compiled MSIs install, uninstall, and major
 upgrade with proper cleanup of the shortcuts just fine.  Now trying to
 tackle in WiX 3.8.



 error LGHT0204 : ICE38: Component component40 installs to user profile. It's
 Key Path registry key must fall under HKCU.



 The message states that component40 installs to user profile.  Why does it
 think that?  The directory it is within is not user specific and the overall
 MSI is ALLUSERS=1.



 The following stackoverflow post looked promising but I'm not understanding
 it yet.
 http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu
 t-for-all-users-per-machine



 And then another stackoverflow post
 http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p
 er-machine-install shows a shortcut as a child of the File.  But doesn't
 really address the fact that a Directory/ needs to have a RemoveFolder/
 and RegistryValue/ which is HKCU.  Other posts have noted that if HKCU is
 used then when another user uninstalls the registry entries are orphaned
 under the other user and some state that when application is run as another
 user it triggers a repair.  I dunno on this.  I also couldn't find what HKMU
 was in the WiX help file or online other than Hubert Kairuki Memorial
 University (something tells me that isn't relevant J ).



 Is it possible to have an ALLUSERS msi and NOT write to user specific
 registry, file, or any other user specific resource?







 In WiX 2.0 we did the following



 . various other wxs constructs .



   !-- defines the application installation directory and contents --

   Directory Id='TARGETDIR' Name='SourceDir'



 !-- gets a reference to Desktop so we can use it later to add
 shortcuts --

 Directory Id='DesktopFolder'/



 !-- defines start menu group --

 Directory Id='ProgramMenuFolder' Name='Programs'

   Directory Id=ProgramMenuCSSIDir Name=CS Software

 Directory Id=ProgramMenuCSSIUtilitiesDir Name=Utilities /

 Directory Id=ProgramMenuCSSIServicesDir Name=Services /

 Directory Id=ProgramMenuCSSIDocsDir Name=Documents /

   /Directory

 /Directory



 !-- application install group --

 Directory Id='ProgramFilesFolder'

   Directory Id='CSSIDIR' Name='CSSI'



 ?include theincludebelow.inc ?



   /Directory

 /Directory



 !-- System32 install group --

 Directory Id=SystemFolder /



   /Directory



 . various other wxs constructs .





 Include



   Directory Id='CSWINDOWSDIR' Name='CLEARS_1' LongName='C s Windows'

 . other file components including file2 .



 Component Id=component40 DiskId=1 Guid=removed.

   Shortcut Id='startMenuCsWindowsExe' Directory='ProgramMenuCSSIDir'
 Name='CSW' LongName=C s Windows WorkingDirectory='CSWINDOWSDIR'
 Target=[#file2] /

 /Component

 Component Id=component41 DiskId=1 Guid=removed.

   Shortcut Id='desktopCsWindowsExe' Directory='DesktopFolder'
 Name='CSW' LongName=C s Windows WorkingDirectory='CSWINDOWSDIR'
 Target=[#file2] /

 /Component



   /Directory



 /Include













 In WiX 3.8 we are trying the following



 . various other wxs constructs .



   !-- defines the application installation directory and contents --

   Directory Id='TARGETDIR' Name='SourceDir'



 !-- gets a reference to Desktop so we can use it later to add
 shortcuts --

 Directory Id='DesktopFolder'/



 !-- defines start menu group --

 Directory Id='ProgramMenuFolder' Name='Programs'

   Directory Id=ProgramMenuCSSIDir Name=CS Software

 Directory Id=ProgramMenuCSSIUtilitiesDir Name=Utilities /

 Directory Id=ProgramMenuCSSIServicesDir Name=Services /

 Directory Id=ProgramMenuCSSIDocsDir Name=Documents /

   /Directory

 /Directory



 !-- application install group --

 Directory Id='ProgramFilesFolder'

   Directory Id='CSSIDIR' Name='CSSI'



 ?include
 theequivalentincludeofthe2.0withshortcutcomponentstrippedout.inc ?



   /Directory

 /Directory



 !-- 

Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

2013-12-05 Thread Dave Williamson
Nice write up. A slight variation for your list ... We separated a 
non-advertised shortcut from the exe into its own component with reg entry and 
remove folder ... And nested that in a directoryref.

Eventually we get to an ICE69 because we too have multiple shortcuts across 
multiple features in the same start menu folder.

We suppressed ICE69 for now and will do some install, uninstall, and major 
upgrade tests to see if the expected clean behavior is observed.


Dave Williamson


-Original Message-
From: Nicolás Alvarez nicolas.alva...@gmail.com
Sent: ‎12/‎5/‎2013 6:32 PM
To: General discussion about the WiX toolset. 
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have  
changed

I did some tests on multiple ways to handle shortcuts a few months ago:
http://sourceforge.net/mailarchive/message.php?msg_id=31481614

I didn't really get any authoritative answer on whether my findings
are correct or what option is better, though.

-- 
Nicolás
Leave it to Microsoft to make computer programming an experimental science

2013/12/4 Dave Williamson, Clear Sky Software d...@clearskysoftware.com:
 Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0.
 Seemed to be working through the compiler and linker errors one by one just
 fine until I hit ICE38 regarding shortcuts.  There are 2 shortcuts created
 to the same installed EXE.  One shortcut is in the start menu and the other
 is on the desktop.  WiX 2.0 compiled MSIs install, uninstall, and major
 upgrade with proper cleanup of the shortcuts just fine.  Now trying to
 tackle in WiX 3.8.



 error LGHT0204 : ICE38: Component component40 installs to user profile. It's
 Key Path registry key must fall under HKCU.



 The message states that component40 installs to user profile.  Why does it
 think that?  The directory it is within is not user specific and the overall
 MSI is ALLUSERS=1.



 The following stackoverflow post looked promising but I'm not understanding
 it yet.
 http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu
 t-for-all-users-per-machine



 And then another stackoverflow post
 http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p
 er-machine-install shows a shortcut as a child of the File.  But doesn't
 really address the fact that a Directory/ needs to have a RemoveFolder/
 and RegistryValue/ which is HKCU.  Other posts have noted that if HKCU is
 used then when another user uninstalls the registry entries are orphaned
 under the other user and some state that when application is run as another
 user it triggers a repair.  I dunno on this.  I also couldn't find what HKMU
 was in the WiX help file or online other than Hubert Kairuki Memorial
 University (something tells me that isn't relevant J ).



 Is it possible to have an ALLUSERS msi and NOT write to user specific
 registry, file, or any other user specific resource?







 In WiX 2.0 we did the following



 . various other wxs constructs .



   !-- defines the application installation directory and contents --

   Directory Id='TARGETDIR' Name='SourceDir'



 !-- gets a reference to Desktop so we can use it later to add
 shortcuts --

 Directory Id='DesktopFolder'/



 !-- defines start menu group --

 Directory Id='ProgramMenuFolder' Name='Programs'

   Directory Id=ProgramMenuCSSIDir Name=CS Software

 Directory Id=ProgramMenuCSSIUtilitiesDir Name=Utilities /

 Directory Id=ProgramMenuCSSIServicesDir Name=Services /

 Directory Id=ProgramMenuCSSIDocsDir Name=Documents /

   /Directory

 /Directory



 !-- application install group --

 Directory Id='ProgramFilesFolder'

   Directory Id='CSSIDIR' Name='CSSI'



 ?include theincludebelow.inc ?



   /Directory

 /Directory



 !-- System32 install group --

 Directory Id=SystemFolder /



   /Directory



 . various other wxs constructs .





 Include



   Directory Id='CSWINDOWSDIR' Name='CLEARS_1' LongName='C s Windows'

 . other file components including file2 .



 Component Id=component40 DiskId=1 Guid=removed.

   Shortcut Id='startMenuCsWindowsExe' Directory='ProgramMenuCSSIDir'
 Name='CSW' LongName=C s Windows WorkingDirectory='CSWINDOWSDIR'
 Target=[#file2] /

 /Component

 Component Id=component41 DiskId=1 Guid=removed.

   Shortcut Id='desktopCsWindowsExe' Directory='DesktopFolder'
 Name='CSW' LongName=C s Windows WorkingDirectory='CSWINDOWSDIR'
 Target=[#file2] /

 /Component



   /Directory



 /Include













 In WiX 3.8 we are trying the following



 . various other wxs constructs .



   !-- defines the application installation directory and contents --

   Directory Id='TARGETDIR' Name='SourceDir'



 !-- gets a reference to Desktop so we can use it later to add

Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

2013-12-04 Thread Christopher Painter
As I recall, there were major language changes from 2.0 to 3.0 and that 
refactoring would be expected.  3.0 - 3.8 should generally be backwards 
compatible though.


 From: Dave Williamson, Clear Sky Software d...@clearskysoftware.com
Sent: Wednesday, December 04, 2013 4:50 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have 
changed

Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0.
Seemed to be working through the compiler and linker errors one by one 
just
fine until I hit ICE38 regarding shortcuts.  There are 2 shortcuts created
to the same installed EXE.  One shortcut is in the start menu and the 
other
is on the desktop.  WiX 2.0 compiled MSIs install, uninstall, and major
upgrade with proper cleanup of the shortcuts just fine.  Now trying to
tackle in WiX 3.8.

error LGHT0204 : ICE38: Component component40 installs to user profile. 
It's
Key Path registry key must fall under HKCU.

The message states that component40 installs to user profile.  Why does it
think that?  The directory it is within is not user specific and the 
overall
MSI is ALLUSERS=1.

The following stackoverflow post looked promising but I'm not 
understanding
it yet.
http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu

t-for-all-users-per-machine

And then another stackoverflow post
http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p

er-machine-install shows a shortcut as a child of the File.  But doesn't
really address the fact that a Directory/ needs to have a 
RemoveFolder/
and RegistryValue/ which is HKCU.  Other posts have noted that if HKCU 
is
used then when another user uninstalls the registry entries are orphaned
under the other user and some state that when application is run as 
another
user it triggers a repair.  I dunno on this.  I also couldn't find what 
HKMU
was in the WiX help file or online other than Hubert Kairuki Memorial
University (something tells me that isn't relevant J ).

Is it possible to have an ALLUSERS msi and NOT write to user specific
registry, file, or any other user specific resource?

In WiX 2.0 we did the following

. various other wxs constructs .

  !-- defines the application installation directory and contents --

  Directory Id='TARGETDIR' Name='SourceDir'

!-- gets a reference to Desktop so we can use it later to add
shortcuts --

Directory Id='DesktopFolder'/

!-- defines start menu group --

Directory Id='ProgramMenuFolder' Name='Programs'

  Directory Id=ProgramMenuCSSIDir Name=CS Software

Directory Id=ProgramMenuCSSIUtilitiesDir Name=Utilities 
/

Directory Id=ProgramMenuCSSIServicesDir Name=Services /

Directory Id=ProgramMenuCSSIDocsDir Name=Documents /

  /Directory

/Directory

!-- application install group --

Directory Id='ProgramFilesFolder'

  Directory Id='CSSIDIR' Name='CSSI'

?include theincludebelow.inc ?

  /Directory

/Directory

!-- System32 install group --

Directory Id=SystemFolder /

  /Directory

. various other wxs constructs .

Include

  Directory Id='CSWINDOWSDIR' Name='CLEARS_1' LongName='C s Windows'

. other file components including file2 .

Component Id=component40 DiskId=1 Guid=removed.

  Shortcut Id='startMenuCsWindowsExe' Directory='ProgramMenuCSSIDir'
Name='CSW' LongName=C s Windows WorkingDirectory='CSWINDOWSDIR'
Target=[#file2] /

/Component

Component Id=component41 DiskId=1 Guid=removed.

  Shortcut Id='desktopCsWindowsExe' Directory='DesktopFolder'
Name='CSW' LongName=C s Windows WorkingDirectory='CSWINDOWSDIR'
Target=[#file2] /

/Component

  /Directory

/Include

In WiX 3.8 we are trying the following

. various other wxs constructs .

  !-- defines the application installation directory and contents --

  Directory Id='TARGETDIR' Name='SourceDir'

!-- gets a reference to Desktop so we can use it later to add
shortcuts --

Directory Id='DesktopFolder'/

!-- defines start menu group --

Directory Id='ProgramMenuFolder' Name='Programs'

  Directory Id=ProgramMenuCSSIDir Name=CS Software

Directory Id=ProgramMenuCSSIUtilitiesDir Name=Utilities 
/

Directory Id=ProgramMenuCSSIServicesDir Name=Services /

Directory Id=ProgramMenuCSSIDocsDir Name=Documents /

  /Directory

/Directory

!-- application install group --

Directory Id='ProgramFilesFolder'

  Directory Id='CSSIDIR' Name='CSSI'

?include
theequivalentincludeofthe2.0withshortcutcomponentstrippedout.inc ?

  /Directory

/Directory

!-- System32 install group --

Directory Id=SystemFolder /

  /Directory

  ?include theincludebelow.inc ?

. various other 

Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

2013-12-04 Thread Dave Williamson
Yes there have been. That is why we held at 2.0 and didn't make the jump. We 
recently ran across the issue where a msi built in 2.0 installs under program 
files(x86) on x64 machines no matter what. So rather than beat that horse we 
are putting the time into migrating.

Dave Williamson
Clear Sky Software
http://www.clearskysoftware.com
Support: 704-554-6300
Sales: 704-568-5544


-Original Message-
From: Christopher Painter chr...@iswix.com
Sent: ‎12/‎4/‎2013 7:07 PM
To: General discussion about the WiX toolset. 
wix-users@lists.sourceforge.net; wix-users@lists.sourceforge.net 
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have  
changed

As I recall, there were major language changes from 2.0 to 3.0 and that 
refactoring would be expected.  3.0 - 3.8 should generally be backwards 
compatible though.


 From: Dave Williamson, Clear Sky Software d...@clearskysoftware.com
Sent: Wednesday, December 04, 2013 4:50 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have 
changed

Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0.
Seemed to be working through the compiler and linker errors one by one 
just
fine until I hit ICE38 regarding shortcuts.  There are 2 shortcuts created
to the same installed EXE.  One shortcut is in the start menu and the 
other
is on the desktop.  WiX 2.0 compiled MSIs install, uninstall, and major
upgrade with proper cleanup of the shortcuts just fine.  Now trying to
tackle in WiX 3.8.

error LGHT0204 : ICE38: Component component40 installs to user profile. 
It's
Key Path registry key must fall under HKCU.

The message states that component40 installs to user profile.  Why does it
think that?  The directory it is within is not user specific and the 
overall
MSI is ALLUSERS=1.

The following stackoverflow post looked promising but I'm not 
understanding
it yet.
http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu

t-for-all-users-per-machine

And then another stackoverflow post
http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p

er-machine-install shows a shortcut as a child of the File.  But doesn't
really address the fact that a Directory/ needs to have a 
RemoveFolder/
and RegistryValue/ which is HKCU.  Other posts have noted that if HKCU 
is
used then when another user uninstalls the registry entries are orphaned
under the other user and some state that when application is run as 
another
user it triggers a repair.  I dunno on this.  I also couldn't find what 
HKMU
was in the WiX help file or online other than Hubert Kairuki Memorial
University (something tells me that isn't relevant J ).

Is it possible to have an ALLUSERS msi and NOT write to user specific
registry, file, or any other user specific resource?

In WiX 2.0 we did the following

. various other wxs constructs .

  !-- defines the application installation directory and contents --

  Directory Id='TARGETDIR' Name='SourceDir'

!-- gets a reference to Desktop so we can use it later to add
shortcuts --

Directory Id='DesktopFolder'/

!-- defines start menu group --

Directory Id='ProgramMenuFolder' Name='Programs'

  Directory Id=ProgramMenuCSSIDir Name=CS Software

Directory Id=ProgramMenuCSSIUtilitiesDir Name=Utilities 
/

Directory Id=ProgramMenuCSSIServicesDir Name=Services /

Directory Id=ProgramMenuCSSIDocsDir Name=Documents /

  /Directory

/Directory

!-- application install group --

Directory Id='ProgramFilesFolder'

  Directory Id='CSSIDIR' Name='CSSI'

?include theincludebelow.inc ?

  /Directory

/Directory

!-- System32 install group --

Directory Id=SystemFolder /

  /Directory

. various other wxs constructs .

Include

  Directory Id='CSWINDOWSDIR' Name='CLEARS_1' LongName='C s Windows'

. other file components including file2 .

Component Id=component40 DiskId=1 Guid=removed.

  Shortcut Id='startMenuCsWindowsExe' Directory='ProgramMenuCSSIDir'
Name='CSW' LongName=C s Windows WorkingDirectory='CSWINDOWSDIR'
Target=[#file2] /

/Component

Component Id=component41 DiskId=1 Guid=removed.

  Shortcut Id='desktopCsWindowsExe' Directory='DesktopFolder'
Name='CSW' LongName=C s Windows WorkingDirectory='CSWINDOWSDIR'
Target=[#file2] /

/Component

  /Directory

/Include

In WiX 3.8 we are trying the following

. various other wxs constructs .

  !-- defines the application installation directory and contents --

  Directory Id='TARGETDIR' Name='SourceDir'

!-- gets a reference to Desktop so we can use it later to add
shortcuts --

Directory Id='DesktopFolder'/

!-- defines start menu group --

Directory Id='ProgramMenuFolder' Name='Programs

Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

2013-12-04 Thread Hoover, Jacob
HKMU is either HKLM or HKCU depending on if it's a per user or per machine 
install.

  Note, I have disabled ICE57, as I am using HKMU registry resources for the 
shortcuts. Windows Installer complains 
  about per-user data and a keypath that can be per-user or per-machine.
  
  There are numerous complaints about ICE57, the biggest from Rob M himself 
saying they neglected to take the
  ALLUSERS property into account when creating it. While I could replace HKMU 
with HKCU and avoid the ICE57,
  it would then leave behind these registry fragments if user A did the install 
but user B did the uninstall.


Ref: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE57-with-HKMU-td5795201.html

-Original Message-
From: Dave Williamson [mailto:d...@clearskysoftware.com] 
Sent: Wednesday, December 04, 2013 6:56 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have 
changed

Yes there have been. That is why we held at 2.0 and didn't make the jump. We 
recently ran across the issue where a msi built in 2.0 installs under program 
files(x86) on x64 machines no matter what. So rather than beat that horse we 
are putting the time into migrating.

Dave Williamson
Clear Sky Software
http://www.clearskysoftware.com
Support: 704-554-6300
Sales: 704-568-5544


-Original Message-
From: Christopher Painter chr...@iswix.com
Sent: ‎12/‎4/‎2013 7:07 PM
To: General discussion about the WiX toolset. 
wix-users@lists.sourceforge.net; wix-users@lists.sourceforge.net 
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have  
changed

As I recall, there were major language changes from 2.0 to 3.0 and that 
refactoring would be expected.  3.0 - 3.8 should generally be backwards 
compatible though.


 From: Dave Williamson, Clear Sky Software d...@clearskysoftware.com
Sent: Wednesday, December 04, 2013 4:50 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0.
Seemed to be working through the compiler and linker errors one by one just 
fine until I hit ICE38 regarding shortcuts.  There are 2 shortcuts created to 
the same installed EXE.  One shortcut is in the start menu and the other is on 
the desktop.  WiX 2.0 compiled MSIs install, uninstall, and major upgrade with 
proper cleanup of the shortcuts just fine.  Now trying to tackle in WiX 3.8.

error LGHT0204 : ICE38: Component component40 installs to user profile. 
It's
Key Path registry key must fall under HKCU.

The message states that component40 installs to user profile.  Why does it 
think that?  The directory it is within is not user specific and the overall 
MSI is ALLUSERS=1.

The following stackoverflow post looked promising but I'm not understanding it 
yet.
http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu

t-for-all-users-per-machine

And then another stackoverflow post
http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p

er-machine-install shows a shortcut as a child of the File.  But doesn't really 
address the fact that a Directory/ needs to have a RemoveFolder/ and 
RegistryValue/ which is HKCU.  Other posts have noted that if HKCU is used 
then when another user uninstalls the registry entries are orphaned under the 
other user and some state that when application is run as another user it 
triggers a repair.  I dunno on this.  I also couldn't find what HKMU was in the 
WiX help file or online other than Hubert Kairuki Memorial University 
(something tells me that isn't relevant J ).

Is it possible to have an ALLUSERS msi and NOT write to user specific registry, 
file, or any other user specific resource?

In WiX 2.0 we did the following

. various other wxs constructs .

  !-- defines the application installation directory and contents --

  Directory Id='TARGETDIR' Name='SourceDir'

!-- gets a reference to Desktop so we can use it later to add 
shortcuts --

Directory Id='DesktopFolder'/

!-- defines start menu group --

Directory Id='ProgramMenuFolder' Name='Programs'

  Directory Id=ProgramMenuCSSIDir Name=CS Software

Directory Id=ProgramMenuCSSIUtilitiesDir Name=Utilities 
/

Directory Id=ProgramMenuCSSIServicesDir Name=Services /

Directory Id=ProgramMenuCSSIDocsDir Name=Documents /

  /Directory

/Directory

!-- application install group --

Directory Id='ProgramFilesFolder'

  Directory Id='CSSIDIR' Name='CSSI'

?include theincludebelow.inc ?

  /Directory

/Directory

!-- System32 install group --

Directory Id=SystemFolder /

  /Directory

. various other wxs constructs .

Include

  Directory Id

Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

2013-12-04 Thread Dave Williamson
Thanks for info on HKMU.  I'll give it a try and suppress ICE57 on the compile.

Is HKMU a WiX thing or did I miss a Windows installer acronym meeting?

Dave Williamson


-Original Message-
From: Hoover, Jacob jacob.hoo...@greenheck.com
Sent: ‎12/‎4/‎2013 8:11 PM
To: General discussion about the WiX toolset. 
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts   
havechanged

HKMU is either HKLM or HKCU depending on if it's a per user or per machine 
install.

  Note, I have disabled ICE57, as I am using HKMU registry resources for the 
shortcuts. Windows Installer complains 
  about per-user data and a keypath that can be per-user or per-machine.
  
  There are numerous complaints about ICE57, the biggest from Rob M himself 
saying they neglected to take the
  ALLUSERS property into account when creating it. While I could replace HKMU 
with HKCU and avoid the ICE57,
  it would then leave behind these registry fragments if user A did the install 
but user B did the uninstall.


Ref: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE57-with-HKMU-td5795201.html

-Original Message-
From: Dave Williamson [mailto:d...@clearskysoftware.com] 
Sent: Wednesday, December 04, 2013 6:56 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have 
changed

Yes there have been. That is why we held at 2.0 and didn't make the jump. We 
recently ran across the issue where a msi built in 2.0 installs under program 
files(x86) on x64 machines no matter what. So rather than beat that horse we 
are putting the time into migrating.

Dave Williamson
Clear Sky Software
http://www.clearskysoftware.com
Support: 704-554-6300
Sales: 704-568-5544


-Original Message-
From: Christopher Painter chr...@iswix.com
Sent: ‎12/‎4/‎2013 7:07 PM
To: General discussion about the WiX toolset. 
wix-users@lists.sourceforge.net; wix-users@lists.sourceforge.net 
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have  
changed

As I recall, there were major language changes from 2.0 to 3.0 and that 
refactoring would be expected.  3.0 - 3.8 should generally be backwards 
compatible though.


 From: Dave Williamson, Clear Sky Software d...@clearskysoftware.com
Sent: Wednesday, December 04, 2013 4:50 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0.
Seemed to be working through the compiler and linker errors one by one just 
fine until I hit ICE38 regarding shortcuts.  There are 2 shortcuts created to 
the same installed EXE.  One shortcut is in the start menu and the other is on 
the desktop.  WiX 2.0 compiled MSIs install, uninstall, and major upgrade with 
proper cleanup of the shortcuts just fine.  Now trying to tackle in WiX 3.8.

error LGHT0204 : ICE38: Component component40 installs to user profile. 
It's
Key Path registry key must fall under HKCU.

The message states that component40 installs to user profile.  Why does it 
think that?  The directory it is within is not user specific and the overall 
MSI is ALLUSERS=1.

The following stackoverflow post looked promising but I'm not understanding it 
yet.
http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu

t-for-all-users-per-machine

And then another stackoverflow post
http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p

er-machine-install shows a shortcut as a child of the File.  But doesn't really 
address the fact that a Directory/ needs to have a RemoveFolder/ and 
RegistryValue/ which is HKCU.  Other posts have noted that if HKCU is used 
then when another user uninstalls the registry entries are orphaned under the 
other user and some state that when application is run as another user it 
triggers a repair.  I dunno on this.  I also couldn't find what HKMU was in the 
WiX help file or online other than Hubert Kairuki Memorial University 
(something tells me that isn't relevant J ).

Is it possible to have an ALLUSERS msi and NOT write to user specific registry, 
file, or any other user specific resource?

In WiX 2.0 we did the following

. various other wxs constructs .

  !-- defines the application installation directory and contents --

  Directory Id='TARGETDIR' Name='SourceDir'

!-- gets a reference to Desktop so we can use it later to add 
shortcuts --

Directory Id='DesktopFolder'/

!-- defines start menu group --

Directory Id='ProgramMenuFolder' Name='Programs'

  Directory Id=ProgramMenuCSSIDir Name=CS Software

Directory Id=ProgramMenuCSSIUtilitiesDir Name=Utilities 
/

Directory Id=ProgramMenuCSSIServicesDir Name=Services /

Directory Id