Re: [WiX-users] Condition logic

[Dave Williamson, Clear Sky Software]

Phil,

No mention of Preselected in the log.  However, I would have expected to see
Installed in the log too and it wasn't.  The MSI was run with

Msiexec /l myinstaller.msi /l*vx install.log

The statement if there any explicit action to force install of another
feature or component then the Condition table will not be used.  I'm not
understanding this.  What would be an example of an explicit action that
forces install?  We might be doing something and not even know it or the WiX
2 wxs that we started with needs some more changes in WiX 3 world.

dave williamson




-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Friday, December 13, 2013 12:24 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Condition logic

It might be an optimization of sorts - if there is no
migratefeaturestate=yes in any upgrade specification then there is no need
for that action to be scheduled anywhere.  It seemed to me that migrating
feature states seems to be the behavior you want from an upgrade based on
the scenarios you supplied. Overall, the gist of what I was trying to say
is that if there any explicit action to force install of another feature or
component then the Condition table will not be used. In other words, since
the condition logic seems correct the main reason for ignoring the
Condition table is that Preselected may be set - you could check for this
is the log.

Phil Wilson


On Thu, Dec 12, 2013 at 2:55 PM, Dave Williamson, Clear Sky Software 
d...@clearskysoftware.com wrote:

 Phil,

 Not sure if you have hit on something here.  Based on some reading on the
 MajorUpgrade element and various readings about subtopics we ran across
 something odd.  According to Orca there is no MigrateFeatureStates action
 in
 the InstallExecuteSequence table of the MSIs built in WiX 3.8.1128.0.  We
 are now wondering if the WiX 2.0.5805.0 constructs regarding upgrades,
 while
 they compile and link, don't work in 3.8.1128.0 since similar compile and
 link in WiX 2.0.5805.0 do have a MigrateFeatureStates action.

 dave williamson





 -Original Message-
 From: Dave Williamson, Clear Sky Software [mailto:
 d...@clearskysoftware.com]

 Sent: Thursday, December 12, 2013 4:11 PM
 To: 'General discussion about the WiX toolset.'
 Subject: RE: [WiX-users] Condition logic


 Ah. I see there is a MajorUpgrade element in WiX now.  That is not what
I
 meant to convey when stating major upgrade.  A new something to check
out
 though.

 In this case we are using the following:

   Property Id=NEWERPRODUCTFOUND Secure=yes /
   Property Id=PREVIOUSVERSIONSINSTALLED Secure=yes /
   Upgrade Id=GUID-HERE
 UpgradeVersion Minimum=3.0.5064 Property=NEWERPRODUCTFOUND
 OnlyDetect=yes IncludeMinimum=yes /
 UpgradeVersion Minimum=3.0.0 Maximum=3.0.5064
 Property=PREVIOUSVERSIONSINSTALLED IncludeMaximum=no /
   /Upgrade



 dave williamson




 -Original Message-
 From: Phil Wilson [mailto:phildgwil...@gmail.com]
 Sent: Thursday, December 12, 2013 11:59 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Condition logic

 It's possible that the major upgrade is migrating feature states. This
does
 not seem to explain the issue, although migrating feature states seems to
 be what you want to happen, and that wouldn't need a registry search to
 detect previously installed features. However, migrating feature states is
 one of the things that prevents the Condition table from being used. So if
 there is anything in your install that says that a component or feature
 needs to be installed then the Condition table won't be used.

 http://msdn.microsoft.com/en-us/library/aa368014(v=vs.85).aspx

 and see Preselected.

 Phil Wilson


 On Thu, Dec 12, 2013 at 5:51 AM, Dave Williamson, Clear Sky Software 
 d...@clearskysoftware.com wrote:

  Nicolás,
 
  Good point.  In all three scenarios the feature comes up selected to
  install.
 
 
  For Scenario 1 this is expected. (new install)
 
  For Scenario 2 this is unexpected. (major upgrade install where feature
  was NOT previously installed)
 
  For Scenario 3 this is expected.  (major upgrade install where feature
 was
  previously installed)
 
 
  Since the Property HAVELS2208 is null in scenario 2, I tried an
  alternative of
 
  Property Id='HAVELS2208' Value='0'
 
  And also made the Condition evaluation more explicit
 
  Condition Level='1'![CDATA[(Installed AND HAVELS2208=1) OR (NOT
  Installed)]]/Condition
 
  Still no dice.
 
 
  I'm missing the obvious.
 
 
  For scenario 2 the log file shows
 
  AppSearch: Property: HAVELS2208, Signature: registrysearchHAVELS2208
  MSI (c) (64:28) [08:43:46:321]: Note: 1: 2262 2: Signature 3:
-2147287038
  MSI (c) (64:28) [08:43:46:321]: Note: 1: 1402 2:
  HKEY_LOCAL_MACHINE\Software\ABC\DEF\LS2208 3: 2
 
 
  Using Orca the MSI clearly has a condition of
 
  LS2208Feature
  1
  (Installed AND HAVELS2208=1) OR (NOT Installed)
 
  I remain

Re: [WiX-users] Condition logic

[Dave Williamson, Clear Sky Software]

Nicolás,

Good point.  In all three scenarios the feature comes up selected to install.


For Scenario 1 this is expected. (new install)

For Scenario 2 this is unexpected. (major upgrade install where feature was NOT 
previously installed)

For Scenario 3 this is expected.  (major upgrade install where feature was 
previously installed)


Since the Property HAVELS2208 is null in scenario 2, I tried an alternative of

Property Id='HAVELS2208' Value='0'

And also made the Condition evaluation more explicit 

Condition Level='1'![CDATA[(Installed AND HAVELS2208=1) OR (NOT 
Installed)]]/Condition

Still no dice.


I'm missing the obvious.


For scenario 2 the log file shows

AppSearch: Property: HAVELS2208, Signature: registrysearchHAVELS2208
MSI (c) (64:28) [08:43:46:321]: Note: 1: 2262 2: Signature 3: -2147287038 
MSI (c) (64:28) [08:43:46:321]: Note: 1: 1402 2: 
HKEY_LOCAL_MACHINE\Software\ABC\DEF\LS2208 3: 2


Using Orca the MSI clearly has a condition of

LS2208Feature
1
(Installed AND HAVELS2208=1) OR (NOT Installed)

I remain baffled.

dave williamson




-Original Message-
From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] 
Sent: Wednesday, December 11, 2013 5:07 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Condition logic

2013/12/11 Dave Williamson, Clear Sky Software d...@clearskysoftware.com:
 My brain is twisted and can't seem to get the condition logic right.

 1.   If the Product has not been installed on the machine then the
 condition should set Level to 1.

 2.   If the Product has been installed but the HAVELS2208 registry key
 doesn't exist then the condition should NOT set Level to 1.

 3.   If the Product has been installed and the HAVELS2208 registry key
 does exist then the condition should set Level to 1.

 For some reason I can't seem to create the right logic in the condition to
 evaluate as expected for the above 3 scenarios.

 Can someone show me what I'm doing wrong?

I don't see anything obviously wrong with your code; but you only
described the expected behavior. What is the wrong actual behavior
you're seeing?

-- 
Nicolás

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Condition logic

[Dave Williamson, Clear Sky Software]

Ah. I see there is a MajorUpgrade element in WiX now.  That is not what I
meant to convey when stating major upgrade.  A new something to check out
though.

In this case we are using the following:

  Property Id=NEWERPRODUCTFOUND Secure=yes /
  Property Id=PREVIOUSVERSIONSINSTALLED Secure=yes /
  Upgrade Id=GUID-HERE
UpgradeVersion Minimum=3.0.5064 Property=NEWERPRODUCTFOUND
OnlyDetect=yes IncludeMinimum=yes /
UpgradeVersion Minimum=3.0.0 Maximum=3.0.5064
Property=PREVIOUSVERSIONSINSTALLED IncludeMaximum=no /
  /Upgrade



dave williamson




-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Thursday, December 12, 2013 11:59 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Condition logic

It's possible that the major upgrade is migrating feature states. This does
not seem to explain the issue, although migrating feature states seems to
be what you want to happen, and that wouldn't need a registry search to
detect previously installed features. However, migrating feature states is
one of the things that prevents the Condition table from being used. So if
there is anything in your install that says that a component or feature
needs to be installed then the Condition table won't be used.

http://msdn.microsoft.com/en-us/library/aa368014(v=vs.85).aspx

and see Preselected.

Phil Wilson


On Thu, Dec 12, 2013 at 5:51 AM, Dave Williamson, Clear Sky Software 
d...@clearskysoftware.com wrote:

 Nicolás,

 Good point.  In all three scenarios the feature comes up selected to
 install.


 For Scenario 1 this is expected. (new install)

 For Scenario 2 this is unexpected. (major upgrade install where feature
 was NOT previously installed)

 For Scenario 3 this is expected.  (major upgrade install where feature was
 previously installed)


 Since the Property HAVELS2208 is null in scenario 2, I tried an
 alternative of

 Property Id='HAVELS2208' Value='0'

 And also made the Condition evaluation more explicit

 Condition Level='1'![CDATA[(Installed AND HAVELS2208=1) OR (NOT
 Installed)]]/Condition

 Still no dice.


 I'm missing the obvious.


 For scenario 2 the log file shows

 AppSearch: Property: HAVELS2208, Signature: registrysearchHAVELS2208
 MSI (c) (64:28) [08:43:46:321]: Note: 1: 2262 2: Signature 3: -2147287038
 MSI (c) (64:28) [08:43:46:321]: Note: 1: 1402 2:
 HKEY_LOCAL_MACHINE\Software\ABC\DEF\LS2208 3: 2


 Using Orca the MSI clearly has a condition of

 LS2208Feature
 1
 (Installed AND HAVELS2208=1) OR (NOT Installed)

 I remain baffled.

 dave williamson




 -Original Message-
 From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
 Sent: Wednesday, December 11, 2013 5:07 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Condition logic

 2013/12/11 Dave Williamson, Clear Sky Software d...@clearskysoftware.com
 :
  My brain is twisted and can't seem to get the condition logic right.
 
  1.   If the Product has not been installed on the machine then the
  condition should set Level to 1.
 
  2.   If the Product has been installed but the HAVELS2208 registry
 key
  doesn't exist then the condition should NOT set Level to 1.
 
  3.   If the Product has been installed and the HAVELS2208 registry
 key
  does exist then the condition should set Level to 1.
 
  For some reason I can't seem to create the right logic in the condition
 to
  evaluate as expected for the above 3 scenarios.
 
  Can someone show me what I'm doing wrong?

 I don't see anything obviously wrong with your code; but you only
 described the expected behavior. What is the wrong actual behavior
 you're seeing?

 --
 Nicolás




--
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!

http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users






--
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!

http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Condition logic

[Dave Williamson, Clear Sky Software]

Phil,

Not sure if you have hit on something here.  Based on some reading on the
MajorUpgrade element and various readings about subtopics we ran across
something odd.  According to Orca there is no MigrateFeatureStates action in
the InstallExecuteSequence table of the MSIs built in WiX 3.8.1128.0.  We
are now wondering if the WiX 2.0.5805.0 constructs regarding upgrades, while
they compile and link, don't work in 3.8.1128.0 since similar compile and
link in WiX 2.0.5805.0 do have a MigrateFeatureStates action.

dave williamson





-Original Message-
From: Dave Williamson, Clear Sky Software [mailto:d...@clearskysoftware.com]

Sent: Thursday, December 12, 2013 4:11 PM
To: 'General discussion about the WiX toolset.'
Subject: RE: [WiX-users] Condition logic


Ah. I see there is a MajorUpgrade element in WiX now.  That is not what I
meant to convey when stating major upgrade.  A new something to check out
though.

In this case we are using the following:

  Property Id=NEWERPRODUCTFOUND Secure=yes /
  Property Id=PREVIOUSVERSIONSINSTALLED Secure=yes /
  Upgrade Id=GUID-HERE
UpgradeVersion Minimum=3.0.5064 Property=NEWERPRODUCTFOUND
OnlyDetect=yes IncludeMinimum=yes /
UpgradeVersion Minimum=3.0.0 Maximum=3.0.5064
Property=PREVIOUSVERSIONSINSTALLED IncludeMaximum=no /
  /Upgrade



dave williamson




-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Thursday, December 12, 2013 11:59 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Condition logic

It's possible that the major upgrade is migrating feature states. This does
not seem to explain the issue, although migrating feature states seems to
be what you want to happen, and that wouldn't need a registry search to
detect previously installed features. However, migrating feature states is
one of the things that prevents the Condition table from being used. So if
there is anything in your install that says that a component or feature
needs to be installed then the Condition table won't be used.

http://msdn.microsoft.com/en-us/library/aa368014(v=vs.85).aspx

and see Preselected.

Phil Wilson


On Thu, Dec 12, 2013 at 5:51 AM, Dave Williamson, Clear Sky Software 
d...@clearskysoftware.com wrote:

 Nicolás,

 Good point.  In all three scenarios the feature comes up selected to
 install.


 For Scenario 1 this is expected. (new install)

 For Scenario 2 this is unexpected. (major upgrade install where feature
 was NOT previously installed)

 For Scenario 3 this is expected.  (major upgrade install where feature was
 previously installed)


 Since the Property HAVELS2208 is null in scenario 2, I tried an
 alternative of

 Property Id='HAVELS2208' Value='0'

 And also made the Condition evaluation more explicit

 Condition Level='1'![CDATA[(Installed AND HAVELS2208=1) OR (NOT
 Installed)]]/Condition

 Still no dice.


 I'm missing the obvious.


 For scenario 2 the log file shows

 AppSearch: Property: HAVELS2208, Signature: registrysearchHAVELS2208
 MSI (c) (64:28) [08:43:46:321]: Note: 1: 2262 2: Signature 3: -2147287038
 MSI (c) (64:28) [08:43:46:321]: Note: 1: 1402 2:
 HKEY_LOCAL_MACHINE\Software\ABC\DEF\LS2208 3: 2


 Using Orca the MSI clearly has a condition of

 LS2208Feature
 1
 (Installed AND HAVELS2208=1) OR (NOT Installed)

 I remain baffled.

 dave williamson




 -Original Message-
 From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
 Sent: Wednesday, December 11, 2013 5:07 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Condition logic

 2013/12/11 Dave Williamson, Clear Sky Software d...@clearskysoftware.com
 :
  My brain is twisted and can't seem to get the condition logic right.
 
  1.   If the Product has not been installed on the machine then the
  condition should set Level to 1.
 
  2.   If the Product has been installed but the HAVELS2208 registry
 key
  doesn't exist then the condition should NOT set Level to 1.
 
  3.   If the Product has been installed and the HAVELS2208 registry
 key
  does exist then the condition should set Level to 1.
 
  For some reason I can't seem to create the right logic in the condition
 to
  evaluate as expected for the above 3 scenarios.
 
  Can someone show me what I'm doing wrong?

 I don't see anything obviously wrong with your code; but you only
 described the expected behavior. What is the wrong actual behavior
 you're seeing?

 --
 Nicolás




--
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!

http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users

[WiX-users] Condition logic

[Dave Williamson, Clear Sky Software]

My brain is twisted and can't seem to get the condition logic right.

 

1.   If the Product has not been installed on the machine then the
condition should set Level to 1.



2.   If the Product has been installed but the HAVELS2208 registry key
doesn't exist then the condition should NOT set Level to 1.



3.   If the Product has been installed and the HAVELS2208 registry key
does exist then the condition should set Level to 1.



For some reason I can't seem to create the right logic in the condition to
evaluate as expected for the above 3 scenarios.



Can someone show me what I'm doing wrong?

 

Include

 

  Property Id='HAVELS2208'

RegistrySearch Id=registrysearchHAVELS2208
Win64=$(var.win64Flag) Root=HKLM Key=Software\ABC\DEF\LS2208
Name=installed Type=raw/

  /Property

 

  Feature Id='LS2208Feature' Title='LS2208' Level='2'
ConfigurableDirectory='INSTALLDIR' Description='Installs the LS2208.'
AllowAdvertise='no' InstallDefault='local'

Condition Level='1'![CDATA[(Installed AND HAVELS2208) OR (NOT
Installed)]]/Condition

 

ComponentRef Id='ls2208component1' /

ComponentRef Id='ls2208component2' /

 

  /Feature

 

/Include

 

 

dave williamson

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - nice msi file size improvement

[Dave Williamson, Clear Sky Software]

Very noticeable size reduction for the same MSI built in 3.8.1128.0 compared
to 2.0.5805.0.  26 MB went to 15 MB.  Nice benefit.  Good job.

 

dave williamson

 

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[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

[WiX-users] WiX 3.8.1128.0 - default install location

[Dave Williamson, Clear Sky Software]

 

  Directory Id='TARGETDIR' Name='SourceDir'

Directory Id='ProgramFilesFolder'

  Directory Id='INSTALLDIR' Name='CSSI'

 

With the above directory structure the WixUI_FeatureTree is showing a
Location of C:\ on the feature selection dialog shown just after accepting
the license agreement.  We would expect the location to be C:\Program
Files\CSSI.

 

In WiX 3.8.1128.0 is there anything special that needs to be provided in the
wxs to help the default location directory that shows on the feature
selection UI show something other than C:\ when it is first shown?

 

Under this condition if the Browse button is used to select a directory (say
C:\Users) a message box is shown stating The folder path '?' contains an
invalid character.  Is this related?

 

 

dave williamson

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.8.1128.0 - default install location

[Dave Williamson, Clear Sky Software]

Thanks Nicolás for the extra pair of eyes.  That was it.  The 
ConfigurableDirectory was an old value.


dave williamson




-Original Message-
From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] 
Sent: Thursday, December 05, 2013 5:40 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX 3.8.1128.0 - default install location

2013/12/5 Dave Williamson, Clear Sky Software d...@clearskysoftware.com:

   Directory Id='TARGETDIR' Name='SourceDir'
 Directory Id='ProgramFilesFolder'
   Directory Id='INSTALLDIR' Name='CSSI'

 With the above directory structure the WixUI_FeatureTree is showing a
 Location of C:\ on the feature selection dialog shown just after accepting
 the license agreement.  We would expect the location to be C:\Program
 Files\CSSI.

 In WiX 3.8.1128.0 is there anything special that needs to be provided in the
 wxs to help the default location directory that shows on the feature
 selection UI show something other than C:\ when it is first shown?

Set ConfigurableDirectory=INSTALLDIR in the Feature element(s).

-- 
Nicolás

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[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

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

[Dave Williamson, Clear Sky Software]

=ProgramMenuCSSIDir On=uninstall/

  RegistryValue Root=HKLM Key=Software\CorpNameHere\CSSI\C s
Windows Name=installed Type=integer Value=1 KeyPath=yes/

/Component

Component Id=component41 DiskId=1 Guid=removed.

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

  RegistryValue Root=HKLM Key=Software\CorpNameHere\CSSI\C s
Windows Name=installed Type=integer Value=1 KeyPath=yes/

/Component

  /DirectoryRef

  

/Include

 

 

 

dave williamson

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[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

[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

Re: [WiX-users] How to remove any older installed version of the sameproduct

[Dave Williamson]

  Steps to create a new setup release:
  1.  Create a new Product Id GUID.
  2.  Increment the Product Version (this is the setup version not the app)
  3.  Create a new Package Id GUID.
  4.  In the Upgrade section increment the UpgradeVersion Minimum to the same 
as the Product Version
  for the property NEWERPRODUCTFOUND.
  5.  In the Upgrade section increment the UpgradeVersion Maximum to the same 
as the Product Version
  for the property PREVIOUSVERSIONSINSTALLED.

Make sure the ALLUSERS property is the same as the previously installed 
version. 


Dave Williamson
Clear Sky Software
704.568.5544 sales
704.554.6300 support
704.943.0585 fax
[EMAIL PROTECTED]
www.clearskysoftware.com





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Petr Vones
Sent: Friday, August 25, 2006 11:43 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to remove any older installed version of the 
sameproduct

How can I completely remove any older version of the product during 
installation of new version ? Currently I'm always getting: Another version 
of this product is already installed ... use Add/Remove ... error dialog.

I know about this article but it does not seem to resolve it:
http://www.tramontana.co.hu/wix/lesson4.php

I don't need to patch or upgrade some files but remove older version at all. 
Also it must work by clicking on the .msi file only, no additional 
command-line parameters. I've seen such .msi installations so it is possible 
for sure.

Thanks, Petr 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSComm32.ocx MSM not registering ocx

[Dave Williamson]

Thanks Bob. I did just that.

wix_2.0.3719.0
windows installer 2.00.2600.1106

I looked at the installation log and MSI thinks 
mscomm32.ocx needs to be installed and it installs it without error. So I 
did a regedit export of the registry then manually registered the mscomm32.ocx 
using regsvr32 and did a regedit export again and looked for the diffs. 
And there were some differences.

(And I did compare the Dark output of the msm to the tallow 
generated code and they were different)

The Dark output showed some interesting constructs that 
were not directly in the tallow code but seemed like they were the same thing 
but represented in a different manner.

Class Id="648A5600-2C6E-101B-82B6-0014" 
Context="InprocServer32" Description="Microsoft Communications Control, version 
6.0" Advertise="yes"ProgId Id="MSCOMMLib.MSComm.1" 
Description="Microsoft Communications Control, version 
6.0"ProgId Id="MSCOMMLib.MSComm" 
Description="Microsoft Communications Control, version 6.0" 
//ProgId/ClassClass 
Id="648A5604-2C6E-101B-82B6-0014" Context="InprocServer32" 
Description="MSComm General Property Page Object" Advertise="yes" 
/Class Id="E0DC8C80-3486-101B-82B6-0014" 
Context="InprocServer32" Description="MSComm Buffers Property Page Object" 
Advertise="yes" /Class Id="D0FC8A81-2CB2-101B-82B6-0014" 
Context="InprocServer32" Description="MSComm Hardware Property Page Object" 
Advertise="yes" /
But yet curiously enough those entries appear to be the 
missing entries in the registry (see diffs below).

I don't understand why I see the correlation that I see and 
thus am unable to determine what I need to do.



Here are the differences (MSIentry followed by after 
regsvr32 entry):
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{648A5600-2C6E-101B-82B6-0014}]

==[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{648A5600-2C6E-101B-82B6-0014}]@="Microsoft 
Communications Control, version 6.0"


[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{648A5600-2C6E-101B-82B6-0014}\InprocServer32]"ThreadingModel"="Apartment"

==[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{648A5600-2C6E-101B-82B6-0014}\InprocServer32]"ThreadingModel"="Apartment"@="C:\\WINDOWS\\system32\\mscomm32.ocx"


[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{648A5603-2C6E-101B-82B6-0014}\1.1\HELPDIR]@="C:\\WINDOWSHELP"==[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{648A5603-2C6E-101B-82B6-0014}\1.1\HELPDIR]@=""


The following keys were not created by the MSI at 
all:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{648A5600-2C6E-101B-82B6-0014}\ProgID]@="MSCOMMLib.MSComm.1"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{648A5600-2C6E-101B-82B6-0014}\VersionIndependentProgID]@="MSCOMMLib.MSComm"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{648A5604-2C6E-101B-82B6-0014}]@="MSComm 
General Property Page Object"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{648A5604-2C6E-101B-82B6-0014}\InprocServer32]@="C:\\WINDOWS\\system32\\mscomm32.ocx"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{D0FC8A81-2CB2-101B-82B6-0014}]@="MSComm 
Hardware Property Page Object"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{D0FC8A81-2CB2-101B-82B6-0014}\InprocServer32]@="C:\\WINDOWS\\system32\\mscomm32.ocx"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{E0DC8C80-3486-101B-82B6-0014}]@="MSComm 
Buffers Property Page Object"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{E0DC8C80-3486-101B-82B6-0014}\InprocServer32]@="C:\\WINDOWS\\system32\\mscomm32.ocx"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MSCOMMLib.MSComm]@="Microsoft 
Communications Control, version 6.0"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MSCOMMLib.MSComm\CLSID]@="{648A5600-2C6E-101B-82B6-0014}"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MSCOMMLib.MSComm\CurVer]@="MSCOMMLib.MSComm.1"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MSCOMMLib.MSComm.1]@="Microsoft 
Communications Control, version 6.0"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MSCOMMLib.MSComm.1\CLSID]@="{648A5600-2C6E-101B-82B6-0014}"




Dave WilliamsonClear Sky 
Software[EMAIL PROTECTED]www.clearskysoftware.com




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Bob 
ArnsonSent: Thursday, August 17, 2006 11:14 AMTo: Dave 
WilliamsonCc: wix-users@lists.sourceforge.netSubject: Re: 
[WiX-users] MSComm32.ocx MSM not registering ocx
Dave Williamson wrote: 

  
  Anyone know where 
  I should start to look to find out what is wrong when using the MSM? Or 
  is it bad to use the MS

Re: [WiX-users] MSComm32.ocx MSM not registering ocx

[Dave Williamson]

mscomm32.msm

Dave WilliamsonClear Sky 
Software[EMAIL PROTECTED]www.clearskysoftware.com




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Derek 
CiceroneSent: Thursday, August 17, 2006 5:56 PMTo: 'Dave 
Williamson'; 'Bob Arnson'Cc: 
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] MSComm32.ocx 
MSM not registering ocx


Which 
msm is causing problems (what is its exact name)?

Thanks,
Derek



From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Dave 
WilliamsonSent: Thursday, August 17, 2006 2:46 PMTo: 'Bob 
Arnson'Cc: wix-users@lists.sourceforge.netSubject: Re: 
[WiX-users] MSComm32.ocx MSM not registering 
ocx

The 
versions of the file are the same. Actually it was the same physical file 
just to be sure (I used the extracted file from the msm).

OK. 
So now I'm back to using the Tallow generated code (because it works) but I'm at 
a cross roads. Rob has said that the component's GUID is super important 
when trying to keep up with shared files installed on a machine ... in this case 
the shared file is a vb 6 ocx control. And the Tallow code does not match 
the Dark code of the msm so technically I should not use the msm component GUID 
with the tallow code because they are different ... yet what is being 
accomplished is installing a shared file, mscomm32.ocx, on the end user's 
system32 dir, registered, and reference counted ... and that does need to be 
coordinated with other folks installing that same file.

If I use 
the same GUID then the mscomm32.ocx should not be uninstalled prematurely if my 
app is uninstalled and other apps that have installed the ocx are still 
installed.

If I use 
a different GUID then the mscomm32.ocx could be uninstalled if the basic 
reference counting is out of whack.

What a 
[EMAIL PROTECTED] if you do and [EMAIL PROTECTED] if you don't situation.

Dave 
WilliamsonClear Sky Software[EMAIL PROTECTED]www.clearskysoftware.com






From: Bob Arnson 
[mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 4:48 
PMTo: Dave WilliamsonCc: 
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] MSComm32.ocx 
MSM not registering ocx
Dave Williamson wrote: 
The Dark 
output showed some interesting constructs that were not directly in the tallow 
code but seemed like they were the same thing but represented in a different 
manner.
Yes, tallow doesn't know how to use the strongly-typed 
COM-registration elements. (Heat, in WiX v3, does.) So it just turns them into 
registry values.The only other suggestion I can think of is to check the 
files in the merge module, to make sure you're using the same version. It's been 
ages since I worried about COM evils.g-- sig://boBhttp://bobs.org
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSComm32.ocx MSM not registering ocx

[Dave Williamson]

The log file was too big for email accounts so is there 
any particular part you want to see?

Here is the section that copies the 
mscomm32.ocx:

MSI (s) (B0:F4): Executing op: 
SetTargetFolder(Folder=C:\WINDOWS\System32\)MSI (s) (B0:F4): Executing op: 
SetSourceFolder(Folder=1\PFiles\FICS\Redist\MS\System\)MSI (s) (B0:F4): 
Executing op: 
FileCopy(SourceName=mscomm32.ocx,SourceCabKey=Global_Controls_MSCOMM32OCX_f0.7EBEDD1E_AA66_11D2_B980_006097C4DE24,DestName=mscomm32.ocx,Attributes=0,FileSize=103744,PerTick=32768,,VerifyMedia=1,CheckCRC=0,Version=6.0.81.69,Language=1033,InstallMode=58982400,,)MSI 
(s) (B0:F4): File: C:\WINDOWS\System32\mscomm32.ocx; To be 
installed; No patch; No existing fileMSI (s) (B0:F4): Source for 
file 'Global_Controls_MSCOMM32OCX_f0.7EBEDD1E_AA66_11D2_B980_006097C4DE24' is 
compressedInstallFiles: File: mscomm32.ocx, Directory: 
C:\WINDOWS\System32\, Size: 103744MSI (s) (B0:F4): Note: 1: 2318 2: 
C:\WINDOWS\System32\mscomm32.ocx MSI (s) (B0:F4): Note: 1: 2360 MSI (s) 
(B0:F4): Note: 1: 2360 MSI (s) (B0:F4): Note: 1: 2360 MSI (s) (B0:F4): 
Executing op: InstallProtectedFiles(AllowUI=1)MSI (s) (B0:F4): Executing op: 
ActionStart(Name=WriteRegistryValues,Description=Writing system registry 
values,Template=Key: , Name: , Value: )

Keep in mind that in this particular case the file is 
getting installed but it isn't getting registered completely because a manual 
registration after the install corrects any missing or invalid 
registration.

Dave WilliamsonClear Sky 
Software[EMAIL PROTECTED]www.clearskysoftware.com




From: Dave Williamson 
[mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 
6:23 PMTo: '[EMAIL PROTECTED]'; 'Bob Arnson'Cc: 
'wix-users@lists.sourceforge.net'Subject: RE: [WiX-users] 
MSComm32.ocx MSM not registering ocx

Yes the file gets installed. I was using a fresh 
install of windows XP in virtual pc so the file does not exist at all to begin 
with. And yes I have a verbose log (it is attached).

Dave WilliamsonClear Sky 
Software[EMAIL PROTECTED]www.clearskysoftware.com




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Derek 
CiceroneSent: Thursday, August 17, 2006 6:14 PMTo: 'Dave 
Williamson'; 'Bob Arnson'Cc: 
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] MSComm32.ocx 
MSM not registering ocx


When 
you use the merge module, do you see the mscomm32.ocx file get installed? 
Do you have a verbose installation log? Those are really useful for 
tracking down issues.

Derek



From: 
Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, 
August 17, 2006 3:00 PMTo: [EMAIL PROTECTED]; 'Bob 
Arnson'Cc: wix-users@lists.sourceforge.netSubject: RE: 
[WiX-users] MSComm32.ocx MSM not registering 
ocx

mscomm32.msm


Dave 
WilliamsonClear Sky Software[EMAIL PROTECTED]www.clearskysoftware.com






From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Derek 
CiceroneSent: Thursday, August 17, 2006 5:56 PMTo: 'Dave 
Williamson'; 'Bob Arnson'Cc: 
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] MSComm32.ocx 
MSM not registering ocx
Which 
msm is causing problems (what is its exact name)?

Thanks,
Derek



From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Dave 
WilliamsonSent: Thursday, August 17, 2006 2:46 PMTo: 'Bob 
Arnson'Cc: wix-users@lists.sourceforge.netSubject: Re: 
[WiX-users] MSComm32.ocx MSM not registering 
ocx

The 
versions of the file are the same. Actually it was the same physical file 
just to be sure (I used the extracted file from the msm).

OK. 
So now I'm back to using the Tallow generated code (because it works) but I'm at 
a cross roads. Rob has said that the component's GUID is super important 
when trying to keep up with shared files installed on a machine ... in this case 
the shared file is a vb 6 ocx control. And the Tallow code does not match 
the Dark code of the msm so technically I should not use the msm component GUID 
with the tallow code because they are different ... yet what is being 
accomplished is installing a shared file, mscomm32.ocx, on the end user's 
system32 dir, registered, and reference counted ... and that does need to be 
coordinated with other folks installing that same file.

If I use 
the same GUID then the mscomm32.ocx should not be uninstalled prematurely if my 
app is uninstalled and other apps that have installed the ocx are still 
installed.

If I use 
a different GUID then the mscomm32.ocx could be uninstalled if the basic 
reference counting is out of whack.

What a 
[EMAIL PROTECTED] if you do and [EMAIL PROTECTED] if you don't situation.

Dave 
WilliamsonClear Sky Software[EMAIL PROTECTED]www.clearskysoftware.com






From: Bob Arnson 
[mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 4:48 
PMTo: Dave WilliamsonCc: 
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] MSComm32.ocx 
MSM not registering ocx
Dave Williamson wrote: 
The Dark 
output showed some interesting constructs that were not directly in the tallow 
code

Re: [WiX-users] MSComm32.ocx MSM not registering ocx

[Dave Williamson]

Yep. Did that earlier. See earlier post to 
thread. I don't think the problem is a Wix problem. And I don't 
think it is going to get solved anytime soon because it is a 3rd party 
msm. So what I need to do is author something with Wix that tries to 
accomplish my goals without screwing up everyone else who might depend on this 
shared component. What would you do ... use the same GUID as the msm (and 
hope that the root of the problem is getting to the end point and not the end 
point) in the hopes that when the true problem is discovered the end install 
result will be the same  or be true to the fact that the tallowed version of 
the component is not the same and use a new GUID?

Dave WilliamsonClear Sky 
Software[EMAIL PROTECTED]www.clearskysoftware.com




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Derek 
CiceroneSent: Thursday, August 17, 2006 7:01 PMTo: 'Dave 
Williamson'; 'Bob Arnson'Cc: 
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] MSComm32.ocx 
MSM not registering ocx


Weird 
 I did a comparison of the registry values in the self-registration and those 
in the merge module but they seem to be very similar. Im not sure whats 
going on there  sorry. The only thing I can think of would be to export 
your HKCR hive in the broken state, then run the self-reg, then export it again 
to see what changed. That might provide some clues.

Derek



From: 
Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, 
August 17, 2006 3:43 PMTo: [EMAIL PROTECTED]; 'Bob 
Arnson'Cc: wix-users@lists.sourceforge.netSubject: RE: 
[WiX-users] MSComm32.ocx MSM not registering 
ocx

The log 
file was too big for email accounts so is there any particular part you want to 
see?

Here is 
the section that copies the mscomm32.ocx:

MSI (s) 
(B0:F4): Executing op: SetTargetFolder(Folder=C:\WINDOWS\System32\)MSI (s) 
(B0:F4): Executing op: 
SetSourceFolder(Folder=1\PFiles\FICS\Redist\MS\System\)MSI (s) (B0:F4): 
Executing op: 
FileCopy(SourceName=mscomm32.ocx,SourceCabKey=Global_Controls_MSCOMM32OCX_f0.7EBEDD1E_AA66_11D2_B980_006097C4DE24,DestName=mscomm32.ocx,Attributes=0,FileSize=103744,PerTick=32768,,VerifyMedia=1,CheckCRC=0,Version=6.0.81.69,Language=1033,InstallMode=58982400,,)MSI 
(s) (B0:F4): File: C:\WINDOWS\System32\mscomm32.ocx; To be 
installed; No patch; No existing fileMSI (s) (B0:F4): Source for 
file 'Global_Controls_MSCOMM32OCX_f0.7EBEDD1E_AA66_11D2_B980_006097C4DE24' is 
compressedInstallFiles: File: mscomm32.ocx, Directory: 
C:\WINDOWS\System32\, Size: 103744MSI (s) (B0:F4): Note: 1: 2318 2: 
C:\WINDOWS\System32\mscomm32.ocx MSI (s) (B0:F4): Note: 1: 2360 MSI (s) 
(B0:F4): Note: 1: 2360 MSI (s) (B0:F4): Note: 1: 2360 MSI (s) (B0:F4): 
Executing op: InstallProtectedFiles(AllowUI=1)MSI (s) (B0:F4): Executing op: 
ActionStart(Name=WriteRegistryValues,Description=Writing system registry 
values,Template=Key: , Name: , Value: )

Keep in 
mind that in this particular case the file is getting installed but it isn't 
getting registered completely because a manual registration after the install 
corrects any missing or invalid registration.


Dave 
WilliamsonClear Sky Software[EMAIL PROTECTED]www.clearskysoftware.com






From: 
Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, 
August 17, 2006 6:23 PMTo: '[EMAIL PROTECTED]'; 'Bob 
Arnson'Cc: 'wix-users@lists.sourceforge.net'Subject: RE: 
[WiX-users] MSComm32.ocx MSM not registering ocx
Yes the 
file gets installed. I was using a fresh install of windows XP in virtual 
pc so the file does not exist at all to begin with. And yes I have a 
verbose log (it is attached).


Dave 
WilliamsonClear Sky Software[EMAIL PROTECTED]www.clearskysoftware.com






From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Derek 
CiceroneSent: Thursday, August 17, 2006 6:14 PMTo: 'Dave 
Williamson'; 'Bob Arnson'Cc: 
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] MSComm32.ocx 
MSM not registering ocx
When 
you use the merge module, do you see the mscomm32.ocx file get installed? 
Do you have a verbose installation log? Those are really useful for 
tracking down issues.

Derek



From: 
Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Thursday, 
August 17, 2006 3:00 PMTo: [EMAIL PROTECTED]; 'Bob 
Arnson'Cc: wix-users@lists.sourceforge.netSubject: RE: 
[WiX-users] MSComm32.ocx MSM not registering 
ocx

mscomm32.msm


Dave 
WilliamsonClear Sky Software[EMAIL PROTECTED]www.clearskysoftware.com






From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Derek 
CiceroneSent: Thursday, August 17, 2006 5:56 PMTo: 'Dave 
Williamson'; 'Bob Arnson'Cc: 
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] MSComm32.ocx 
MSM not registering ocx
Which 
msm is causing problems (what is its exact name)?

Thanks,
Derek



From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Dave 
WilliamsonSent: Thursday, August 17, 2006 2:46 PMTo: 'Bob 
Arnson'Cc: wix-users@lists.sourceforge.netSubject: Re: 
[WiX-users

[WiX-users] MSComm32.ocx MSM not registering ocx

[Dave Williamson]

When using the VB6 
merge modules from Microsoft's download site (specifically the mscomm32.msm) I 
am finding that the mscomm32.ocx has to be manually registered (using regsvr32) 
or else the .NET 2003 application that is trying to call it gets a "Class not 
registered" error.

Prior to including 
this MSM I hadplaced Tallow generated code in my wix code because I did 
not know the MSMs existed. Wheninstallingusingthe tallow 
generated code all was well.

Anyone know where I 
should start to look to find out what is wrong when using the MSM? Or is 
it bad to use the MSM?

Should I pull the 
component GUID out of the MSM and then use that GUID with the tallow generated 
code?

Dave WilliamsonClear Sky 
Software[EMAIL PROTECTED]www.clearskysoftware.com


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Request for Advice regarding File Organisation

[Dave Williamson]

Bob,

Thanks a bunch.  I altered the test scenario to test what you said and 
reference counting did work as I had originally thought it
did.  I was unaware that the mechanism had changed along the way (whether that 
be since MSI infant or sometime as MSI evolved).

Thanks for the input as this further clarified (for me at least) when each type 
of reference counting should be used.

Dave Williamson
Clear Sky Software
704.568.5544 sales
704.554.6300 support
704.943.0585 fax
[EMAIL PROTECTED]
www.clearskysoftware.com





-Original Message-
From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 10, 2006 2:29 AM
To: Dave Williamson
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Eric Fesh'; 
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Request for Advice regarding File Organisation

Dave Williamson wrote:
 Makes sense.  My thoughts were more down the lines of using 3rd party files 
 and needing to make sure those dependencies are
 installed ... things like mscomm32.ocx being installed in the 
 windows\system32 directory ... up to now I never knew that reference
 counting wasn't at a higher level than each install ... I had assumed that 
 reference counting occurred at a more global level.
   
You can use Component/@SharedDllRefCount to tell MSI to also track the 
component using the pre-MSI DLL ref-counting mechanism in the registry. 
It's not ideal, as it's easy for the ref count to get out of date.

-- 
sig://boB
http://bobs.org



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Transition VS.NET 2003 installer base to WiX 2 installer

[Dave Williamson]

I thought I would 
find this answer in the archives but did not.

What is the best way 
to move an existing application that is deployed in the field via VS.NET 2003 
installer project to a WiX based deployment?

Major upgrade is a 
given but what has to be authored on the Wix side to get it to upgrade an 
install that was built by something totally different (my assumption is that 
using the same upgradecode as is in the VS.NET 2003 installer isn't the answer 
and that the answer may be somewhat complicated).

Some info about the 
VS.NET 2003 installer:
1. It was 
built using the VS.NET 2003 setup project (no special other stuff outside what 
VS.NET IDE supports).
2. It has 
merge modules within the setup project that were also built in 
VS.NET.


Dave WilliamsonClear Sky 
Software704.568.5544 sales704.554.6300 support704.943.0585 fax[EMAIL PROTECTED]www.clearskysoftware.com


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Request for Advice regarding File Organisation

[Dave Williamson]

If you change the GUID for the components then they are totally different 
components regardless of their contents ... so yes
upgrading in the future would be limited to a major upgrade only i believe. 


Dave Williamson
Clear Sky Software
704.568.5544 sales
704.554.6300 support
704.943.0585 fax
[EMAIL PROTECTED]
www.clearskysoftware.com





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fesh
Sent: Wednesday, August 09, 2006 12:44 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Request for Advice regarding File Organisation

Hello all:

I'm wondering if there are reasons why I should not be setting up and 
organizing 
my WiX projects the way I currently am. I have an nmake file that runs tallow 
across the files that I want to install. The .xml file that is produced then 
gets processed by two perl scripts. The first (twiddle.pl) fills in GUIDS for 
all of the files and renames the components and outputs to a .wxs. The second 
(twaddle.pl) generates features from the the .xml file and outputs to a second 
.wxs. Finally, the contents of the two .wxs files are referenced in a main .wxs 
file that sort of controls everything else.

The reason I ask is that two build runs will result in different GUIDS for all 
of the files in the project. Is this a bad thing if I want to provide upgrades 
later on? I don't save the .wxs files in my source repository because I see 
them 
as intermediate steps...

-- 
--

Eric Fesh
Customer Support Engineer/Software Test Engineer
Verari Systems Software, Inc.
110 12th Street North, Suite D103
Birmingham, AL 35203
Phone +1-205-397-3141 ext. 3149
Fax +1-205-397-3142
[EMAIL PROTECTED]
http://www.verarisoft.com/

The information contained in this communication may be confidential and is
intended only for the use of the recipient(s) named above.  If the reader of
this communication is not the intended recipient(s), you are hereby notified
that any dissemination, distribution, or copying of this communication, or
any of its contents, is strictly prohibited.  If you are not a named
recipient or received this communication by mistake, please notify the sender
and delete the communication and all copies of it.

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Request for Advice regarding File Organisation

[Dave Williamson]

Ok.  I read the blog(s).

If 2 unrelated installs install the same shared file (say comctl32.ocx) both 
the installs need to use the same GUID for the
component that contains the comctl32.ocx file so that reference counting isn't 
thrown askew?

And if that is the case then the comctl32.ocx author's merge module must be 
used by all parties so they keep the same GUID.

WOW.  That means any installation that I put together must use merge modules 
from the shared file authors.  And in my little bit of
experience in creating installers I have found that the merge modules have 
quirks and bugs that I can't wait on them to fix and must
create my own merge module that installs the shared file.

Correct me if I'm wrong (and please be wrong) ... because if I'm not then this 
isn't so much a technical decision as much a business
decision ... the decision being do we use technology on which our productivity 
depends on the productivity of a 3rd party.


Dave Williamson
Clear Sky Software
704.568.5544 sales
704.554.6300 support
704.943.0585 fax
[EMAIL PROTECTED]
www.clearskysoftware.com





-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 09, 2006 1:10 PM
To: 'Dave Williamson'; 'Eric Fesh'; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Request for Advice regarding File Organisation
Importance: Low

PS: It is for all these reasons that tallow does not generate GUIDs for you
today.  It is very, very difficult to do correctly in all cases.  You may be
able to create specialized solutions targeted for your needs... but a
solution that works for everyone every time is a lot more involved (and, I
believe, requires storing data in ways that are rather unnatural in a build
environment).

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Wednesday, August 09, 2006 10:03 AM
To: 'Dave Williamson'; 'Eric Fesh'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Request for Advice regarding File Organisation

It can be worse than that.  If any of those Files are shared across
different Products that can be installed on the user's machine, you can get
into scenarios where the Files are incorrectly reference counted.  I tried
to capture much of the trickiness here:
http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx




-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Request for Advice regarding File Organisation

[Dave Williamson]

I just setup a test scenario proving to myself what Rob was saying and now my 
mind is completely blown.  A file will be deleted from
disk and registration information orphaned when that file is installed by 2 
different installers (in the same directory) using 2
different component GUIDs.

I'll be at the funny farm for a bit.  Sorry for the confusion Eric.

Dave Williamson
Clear Sky Software
704.568.5544 sales
704.554.6300 support
704.943.0585 fax
[EMAIL PROTECTED]
www.clearskysoftware.com





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Williamson
Sent: Wednesday, August 09, 2006 1:38 PM
To: [EMAIL PROTECTED]; 'Eric Fesh'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Request for Advice regarding File Organisation

Ok.  I read the blog(s).

If 2 unrelated installs install the same shared file (say comctl32.ocx) both 
the installs need to use the same GUID for the
component that contains the comctl32.ocx file so that reference counting isn't 
thrown askew?

And if that is the case then the comctl32.ocx author's merge module must be 
used by all parties so they keep the same GUID.

WOW.  That means any installation that I put together must use merge modules 
from the shared file authors.  And in my little bit of
experience in creating installers I have found that the merge modules have 
quirks and bugs that I can't wait on them to fix and must
create my own merge module that installs the shared file.

Correct me if I'm wrong (and please be wrong) ... because if I'm not then this 
isn't so much a technical decision as much a business
decision ... the decision being do we use technology on which our productivity 
depends on the productivity of a 3rd party.


Dave Williamson
Clear Sky Software
704.568.5544 sales
704.554.6300 support
704.943.0585 fax
[EMAIL PROTECTED]
www.clearskysoftware.com





-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 09, 2006 1:10 PM
To: 'Dave Williamson'; 'Eric Fesh'; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Request for Advice regarding File Organisation
Importance: Low

PS: It is for all these reasons that tallow does not generate GUIDs for you
today.  It is very, very difficult to do correctly in all cases.  You may be
able to create specialized solutions targeted for your needs... but a
solution that works for everyone every time is a lot more involved (and, I
believe, requires storing data in ways that are rather unnatural in a build
environment).

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Wednesday, August 09, 2006 10:03 AM
To: 'Dave Williamson'; 'Eric Fesh'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Request for Advice regarding File Organisation

It can be worse than that.  If any of those Files are shared across
different Products that can be installed on the user's machine, you can get
into scenarios where the Files are incorrectly reference counted.  I tried
to capture much of the trickiness here:
http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx




-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Request for Advice regarding File Organisation

[Dave Williamson]

Makes sense.  My thoughts were more down the lines of using 3rd party files and 
needing to make sure those dependencies are
installed ... things like mscomm32.ocx being installed in the windows\system32 
directory ... up to now I never knew that reference
counting wasn't at a higher level than each install ... I had assumed that 
reference counting occurred at a more global level.


Dave Williamson
Clear Sky Software
704.568.5544 sales
704.554.6300 support
704.943.0585 fax
[EMAIL PROTECTED]
www.clearskysoftware.com





-Original Message-
From: Derek Cicerone [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 09, 2006 3:24 PM
To: 'Dave Williamson'; [EMAIL PROTECTED]; 'Eric Fesh'; 
wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Request for Advice regarding File Organisation

That is why we encourage everyone to be very careful with component guids
and when possible install to private locations.

If you have several products which share some common files, you don't need
merge modules to achieve that.  Just ensure that you author those common
components once and share the resulting wixobj/wixlib files amongst all the
products during linking.

Derek

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave
Williamson
Sent: Wednesday, August 09, 2006 12:14 PM
To: 'Dave Williamson'; [EMAIL PROTECTED]; 'Eric Fesh';
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Request for Advice regarding File Organisation

I just setup a test scenario proving to myself what Rob was saying and now
my mind is completely blown.  A file will be deleted from disk and
registration information orphaned when that file is installed by 2 different
installers (in the same directory) using 2 different component GUIDs.

I'll be at the funny farm for a bit.  Sorry for the confusion Eric.

Dave Williamson
Clear Sky Software
704.568.5544 sales
704.554.6300 support
704.943.0585 fax
[EMAIL PROTECTED]
www.clearskysoftware.com





-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave
Williamson
Sent: Wednesday, August 09, 2006 1:38 PM
To: [EMAIL PROTECTED]; 'Eric Fesh';
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Request for Advice regarding File Organisation

Ok.  I read the blog(s).

If 2 unrelated installs install the same shared file (say comctl32.ocx) both
the installs need to use the same GUID for the component that contains the
comctl32.ocx file so that reference counting isn't thrown askew?

And if that is the case then the comctl32.ocx author's merge module must be
used by all parties so they keep the same GUID.

WOW.  That means any installation that I put together must use merge modules
from the shared file authors.  And in my little bit of experience in
creating installers I have found that the merge modules have quirks and bugs
that I can't wait on them to fix and must create my own merge module that
installs the shared file.

Correct me if I'm wrong (and please be wrong) ... because if I'm not then
this isn't so much a technical decision as much a business decision ... the
decision being do we use technology on which our productivity depends on the
productivity of a 3rd party.



Dave Williamson
Clear Sky Software
704.568.5544 sales
704.554.6300 support
704.943.0585 fax
[EMAIL PROTECTED]
www.clearskysoftware.com





-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 09, 2006 1:10 PM
To: 'Dave Williamson'; 'Eric Fesh'; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Request for Advice regarding File Organisation
Importance: Low

PS: It is for all these reasons that tallow does not generate GUIDs for you
today.  It is very, very difficult to do correctly in all cases.  You may be
able to create specialized solutions targeted for your needs... but a
solution that works for everyone every time is a lot more involved (and, I
believe, requires storing data in ways that are rather unnatural in a build
environment).

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Wednesday, August 09, 2006 10:03 AM
To: 'Dave Williamson'; 'Eric Fesh'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Request for Advice regarding File Organisation

It can be worse than that.  If any of those Files are shared across
different Products that can be installed on the user's machine, you can get
into scenarios where the Files are incorrectly reference counted.  I tried
to capture much of the trickiness here:
http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx




-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid

Re: [WiX-users] Shortcuts orphaned when changed out from under File

[Dave Williamson]

Tony,

That was the trick.  The GUIDs were not changed. 


Dave Williamson
Clear Sky Software
704.568.5544 sales
704.554.6300 support
704.943.0585 fax
[EMAIL PROTECTED]
www.clearskysoftware.com





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Hoyle
Sent: Friday, August 04, 2006 5:09 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Shortcuts orphaned when changed out from under File

Derek Cicerone wrote:
 Non-advertised shortcuts require dummy HKCU keypaths in their components 
 - do you have those?  (This is one of many mistakes ICE validation catches)
 
The OP is using ALLUSERS=1 so that would make the problem worse, not 
better (modifying HKCU in ALLUSERS would mean that the only the admin 
that installed it could uninstall it...)

It's probably not changing the component GUIDs - you have to change them 
when you change a component (and probably force a major upgrade so the 
old ones are uninstalled just to be safe) otherwise it thinks that 
nothing has changed and doesn't install the new ones.

Tony

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Shortcuts orphaned when changed out from under File

[Dave Williamson]

Based on an earlier 
email reply(8/1/2006 subject=Shortcuts) from Derek. In this reply 
Derek suggested that shortcuts should not always be definedunder the 
File but independently because shortcuts and ALLUSERS don't always 
coexist in a manner that makes sense.

Some relevant facts 
on the *.wxs:
Wix being used = v2 
(wix_2.0.3719.0)
Install sets 
ALLUSERS property to 1.
Product ID and 
Package ID are changed with each release.
and
 
InstallExecuteSequence 
RemoveExistingProducts After='InstallFinalize' 
/ 
/InstallExecuteSequence
So I took all my 
shortcuts out from within the File elements and placed them within their 
own component elements. When this new MSI is run on a workstation that has 
any previous install on it the old shortcuts (desktop and startmenu) are left on 
the machine along side the new shortcuts.

Why were the old 
shortcuts not removed?

Dave WilliamsonClear Sky 
Software704.568.5544 sales704.554.6300 support704.943.0585 fax[EMAIL PROTECTED]www.clearskysoftware.com


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Shortcuts orphaned when changed out from under File

[Dave Williamson]

non-advertised shortcuts

Have not delved into ICE validation yet ... see a 
little too much bantering back and forth about what is "passing ICE 
validation". I'm too much of a newbie yet.

Dave WilliamsonClear Sky 
Software704.568.5544 sales704.554.6300 support704.943.0585 fax[EMAIL PROTECTED]www.clearskysoftware.com




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Derek 
CiceroneSent: Friday, August 04, 2006 4:38 PMTo: 'Dave 
Williamson'; wix-users@lists.sourceforge.netSubject: Re: [WiX-users] 
Shortcuts orphaned when changed out from under File


Are you using 
advertised or non-advertised shortcuts? Did your MSI pass ICE 
validation?





From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Dave WilliamsonSent: Friday, August 04, 2006 1:20 
PMTo: 
wix-users@lists.sourceforge.netSubject: [WiX-users] Shortcuts orphaned 
when changed out from under File


Based on an earlier email 
reply(8/1/2006 subject=Shortcuts) from Derek. In this reply Derek 
suggested that shortcuts should not always be definedunder the 
File but independently because shortcuts and ALLUSERS don't always 
coexist in a manner that makes sense.



Some relevant facts on the 
*.wxs:

Wix being used = v2 
(wix_2.0.3719.0)

Install sets ALLUSERS property to 
1.

Product ID and Package ID are 
changed with each release.

and

 
InstallExecuteSequence 
RemoveExistingProducts After='InstallFinalize' 
/ 
/InstallExecuteSequence

So I took all my shortcuts out from 
within the File elements and placed them within their own component 
elements. When this new MSI is run on a workstation that has any previous 
install on it the old shortcuts (desktop and startmenu) are left on the machine 
along side the new shortcuts.



Why were the old shortcuts not 
removed?


Dave WilliamsonClear Sky 
Software704.568.5544 sales704.554.6300 support704.943.0585 fax[EMAIL PROTECTED]www.clearskysoftware.com


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] rfc: Package element changes

[Dave Williamson]

I assume that ----? makes up a totally new 
GUID.

I assume that -1234---? makes 
up all the GUID parts except for 1234.

I assume that 12345678----??5?? makes 
up all the GUID parts except for 12345678 and 5.

If my assumptions are not correct then a "?" does not 
follow the standard of a digit wildcard and thus * would make more sense to 
me.

If my assumptions are correct then that is way too cool and 
I would love to also have the * so it would be meaningful the day that the GUID 
format changes. :)

Dave WilliamsonClear Sky 
Software704.568.5544 sales704.554.6300 support704.943.0585 fax[EMAIL PROTECTED]www.clearskysoftware.com




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Derek 
CiceroneSent: Tuesday, August 01, 2006 2:10 PMTo: 
[EMAIL PROTECTED]; 'Bob Arnson'; 
[EMAIL PROTECTED]Cc: 
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] rfc: Package 
element changes


Just a note: the 
Product/@Id should almost never be auto-generated because that forces major 
upgrades every time. But why would * be better than 
----??

Thanks,
Derek





From: Rob Mensching [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 01, 2006 8:37 
AMTo: 'Bob Arnson'; 
[EMAIL PROTECTED]Cc: 
wix-users@lists.sourceforge.netSubject: RE: [WiX-users] rfc: Package 
element changes

I have no opinion on 
that. Anybody else care?




From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Bob ArnsonSent: Monday, July 31, 2006 3:39 
PMTo: 
[EMAIL PROTECTED]Cc: wix-users@lists.sourceforge.net; 
[EMAIL PROTECTED]Subject: Re: [WiX-users] rfc: Package 
element changes

Derek Cicerone wrote: 
That is an excellent 
point  what if we keep the ???... syntax just for Product/@Id in that case and 
go with the recommendations below for everything 
else?
Any chance of a different 
syntax? @Id="*" maybe, keeping with the wildcard 
scheme?-- sig://boBhttp://bobs.org
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files

[Dave Williamson]

If there are utilities to bring a pure WiX 2 code base 
up to a pure WiX 3 code base then breaking compatibility is fine by me. We 
do not intend to mix the two. The utilities would eliminate costly manual 
conversion time and provide a quick way for the entire WiX 2 code library to be 
converted. So we could keep our existing WiX 2 library (just in case :)) 
then put upa parallel WiX 3 library and just make the switch wholesale and 
if WiX 3 floats in production then the WiX 2 library can be deprecated ... Note 
however we won't address the switch to WiX 3 until it becomes production 
ready. So on that note ... to help encourage the use of (and thus bug 
fixing of) WiX 3 to get it ready for production the conversion utilities need to 
convert from WiX 2 to WiX 3 and (to save our butts if WiX 3 doesn't get it done) 
convert from WiX 3 to WiX 2.

You will need to weigh the cost of conversion versus 
backwards compatibility ... I'm clueless on just how would you automate a 
conversion.

Dave WilliamsonClear Sky 
Software704.568.5544 sales704.554.6300 support704.943.0585 fax[EMAIL PROTECTED]www.clearskysoftware.com




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Derek 
CiceroneSent: Wednesday, July 26, 2006 6:50 PMTo: 
wix-users@lists.sourceforge.netSubject: [WiX-users] rfc: break WiX 
3.0 backwards-compatibility with WiX 2.0library (wixlib) 
files


WiX 3.0 currently has the ability to 
read library (.wixlib) files generated by the WiX 2.0 version of the 
toolset. However, weve recently identified several reasons why wed like 
to stop maintaining backwards-compatibility with the 2.0 format. The 
overall goal here is to make the changes necessary so that we never need to 
touch the wixobj or wixlib file formats ever again. All the proposed 
changes should make the contents of the wixobj and wixlib files so generic that 
all future improvements can be made by merely working with the existing concept 
of unreal tables instead of special 1-off xml and unreal 
columns.

Drawbacks
The one obvious drawback of this 
change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs 
from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be 
converted to the 3.0 format (or re-built in 3.0) to work. For most groups, 
we anticipate that this will not be a problem since the move to 3.0 should only 
be done for a new product release and mixing versions of WiX in your build 
process is currently not advisable (its not a scenario we test very 
often). From 3.0 onward, however, we should be able to keep a consistent 
file format for wixobj/wixlib/wixout files.

Advantages
1. Remove unreal 
columns from real tables
Currently WiX internally uses a 
concept of unreal columns to associate additional information with standard MSI 
tables. For example, to associate a file path with a File row, WiX has a 
special Source column in the File table which is considered an unreal 
column. This basically means that wixobj and wixlib files carry the 
column but the final MSI file does not.

The big danger with using this 
method of persisting additional information about standard tables is that should 
the MSI team ever decide to add additional columns to the tables, WiX will need 
to add hacks to ignore its unreal columns since all columns are addressed by 
their index (not the name of the column). In order to prepare for the 
possibility of the MSI team adding new columns to existing standard tables, wed 
like to remove the unreal column concept. This doesnt mean that metadata 
can no longer be associated with standard tables  it just means it needs to be 
stored in a separate table like a WixFile table with a foreign key matching a 
File table entry.

2. Prefix 
wix-specific unreal tables with Wix
There are currently several 
WiX-specific tables used between candle and light which do not actually appear 
in any MSI files. However, these tables do reside in the same namespace as 
normal tables that will be put in the MSI file. Some of these tables 
include:
- FeatureGroup  supports 
ComponentGroup authoring concepts
- ComponentGroup  support 
ComponentGroup authoring concept
- Merge  supports merge 
modules
- Actions  supports scheduling for 
standard and custom actions
- SuppressAction  supports 
suppression of actions
- CustomTables  supports custom 
tables without needing an extension
- EnsureTables  supports ensuring a 
table exists in an MSI file
- RowData  contains row information 
for CustomTables
- UI  supports UI 
elements
The danger is that should MSI or any 
other group decide to use one of these names for a table in their setup package, 
a collision will occur and WiX will not be able to represent it properly. 
In order to prepare for this scenario, wed like to preface all WiX-specific 
table names with Wix similar to how MSI deals with collisions since MSI 2.0 
but prefixing all their tables with Msi. This prefix will essentially 
become a namespace for WiX-specific tables 

Re: [WiX-users] rfc: long names in WiX 3.0 COM registration

[Dave Williamson]

You have my vote on anything that replaces short file 
name limitations including this specific bug. It may take some time to 
make the edits but the good thing about this type of edit is the information is 
right there anyway in some form or fashion.

Dave WilliamsonClear Sky 
Softwarewww.clearskysoftware.com




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Derek 
CiceroneSent: Thursday, July 06, 2006 3:02 PMTo: 
wix-users@lists.sourceforge.netCc: 
[EMAIL PROTECTED]Subject: [WiX-users] rfc: long names in 
WiX 3.0 COM registration


This is another simple rfc. 
Wed like to change the COM registration written by the Class / element 
to be long file names (versus the current short file names). In terms of 
how this will affect MSI files, it basically means that instead of writing 
registry keys with [!FileId], wed begin to use [#FileId] (quotes needed for 
paths that may contain spaces).

For more information on this issue, 
please see the bug:
https://sourceforge.net/tracker/index.php?func=detailaid=1445483group_id=105970atid=642714

Thanks,
Derek
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] outlook settings not working with the mailing list

[Dave Williamson]

I'm not sure.  But I can tell you that I have seen it as well over the past 
couple of weeks and therefore it isn't specific to your
Outlook. 


Dave Williamson
Clear Sky Software
www.clearskysoftware.com





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of steve baker
Sent: Thursday, July 06, 2006 3:53 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] outlook settings not working with the mailing list

i keep getting responses from [EMAIL PROTECTED]
when i try to send mail from outlook. it is set to send as plain text.

what causes this?

TIA,

Steve

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] job postings...

[Dave Williamson]

I concur.  By having a separate mailing list those interested can opt 
themselves in.


Dave Williamson
Clear Sky Software





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of david adams
Sent: Tuesday, June 20, 2006 7:48 PM
To: WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] job postings...

That was so simple that I was going to suggest the same thing.

David Adams
MSN MessengerID: [EMAIL PROTECTED]





From: James Carter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] job postings...
Date: Tue, 20 Jun 2006 16:40:09 -0700
MIME-Version: 1.0
Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by 
bay0-mc7-f19.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Tue, 
20 Jun 2006 16:40:13 -0700
Received: from sc8-sf-list1-new.sourceforge.net (unknown [10.3.1.93])by 
sc8-sf-spam2.sourceforge.net (Postfix) with ESMTPid ADC542E08A; Tue, 20 Jun 
2006 16:40:12 -0700 (PDT)
Received: from sc8-sf-mx1-b.sourceforge.net 
([10.3.1.91]helo=mail.sourceforge.net)by sc8-sf-list1-new.sourceforge.net 
with esmtp (Exim 4.43)id 1FsppL-0003V4-JAfor 
WiX-users@lists.sourceforge.net; Tue, 20 Jun 2006 16:40:11 -0700
Received: from wx-out-0102.google.com ([66.249.82.203])by 
mail.sourceforge.net with esmtp (Exim 4.44) id 1FsppL-0005os-A9for 
WiX-users@lists.sourceforge.net; Tue, 20 Jun 2006 16:40:11 -0700
Received: by wx-out-0102.google.com with SMTP id t4so24449wxcfor 
WiX-users@lists.sourceforge.net;Tue, 20 Jun 2006 16:40:10 -0700 (PDT)
Received: by 10.70.49.13 with SMTP id w13mr19886wxw;Tue, 20 Jun 2006 
16:40:09 -0700 (PDT)
Received: by 10.70.65.1 with HTTP; Tue, 20 Jun 2006 16:40:09 -0700 (PDT)
X-Message-Info: LsUYwwHHNt37bHJQxJdRKLYf4+r0T1E8jvqyQFN16RI=
References: [EMAIL PROTECTED]
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by sourceforge.net.See 
http://spamassassin.org/tag/ for more details.Report problems 
tohttp://sf.net/tracker/?func=addgroup_id=1atid=210.0 RCVD_BY_IP  
Received by mail server with no name0.1 HTML_30_40 
BODY: Message is 30% to 40% HTML0.0 HTML_MESSAGE   BODY: HTML 
included in message
X-BeenThere: wix-users@lists.sourceforge.net
X-Mailman-Version: 2.1.8
Precedence: list
List-Id: General discussion for Windows Installer XML 
toolset.wix-users.lists.sourceforge.net
List-Unsubscribe: 
https://lists.sourceforge.net/lists/listinfo/wix-users,mailto:[EMAIL 
PROTECTED]
List-Archive: 
http://sourceforge.net/mailarchive/forum.php?forum=wix-users
List-Post: mailto:wix-users@lists.sourceforge.net
List-Help: mailto:[EMAIL PROTECTED]
List-Subscribe: 
https://lists.sourceforge.net/lists/listinfo/wix-users,mailto:[EMAIL 
PROTECTED]
Errors-To: [EMAIL PROTECTED]
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 20 Jun 2006 23:40:13.0849 (UTC) 
FILETIME=[E08C3890:01C694C2]

Why not just start another mailing list ([EMAIL PROTECTED])?
Then those of us interested could subscribe to it. Maybe I'm 
oversimplifying
the situation.

-James

On 6/20/06, Rob Mensching [EMAIL PROTECTED] wrote:

I recently had some people ask me if it would be okay for them to send out
job requests to this mailing list.  I thought about it and I was
conflicted.
On one hand, this is place to talk about the WiX toolset, how to use it,
and
how to improve it.  Job postings don't belong here.  On the other hand,
the
people that hang out here would likely be very good matches for some of
the
positions I've heard queries for.

I'm still leaning towards my initial feeling (No) but I thought I might
as
well just ask here to see what everyone else felt.



___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users





___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Product clashes

[Dave Williamson]

Wow!  What in the world kind of logic is that!

Very good to know.

Dave



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Hamflett
Sent: Friday, June 16, 2006 4:10 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Product clashes

After a lot of testing and talking to ATI, it seems the problem is that the ATI 
uninstaller is 
indiscriminately removing any product with the uppercase letters 'ATI' in it's 
name.  Does this 
sound like the cause of your past problem?

Rob

Francis Kam wrote:
 I don't have the answer, but I can say that I have seen behavior in the 
 past which led me to the same conclusions.  I can't remember when it 
 was, but I do remember it was with ATI drivers.
  
 -Francis
  
 
 
  
 On 5/26/06, *Rob Hamflett* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 
 wrote:
 
 This isn't WiX related, but I hope you don't mind me posting
 this.  I find that the level of
 expertise in this newsgroup/list is generally higher than the other
 MSI newsgroups I read, and I'm
 in disbelief at what's happening.
 
 I've got a rather weird problem, and I'm just trying to think
 through possible causes.  My problem
 is that when you uninstall the ATI drivers (which you need to do
 during an upgrade) two of my
 products get uninstalled. I have suspicions about a third, but
 haven't tested for that yet.  It's
 really strange.  If you remove the ATI drivers from Add/Remove
 Programs, our products are removed
 when it's finished.  There is also a program of theirs that you can
 download and run to uninstall
 all the ATI software.  When you run this executable it asks you the
 normal 'are you sure?' question,
 and when you click OK you get a progress only dialog with the title
 Uninstalling my-product
 before it opens their maintenance dialog.
 
 This happens across different product versions and different
 products with different package,
 product and upgrade codes , and different versions numbers.  I can
 only assume that there is a
 component GUID clash, and that their software is looking for the
 product that contains that GUID and
 is uninstalling it.  I know it sounds highly unlikely (I'm not even
 sure it's possible) but a GUID
 clash is the only thing I can think of.  The ATI installers appear
 to use InstallShield and there's
 no useful information about them under their key in the Uninstall
 section of the registry.  The
 remove command is a call to an entry point in a DLL and there's no
 product code given either.
 
 Does anyone have any idea what could be going on before I have to
 make an international phone call
 to try and get hold of their setup developer?
 
 Rob
 
 
 
 ---
 All the advantages of Linux Managed Hosting--Without the Cost and Risk!
 Fully trained technicians. The highest number of Red Hat
 certifications in
 the hosting industry. Fanatical Support. Click to learn more
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net mailto:WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 



___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users