Menu
▾
▴
wix-devs — Windows Installer XML toolset developer mailing list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(72) |
May
(71) |
Jun
(30) |
Jul
(34) |
Aug
(52) |
Sep
(40) |
Oct
(72) |
Nov
(46) |
Dec
(93) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(67) |
Feb
(169) |
Mar
(147) |
Apr
(131) |
May
(169) |
Jun
(179) |
Jul
(292) |
Aug
(184) |
Sep
(212) |
Oct
(146) |
Nov
(138) |
Dec
(72) |
| 2006 |
Jan
(82) |
Feb
(183) |
Mar
(129) |
Apr
(237) |
May
(122) |
Jun
(125) |
Jul
(138) |
Aug
(173) |
Sep
(114) |
Oct
(251) |
Nov
(258) |
Dec
(212) |
| 2007 |
Jan
(270) |
Feb
(169) |
Mar
(179) |
Apr
(155) |
May
(159) |
Jun
(188) |
Jul
(225) |
Aug
(227) |
Sep
(146) |
Oct
(352) |
Nov
(145) |
Dec
(151) |
| 2008 |
Jan
(148) |
Feb
(147) |
Mar
(89) |
Apr
(426) |
May
(524) |
Jun
(4) |
Jul
(13) |
Aug
(11) |
Sep
(4) |
Oct
(23) |
Nov
(38) |
Dec
(28) |
| 2009 |
Jan
(48) |
Feb
(39) |
Mar
(30) |
Apr
(33) |
May
(28) |
Jun
(10) |
Jul
(4) |
Aug
(4) |
Sep
(7) |
Oct
(3) |
Nov
|
Dec
(27) |
| 2010 |
Jan
(11) |
Feb
(7) |
Mar
(15) |
Apr
(23) |
May
(41) |
Jun
(28) |
Jul
(27) |
Aug
(26) |
Sep
(38) |
Oct
(9) |
Nov
(14) |
Dec
(14) |
| 2011 |
Jan
(21) |
Feb
(7) |
Mar
(5) |
Apr
(9) |
May
(4) |
Jun
(11) |
Jul
(8) |
Aug
(10) |
Sep
(11) |
Oct
(9) |
Nov
(14) |
Dec
(1) |
| 2012 |
Jan
(27) |
Feb
(2) |
Mar
(1) |
Apr
(26) |
May
(23) |
Jun
(2) |
Jul
(17) |
Aug
(7) |
Sep
(5) |
Oct
(22) |
Nov
(33) |
Dec
(6) |
| 2013 |
Jan
(92) |
Feb
(119) |
Mar
(123) |
Apr
(90) |
May
(87) |
Jun
(58) |
Jul
(71) |
Aug
(88) |
Sep
(82) |
Oct
(152) |
Nov
(148) |
Dec
(77) |
| 2014 |
Jan
(130) |
Feb
(154) |
Mar
(108) |
Apr
(78) |
May
(104) |
Jun
(101) |
Jul
(156) |
Aug
(57) |
Sep
(51) |
Oct
(107) |
Nov
(130) |
Dec
(52) |
| 2015 |
Jan
(72) |
Feb
(20) |
Mar
(53) |
Apr
(38) |
May
(18) |
Jun
(13) |
Jul
(29) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2022 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Heath S. <he...@ou...> - 2015-03-21 01:31:33
|
What several on the MSI team have told me in the past: if it's not documented, it's not supported. Just sayin'. Heath Stewart Software Engineer Visual Studio, Microsoft http://blogs.msdn.com/heaths From: bo...@fi... To: wix...@li... Date: Sat, 21 Mar 2015 00:57:44 +0000 Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute I know that’s true of the general case but there’s nothing in the RegLocator doc to suggest it applies to searches. I’m going to try a file search – I can see that being affected. (I’m wondering if Burn handles that case either…) From: Heath Stewart [mailto:he...@ou...] Sent: Friday, 20 March, 2015 20:42 To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 32-bit MSIs can do 64-bit'y things, but it's documented as not supported. What works currently works only because they didn't prevent it (IIRC, registry keys) but one shouldn't take advantage of this. Heath Stewart Software Engineer Visual Studio, Microsoft http://blogs.msdn.com/heaths From: bo...@fi... To: wix...@li... Date: Fri, 20 Mar 2015 23:17:08 +0000 Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 64-bit searches are legal (or at least aren’t contraindicated) and work from 32-bit packages. So we need to keep a way to specify that. Naming both is hard… From: Rob Mensching [mailto:ro...@fi...] Sent: Friday, 20 March, 2015 17:22 To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 1. I don’t understand this comment in the WIP: This attribute will not require the "-arch" switch to function properly. The –arch switch is most definitely required. It’s handled by default in MSBuild. It’s very, very important. 2. I’m also not thrilled with 'Always32Bit' name. I like “always” better than “force” but “32Bit” feels funny. Bob can you bail us out here? 3. Searches in Burn *may* be different. *Maybe* even in MSI. I don’t remember if 32-bit MSIs can do 64-bit searches. Anyone else remember? If searches are different then maybe “Win64” attribute is bad name and we can come up with a better name for searching hives (that may default to –arch). _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Mike Carlson [mailto:mi...@fi...] Sent: Wednesday, March 18, 2015 3:38 PM To: wix...@li... Subject: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute I’d like to propose replacing the Win64 attribute with something more intuitive in WiX v4.0. Here is the WIP: http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/ I appreciate feedback. Thanks, Mike Carlson ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li... https://lists.sourceforge.net/lists/listinfo/wix-devs ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li... https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: Bob A. <bo...@fi...> - 2015-03-21 00:57:56
|
I know that's true of the general case but there's nothing in the RegLocator doc to suggest it applies to searches. I'm going to try a file search - I can see that being affected. (I'm wondering if Burn handles that case either...) From: Heath Stewart [mailto:he...@ou...] Sent: Friday, 20 March, 2015 20:42 To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 32-bit MSIs can do 64-bit'y things, but it's documented as not supported. What works currently works only because they didn't prevent it (IIRC, registry keys) but one shouldn't take advantage of this. Heath Stewart Software Engineer Visual Studio, Microsoft http://blogs.msdn.com/heaths ________________________________ From: bo...@fi...<mailto:bo...@fi...> To: wix...@li...<mailto:wix...@li...> Date: Fri, 20 Mar 2015 23:17:08 +0000 Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 64-bit searches are legal (or at least aren't contraindicated) and work from 32-bit packages. So we need to keep a way to specify that. Naming both is hard... From: Rob Mensching [mailto:ro...@fi...] Sent: Friday, 20 March, 2015 17:22 To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 1. I don't understand this comment in the WIP: This attribute will not require the "-arch" switch to function properly. The -arch switch is most definitely required. It's handled by default in MSBuild. It's very, very important. 2. I'm also not thrilled with 'Always32Bit' name. I like "always" better than "force" but "32Bit" feels funny. Bob can you bail us out here? 3. Searches in Burn *may* be different. *Maybe* even in MSI. I don't remember if 32-bit MSIs can do 64-bit searches. Anyone else remember? If searches are different then maybe "Win64" attribute is bad name and we can come up with a better name for searching hives (that may default to -arch). _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Mike Carlson [mailto:mi...@fi...] Sent: Wednesday, March 18, 2015 3:38 PM To: wix...@li...<mailto:wix...@li...> Subject: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute I'd like to propose replacing the Win64 attribute with something more intuitive in WiX v4.0. Here is the WIP: http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/ I appreciate feedback. Thanks, Mike Carlson ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: Heath S. <he...@ou...> - 2015-03-21 00:41:55
|
32-bit MSIs can do 64-bit'y things, but it's documented as not supported. What works currently works only because they didn't prevent it (IIRC, registry keys) but one shouldn't take advantage of this. Heath Stewart Software Engineer Visual Studio, Microsoft http://blogs.msdn.com/heaths From: bo...@fi... To: wix...@li... Date: Fri, 20 Mar 2015 23:17:08 +0000 Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 64-bit searches are legal (or at least aren’t contraindicated) and work from 32-bit packages. So we need to keep a way to specify that. Naming both is hard… From: Rob Mensching [mailto:ro...@fi...] Sent: Friday, 20 March, 2015 17:22 To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 1. I don’t understand this comment in the WIP: This attribute will not require the "-arch" switch to function properly. The –arch switch is most definitely required. It’s handled by default in MSBuild. It’s very, very important. 2. I’m also not thrilled with 'Always32Bit' name. I like “always” better than “force” but “32Bit” feels funny. Bob can you bail us out here? 3. Searches in Burn *may* be different. *Maybe* even in MSI. I don’t remember if 32-bit MSIs can do 64-bit searches. Anyone else remember? If searches are different then maybe “Win64” attribute is bad name and we can come up with a better name for searching hives (that may default to –arch). _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Mike Carlson [mailto:mi...@fi...] Sent: Wednesday, March 18, 2015 3:38 PM To: wix...@li... Subject: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute I’d like to propose replacing the Win64 attribute with something more intuitive in WiX v4.0. Here is the WIP: http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/ I appreciate feedback. Thanks, Mike Carlson ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li... https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: Bob A. <bo...@fi...> - 2015-03-20 23:17:27
|
64-bit searches are legal (or at least aren't contraindicated) and work from 32-bit packages. So we need to keep a way to specify that. Naming both is hard... From: Rob Mensching [mailto:ro...@fi...] Sent: Friday, 20 March, 2015 17:22 To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 1. I don't understand this comment in the WIP: This attribute will not require the "-arch" switch to function properly. The -arch switch is most definitely required. It's handled by default in MSBuild. It's very, very important. 2. I'm also not thrilled with 'Always32Bit' name. I like "always" better than "force" but "32Bit" feels funny. Bob can you bail us out here? 3. Searches in Burn *may* be different. *Maybe* even in MSI. I don't remember if 32-bit MSIs can do 64-bit searches. Anyone else remember? If searches are different then maybe "Win64" attribute is bad name and we can come up with a better name for searching hives (that may default to -arch). _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Mike Carlson [mailto:mi...@fi...] Sent: Wednesday, March 18, 2015 3:38 PM To: wix...@li...<mailto:wix...@li...> Subject: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute I'd like to propose replacing the Win64 attribute with something more intuitive in WiX v4.0. Here is the WIP: http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/ I appreciate feedback. Thanks, Mike Carlson |
|
From: Rob M. <ro...@fi...> - 2015-03-20 23:06:31
|
Yes, Server Core, exactly. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Heath Stewart [mailto:he...@ou...] Sent: Friday, March 20, 2015 4:01 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute Any reason the engine would need to be 64-bit, though? Only Server Core currently supports 64-bit only, and not much runs on that. 64-bit processes affect default registry and file system paths, and while MSI and isolated EXEs (including wusa.exe, since we just invoke that) will work correctly, other things with Burn may not - like ARP/bundle registration. Fortunately, and against the MSI team's wishes, I stuck the package dependency stuff in a reflected/shared key but registry searches would be adversely affected and setup devs may not realize it. Heath Stewart Software Engineer Visual Studio, Microsoft http://blogs.msdn.com/heaths ________________________________ Date: Fri, 20 Mar 2015 17:13:09 -0500 From: r.s...@gm...<mailto:r.s...@gm...> To: wix...@li...<mailto:wix...@li...> Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute The engine might be 64-bit, but I don't think that should affect how the bundle works. Things are different for MSI since the package is inherently 32-bit or 64-bit. Naming is hard. I think Win64 works for Burn, I'd have to think about whether there's a better name. On Fri, Mar 20, 2015 at 4:53 PM, Rob Mensching <ro...@fi...<mailto:ro...@fi...>> wrote: What if we had 64-bit Burn that was affected by -arch switch? Ultimately, I think I agree with you. Thus my point in #3 where I'm wondering if there is a better name than "Win64". Any thoughts on that? _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Sean Hall [mailto:r.s...@gm...<mailto:r.s...@gm...>] Sent: Friday, March 20, 2015 2:34 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute Looks like there's only ApprovedExeForElevation and util:RegistrySearch in Burn. These aren't going to be affected by the -arch switch, so it doesn't make sense to me to have "force" or "always" in the name. On Fri, Mar 20, 2015 at 4:21 PM, Rob Mensching <ro...@fi...<mailto:ro...@fi...>> wrote: 1. I don't understand this comment in the WIP: This attribute will not require the "-arch" switch to function properly. The -arch switch is most definitely required. It's handled by default in MSBuild. It's very, very important. 2. I'm also not thrilled with 'Always32Bit' name. I like "always" better than "force" but "32Bit" feels funny. Bob can you bail us out here? 3. Searches in Burn *may* be different. *Maybe* even in MSI. I don't remember if 32-bit MSIs can do 64-bit searches. Anyone else remember? If searches are different then maybe "Win64" attribute is bad name and we can come up with a better name for searching hives (that may default to -arch). _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Mike Carlson [mailto:mi...@fi...<mailto:mi...@fi...>] Sent: Wednesday, March 18, 2015 3:38 PM To: wix...@li...<mailto:wix...@li...> Subject: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute I'd like to propose replacing the Win64 attribute with something more intuitive in WiX v4.0. Here is the WIP: http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/ I appreciate feedback. Thanks, Mike Carlson ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: Heath S. <he...@ou...> - 2015-03-20 23:01:23
|
Any reason the engine would need to be 64-bit, though? Only Server Core currently supports 64-bit only, and not much runs on that. 64-bit processes affect default registry and file system paths, and while MSI and isolated EXEs (including wusa.exe, since we just invoke that) will work correctly, other things with Burn may not - like ARP/bundle registration. Fortunately, and against the MSI team's wishes, I stuck the package dependency stuff in a reflected/shared key but registry searches would be adversely affected and setup devs may not realize it. Heath Stewart Software Engineer Visual Studio, Microsoft http://blogs.msdn.com/heaths Date: Fri, 20 Mar 2015 17:13:09 -0500 From: r.s...@gm... To: wix...@li... Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute The engine might be 64-bit, but I don't think that should affect how the bundle works. Things are different for MSI since the package is inherently 32-bit or 64-bit. Naming is hard. I think Win64 works for Burn, I'd have to think about whether there's a better name. On Fri, Mar 20, 2015 at 4:53 PM, Rob Mensching <ro...@fi...> wrote: What if we had 64-bit Burn that was affected by –arch switch? Ultimately, I think I agree with you. Thus my point in #3 where I’m wondering if there is a better name than “Win64”. Any thoughts on that? _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Sean Hall [mailto:r.s...@gm...] Sent: Friday, March 20, 2015 2:34 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute Looks like there's only ApprovedExeForElevation and util:RegistrySearch in Burn. These aren't going to be affected by the -arch switch, so it doesn't make sense to me to have "force" or "always" in the name. On Fri, Mar 20, 2015 at 4:21 PM, Rob Mensching <ro...@fi...> wrote: 1. I don’t understand this comment in the WIP: This attribute will not require the "-arch" switch to function properly. The –arch switch is most definitely required. It’s handled by default in MSBuild. It’s very, very important. 2. I’m also not thrilled with 'Always32Bit' name. I like “always” better than “force” but “32Bit” feels funny. Bob can you bail us out here? 3. Searches in Burn *may* be different. *Maybe* even in MSI. I don’t remember if 32-bit MSIs can do 64-bit searches. Anyone else remember? If searches are different then maybe “Win64” attribute is bad name and we can come up with a better name for searching hives (that may default to –arch). _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Mike Carlson [mailto:mi...@fi...] Sent: Wednesday, March 18, 2015 3:38 PM To: wix...@li... Subject: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute I’d like to propose replacing the Win64 attribute with something more intuitive in WiX v4.0. Here is the WIP: http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/ I appreciate feedback. Thanks, Mike Carlson ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li... https://lists.sourceforge.net/lists/listinfo/wix-devs ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li... https://lists.sourceforge.net/lists/listinfo/wix-devs ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li... https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: Sean H. <r.s...@gm...> - 2015-03-20 22:13:17
|
The engine might be 64-bit, but I don't think that should affect how the bundle works. Things are different for MSI since the package is inherently 32-bit or 64-bit. Naming is hard. I think Win64 works for Burn, I'd have to think about whether there's a better name. On Fri, Mar 20, 2015 at 4:53 PM, Rob Mensching <ro...@fi...> wrote: > What if we had 64-bit Burn that was affected by –arch switch? > > > > Ultimately, I think I agree with you. Thus my point in #3 where I’m > wondering if there is a better name than “Win64”. Any thoughts on that? > > > > _______________________________________________________________ > > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > > > *From:* Sean Hall [mailto:r.s...@gm...] > *Sent:* Friday, March 20, 2015 2:34 PM > *To:* WiX toolset developer mailing list > *Subject:* Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute > > > > Looks like there's only ApprovedExeForElevation and util:RegistrySearch in > Burn. These aren't going to be affected by the -arch switch, so it doesn't > make sense to me to have "force" or "always" in the name. > > > > On Fri, Mar 20, 2015 at 4:21 PM, Rob Mensching <ro...@fi...> wrote: > > 1. I don’t understand this comment in the WIP: > > > > This attribute will not require the "-arch" switch to function properly. > > > > The –arch switch is most definitely required. It’s handled by default in > MSBuild. It’s very, very important. > > > > 2. I’m also not thrilled with 'Always32Bit' name. I like “always” > better than “force” but “32Bit” feels funny. Bob can you bail us out here? > > > > 3. Searches in Burn **may** be different. **Maybe** even in MSI. I don’t > remember if 32-bit MSIs can do 64-bit searches. Anyone else remember? If > searches are different then maybe “Win64” attribute is bad name and we can > come up with a better name for searching hives (that may default to –arch). > > > > _______________________________________________________________ > > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > > > *From:* Mike Carlson [mailto:mi...@fi...] > *Sent:* Wednesday, March 18, 2015 3:38 PM > *To:* wix...@li... > *Subject:* [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute > > > > I’d like to propose replacing the Win64 attribute with something more > intuitive in WiX v4.0. > > > > Here is the WIP: > > > http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/ > > > > I appreciate feedback. > > > > Thanks, > > Mike Carlson > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > WiX-devs mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-devs > > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > WiX-devs mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-devs > > |
|
From: Rob M. <ro...@fi...> - 2015-03-20 21:53:32
|
What if we had 64-bit Burn that was affected by –arch switch? Ultimately, I think I agree with you. Thus my point in #3 where I’m wondering if there is a better name than “Win64”. Any thoughts on that? _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Sean Hall [mailto:r.s...@gm...] Sent: Friday, March 20, 2015 2:34 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute Looks like there's only ApprovedExeForElevation and util:RegistrySearch in Burn. These aren't going to be affected by the -arch switch, so it doesn't make sense to me to have "force" or "always" in the name. On Fri, Mar 20, 2015 at 4:21 PM, Rob Mensching <ro...@fi...<mailto:ro...@fi...>> wrote: 1. I don’t understand this comment in the WIP: This attribute will not require the "-arch" switch to function properly. The –arch switch is most definitely required. It’s handled by default in MSBuild. It’s very, very important. 2. I’m also not thrilled with 'Always32Bit' name. I like “always” better than “force” but “32Bit” feels funny. Bob can you bail us out here? 3. Searches in Burn *may* be different. *Maybe* even in MSI. I don’t remember if 32-bit MSIs can do 64-bit searches. Anyone else remember? If searches are different then maybe “Win64” attribute is bad name and we can come up with a better name for searching hives (that may default to –arch). _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Mike Carlson [mailto:mi...@fi...<mailto:mi...@fi...>] Sent: Wednesday, March 18, 2015 3:38 PM To: wix...@li...<mailto:wix...@li...> Subject: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute I’d like to propose replacing the Win64 attribute with something more intuitive in WiX v4.0. Here is the WIP: http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/ I appreciate feedback. Thanks, Mike Carlson ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: Sean H. <r.s...@gm...> - 2015-03-20 21:33:44
|
Looks like there's only ApprovedExeForElevation and util:RegistrySearch in Burn. These aren't going to be affected by the -arch switch, so it doesn't make sense to me to have "force" or "always" in the name. On Fri, Mar 20, 2015 at 4:21 PM, Rob Mensching <ro...@fi...> wrote: > 1. I don’t understand this comment in the WIP: > > > > This attribute will not require the "-arch" switch to function properly. > > > > The –arch switch is most definitely required. It’s handled by default in > MSBuild. It’s very, very important. > > > > 2. I’m also not thrilled with 'Always32Bit' name. I like “always” > better than “force” but “32Bit” feels funny. Bob can you bail us out here? > > > > 3. Searches in Burn **may** be different. **Maybe** even in MSI. I don’t > remember if 32-bit MSIs can do 64-bit searches. Anyone else remember? If > searches are different then maybe “Win64” attribute is bad name and we can > come up with a better name for searching hives (that may default to –arch). > > > > _______________________________________________________________ > > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > > > *From:* Mike Carlson [mailto:mi...@fi...] > *Sent:* Wednesday, March 18, 2015 3:38 PM > *To:* wix...@li... > *Subject:* [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute > > > > I’d like to propose replacing the Win64 attribute with something more > intuitive in WiX v4.0. > > > > Here is the WIP: > > > http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/ > > > > I appreciate feedback. > > > > Thanks, > > Mike Carlson > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > WiX-devs mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-devs > > |
|
From: Rob M. <ro...@fi...> - 2015-03-20 21:21:44
|
1. I don't understand this comment in the WIP: This attribute will not require the "-arch" switch to function properly. The -arch switch is most definitely required. It's handled by default in MSBuild. It's very, very important. 2. I'm also not thrilled with 'Always32Bit' name. I like "always" better than "force" but "32Bit" feels funny. Bob can you bail us out here? 3. Searches in Burn *may* be different. *Maybe* even in MSI. I don't remember if 32-bit MSIs can do 64-bit searches. Anyone else remember? If searches are different then maybe "Win64" attribute is bad name and we can come up with a better name for searching hives (that may default to -arch). _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Mike Carlson [mailto:mi...@fi...] Sent: Wednesday, March 18, 2015 3:38 PM To: wix...@li... Subject: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute I'd like to propose replacing the Win64 attribute with something more intuitive in WiX v4.0. Here is the WIP: http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/ I appreciate feedback. Thanks, Mike Carlson |
|
From: Mike C. <mi...@fi...> - 2015-03-20 20:44:52
|
I saw that Sean commented this on the WIP pull request:
I'm not sure getting rid of Win64 in Bundle elements makes sense.
Sean, are you talking about the ApprovedExeForElevation element?
From: Mike Carlson [mailto:mi...@fi...]
Sent: Wednesday, March 18, 2015 3:38 PM
To: wix...@li...
Subject: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute
I'd like to propose replacing the Win64 attribute with something more intuitive in WiX v4.0.
Here is the WIP:
http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/
I appreciate feedback.
Thanks,
Mike Carlson
|
|
From: Heath S. <he...@ou...> - 2015-03-19 03:58:36
|
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ |
|
From: Mike C. <mi...@fi...> - 2015-03-18 22:37:49
|
I'd like to propose replacing the Win64 attribute with something more intuitive in WiX v4.0.
Here is the WIP:
http://wixtoolset.org/development/wips/4707-replace-win64-with-intuitive-attribute/
I appreciate feedback.
Thanks,
Mike Carlson
|
|
From: Rob M. <ro...@fi...> - 2015-03-18 04:51:07
|
100% agree with this position. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Sean Hall [mailto:r.s...@gm...] Sent: Sunday, March 1, 2015 12:53 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] [wix4] WIXFEAT4658 - Add builtin button functionality to thmutil (#89) My pull request gives the ability to do whatever kind of dialog sequence you want. I'd like to see some real world complex dialogs to look at before implementing stuff like the PreviousPageAction and ResetSequence. |
|
From: Rob M. <ro...@fi...> - 2015-03-18 04:50:48
|
I expect it’s by design since pulling the source out from under an MSI that was delivered by a bundle leaves the user in a bad place if they ever need the source again. Of course, it almost guarantees the MSI source is “leaked” in the cache. There is no great answer here (unless we started teaching MSIs how to clean their own cache… which is interesting but terrifying at the same time). _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Sean Hall [mailto:r.s...@gm...] Sent: Sunday, March 1, 2015 12:18 PM To: WiX toolset developer mailing list Subject: [WiX-devs] Burn caching behavior during uninstall When a BA plans and applies the Uninstall action, but requests its packages to be Present, the packages are not cleaned from the package cache. Is this by design, or a bug? Detect begin, 1 packages Detected package: Test.msi, state: Present, cached: Complete Detect complete, result: 0x0 Plan begin, 1 packages, action: Uninstall Planned package: Test.msi, state: Present, default requested: Absent, ba requested: Present, execute: None, rollback: None, cache: No, uncache: No, dependency: Unregister Plan complete, result: 0x0 |
|
From: Rob M. <ro...@fi...> - 2015-03-17 20:08:43
|
Someone needs to do the work. We don’t necessarily need the exact same packages (with all the private data in it)… just something that can satisfy the tests (or update tests as appropriate). Work to be done by someone that wants to do it. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Brian Rogers [mailto:rog...@gm...] Sent: Tuesday, March 17, 2015 1:05 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WiX Test Packages :) Is there something I should say to this gentleman or just ignore the need? Side note, not that I have a lot of time, but is this something only previous MS people can do? If so, is there a way to get in on the fun? Hope all is well! Brian Rogers "Intelligence removes complexity." - Me http://blogs.msdn.com/icumove On Tue, Mar 17, 2015 at 1:01 PM, Rob Mensching <ro...@fi...<mailto:ro...@fi...>> wrote: Yep. Outstanding task. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Brian Rogers [mailto:rog...@gm...<mailto:rog...@gm...>] Sent: Tuesday, March 17, 2015 12:58 PM To: Windows Installer XML toolset developer mailing list Subject: [WiX-devs] WiX Test Packages Hey Rob / Bob / Heath, What are you guys doing to replace all the MSI packages we had internally? I only ask because there is a PR and I feel there should be tests for it but don't know the new way. Thanks, Brian Rogers "Intelligence removes complexity." - Me http://blogs.msdn.com/icumove ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: Brian R. <rog...@gm...> - 2015-03-17 20:05:15
|
:) Is there something I should say to this gentleman or just ignore the need? Side note, not that I have a lot of time, but is this something only previous MS people can do? If so, is there a way to get in on the fun? Hope all is well! Brian Rogers "Intelligence removes complexity." - Me http://blogs.msdn.com/icumove On Tue, Mar 17, 2015 at 1:01 PM, Rob Mensching <ro...@fi...> wrote: > Yep. Outstanding task. > > > > _______________________________________________________________ > > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > > > > > *From:* Brian Rogers [mailto:rog...@gm...] > *Sent:* Tuesday, March 17, 2015 12:58 PM > *To:* Windows Installer XML toolset developer mailing list > *Subject:* [WiX-devs] WiX Test Packages > > > > Hey Rob / Bob / Heath, > > > > What are you guys doing to replace all the MSI packages we had internally? > I only ask because there is a PR and I feel there should be tests for it > but don't know the new way. > > > > Thanks, > > > Brian Rogers > "Intelligence removes complexity." - Me > http://blogs.msdn.com/icumove > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > WiX-devs mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-devs > > |
|
From: Rob M. <ro...@fi...> - 2015-03-17 20:01:57
|
Yep. Outstanding task. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Brian Rogers [mailto:rog...@gm...] Sent: Tuesday, March 17, 2015 12:58 PM To: Windows Installer XML toolset developer mailing list Subject: [WiX-devs] WiX Test Packages Hey Rob / Bob / Heath, What are you guys doing to replace all the MSI packages we had internally? I only ask because there is a PR and I feel there should be tests for it but don't know the new way. Thanks, Brian Rogers "Intelligence removes complexity." - Me http://blogs.msdn.com/icumove |
|
From: Brian R. <rog...@gm...> - 2015-03-17 19:57:56
|
Hey Rob / Bob / Heath, What are you guys doing to replace all the MSI packages we had internally? I only ask because there is a PR and I feel there should be tests for it but don't know the new way. Thanks, Brian Rogers "Intelligence removes complexity." - Me http://blogs.msdn.com/icumove |
|
From: Rob M. <ro...@fi...> - 2015-03-16 21:43:19
|
Next WiX Online meeting will be: March 16th, 2015 @14:30 PST Agenda items: * Triage ......................................................................................................................................... --> Join Lync Meeting<https://meet.lync.com/firegiant/rob/H2YHJ4TN> Help<http://go.microsoft.com/fwlink/?LinkId=389737> [!OC([1033])!] ......................................................................................................................................... |
|
From: Rob M. <ro...@fi...> - 2015-03-09 23:41:39
|
Next WiX Online meeting will be: March 10th, 2015 @14:30 PST Agenda items: * Triage ......................................................................................................................................... --> Join Lync Meeting<https://meet.lync.com/firegiant/rob/2HMJ6R0S> Help<http://go.microsoft.com/fwlink/?LinkId=389737> [!OC([1033])!] ......................................................................................................................................... |
|
From: Bob A. <bo...@jo...> - 2015-03-09 01:37:44
|
I think there's a bug in C++/14 that causes the .wixburn section to be dropped. I can't even find it in the .obj. No doc or warnings that complain about #pragma data_seg. Apparently, I'm going to be spending my Sunday night uninstalling VS2015 and reinstalling VS2013. I'm in for a thrill ride! -- sig://boB http://joyofsetup.com/ |
|
From: Sean H. <r.s...@gm...> - 2015-03-06 01:50:02
|
Oops, I didn't mean to send that to wix-users. On Thu, Mar 5, 2015 at 7:13 PM, Sean Hall <r.s...@gm...> wrote: > I get a 404 when going to http://wixtoolset.org/releases/feed/v3.10, and > the bundle can't access it either. > |
|
From: Heath S. <he...@ou...> - 2015-03-05 08:34:27
|
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ |
|
From: Sean H. <r.s...@gm...> - 2015-03-05 02:32:06
|
I find these discussions really hard without any requirements or design docs (which was why I tried to start writing them down <http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-documentation-td7594298.html> ). I think Rob covered why it needs to be between UNINSTALL and CACHE. That also makes it match BOOTSTRAPPER_REQUEST_STATE (where CACHE is between ABSENT and PRESENT). I don't understand the question about the command line. It'll be just like if your BA had a /forceinstall switch (which maybe made it ignore install conditions or something). Burn will not understand it and put it in the command line that it gives to the BA. I cloned your wix4 branch and built a test bundle to see how it worked (it looked the same as wix3 and I wanted to be lazy and use the command line switch): Detected package: NetFx451Web, state: Present, cached: None Detected package: UpdateReplace2MSI.msi, state: Absent, cached: None Detected package: stuff1, state: Absent, cached: None Planned package: NetFx451Web, state: Present, default requested: Present, > ba requested: Present, execute: None, rollback: None, cache: No, uncache: > No, dependency: None > Planned package: UpdateReplace2MSI.msi, state: Absent, default requested: > Present, ba requested: Present, execute: Install, rollback: None, cache: > Yes, uncache: No, dependency: Register > Planned package: stuff1, state: Absent, default requested: Absent, ba > requested: Absent, execute: None, rollback: None, cache: No, uncache: No, > dependency: None > --- Begin plan dump --- > Plan action: Cache > per-machine: true > keep registration by default: true > estimated size: 32768 > Plan cache size: 32768 > Cache action[0]: CHECKPOINT id: 1 > Cache action[1]: PACKAGE_START id: UpdateReplace2MSI.msi, plan index > for skip: 4, payloads to cache: 1, bytes to cache: 32768, skip until > retried: No > Cache action[2]: EXTRACT_CONTAINER id: WixAttachedContainer, working > path: > E:\testprojects\MBA4\UpdateReplace2Bundle\bin\Debug\UpdateReplace2Bundle.exe, > skip until retried: No, skip until acquired by action: 2147483648 > extract package id: UpdateReplace2MSI.msi, payload id: > UpdateReplace2MSI.msi, working path: > C:\Users\First\AppData\Local\Temp\{9a719fca-3c38-4d7d-9461-82c730fc03de}\UpdateReplace2MSI.msi > Cache action[3]: CACHE_PAYLOAD package id: UpdateReplace2MSI.msi, > payload id: UpdateReplace2MSI.msi, working path: > C:\Users\First\AppData\Local\Temp\{9a719fca-3c38-4d7d-9461-82c730fc03de}\UpdateReplace2MSI.msi, > operation: move, skip until retried: No, retry action: 2 > Cache action[4]: PACKAGE_STOP id: UpdateReplace2MSI.msi, skip until > retried: No > Cache action[5]: SIGNAL_SYNCPOINT event handle: 0x3f0, skip until > retried: No > Plan execute package count: 0 > overall progress ticks: 1 > Execute action[0]: ROLLBACK_BOUNDARY id: WixDefaultBoundary, vital: yes > Execute action[1]: CHECKPOINT id: 2 > Execute action[2]: PACKAGE_PROVIDER package id: UpdateReplace2MSI.msi, > action: 1 > Execute action[3]: CHECKPOINT id: 3 > Execute action[4]: PACKAGE_DEPENDENCY package id: > UpdateReplace2MSI.msi, bundle provider key: > {9a719fca-3c38-4d7d-9461-82c730fc03de}, action: 1 > Execute action[5]: CHECKPOINT id: 4 > Execute action[6]: CHECKPOINT id: 5 > Rollback action[0]: ROLLBACK_BOUNDARY id: WixDefaultBoundary, vital: yes > Rollback action[1]: PACKAGE_PROVIDER package id: UpdateReplace2MSI.msi, > action: 2 > Rollback action[2]: CHECKPOINT id: 2 > Rollback action[3]: PACKAGE_DEPENDENCY package id: > UpdateReplace2MSI.msi, bundle provider key: > {9a719fca-3c38-4d7d-9461-82c730fc03de}, action: 2 > Rollback action[4]: CHECKPOINT id: 3 > Rollback action[5]: CHECKPOINT id: 4 > Rollback action[6]: CHECKPOINT id: 5 > Dependency action[0]: PLANNED_PROVIDER key: > {9a719fca-3c38-4d7d-9461-82c730fc03de}, name: (null) > --- End plan dump --- > Plan complete, result: 0x0 > Apply begin > Session begin, registration key: > SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de}, > options: 0x7, disable resume: No > Caching bundle from: > 'C:\Users\First\AppData\Local\Temp\{9a719fca-3c38-4d7d-9461-82c730fc03de}\.be\UpdateReplace2Bundle.exe' > to: 'C:\ProgramData\Package > Cache\{9a719fca-3c38-4d7d-9461-82c730fc03de}\UpdateReplace2Bundle.exe' > Registering bundle dependency provider: > {9a719fca-3c38-4d7d-9461-82c730fc03de}, version: 1.1.0.0 > Updating session, registration key: > SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de}, > resume: Active, restart initiated: No, disable resume: No > Verified acquired payload: UpdateReplace2MSI.msi at path: > C:\ProgramData\Package Cache\.unverified\UpdateReplace2MSI.msi, moving to: > C:\ProgramData\Package > Cache\{3A4998AD-EAE6-4C84-9C2E-576FFD18A9B7}v1.1.0.0\UpdateReplace2MSI.msi. > Registering package dependency provider: > {3A4998AD-EAE6-4C84-9C2E-576FFD18A9B7}, version: (null), package: > UpdateReplace2MSI.msi > Registering dependency: {9a719fca-3c38-4d7d-9461-82c730fc03de} on package > provider: {3A4998AD-EAE6-4C84-9C2E-576FFD18A9B7}, package: > UpdateReplace2MSI.msi > Session end, registration key: > SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de}, > resume: ARP, restart: None, disable resume: No > Updating session, registration key: > SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9a719fca-3c38-4d7d-9461-82c730fc03de}, > resume: ARP, restart initiated: No, disable resume: No > Apply complete, result: 0x0, restart: None, ba requested restart: No This is a Bundle that I reuse over and over again for testing, so the authoring's pretty weird: <Chain DisableSystemRestore="yes"> <PackageGroupRef Id="NetFx451Web"/> <MsiPackage bal:PrereqPackage="yes" SourceFile="$(var.UpdateReplace2MSI.TargetPath)" /> <ExePackage Id="stuff1" SourceFile="C:\Users\First\Downloads\Wix37.exe" InstallCondition="0 = 1" DetectCondition="WixBundleInstalled AND WixBundleAction = 5" /> </Chain> I don't like that the Planned package message says it will install the MSI, but it doesn't actually install it. I'm not sure it should be registering any dependencies during the Cache operation. Before I ran this test I didn't think it mattered that the BOOTSTRAPPER_ACTION_CACHE action wasn't using the BOOTSTRAPPER_REQUEST_STATE_CACHE state, but now I think it has to in order for the execute action to be None. Which means that your pull request won't actually work without my pull request. Sorry. I notice that there are two differences in the refactor of plan.cpp between our pull requests. One is that you disable the rollback actions during the CACHE operation, I don't think you can do that - the packages will be left on the machine without any way to delete them (except manually). Or am I missing something? The other one's a toss up. I chose to look at the special case of BURN_CACHE_TYPE_ALWAYS in ProcessPackage, and you did it in PlanDependencyActions. Naturally I'm biased towards mine... On Wed, Mar 4, 2015 at 10:49 AM, Rob Mensching <ro...@fi...> wrote: > Why? Won’t “additional command-line arguments” be appended so that > whatever was called “CACHE” on the command line (/cache or /store or > /whateverBAchooses) would get put back on there? Or am I not remembering > the code correctly? > > > > _______________________________________________________________ > > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > > > *From:* Heath Stewart [mailto:he...@ou...] > *Sent:* Tuesday, March 3, 2015 10:53 PM > *To:* WiX toolset developer mailing list > *Subject:* Re: [WiX-devs] BOOTSTRAPPER_ACTION_CACHE > > > > Reviewing other changes I may need to make apart from removing command > line support, CoreRecreateCommandLine does pass /cache and seems it would > need to for the original scenario. But since command line args not > understood by Burn are passed through, is this okay? Only a parent BA could > do this, but then again - nothing now sets BURN_COMMAND::action to > BOOTSTRAPPER_ACTION_CACHE. Do we just leave it up to the BAs to know when > to set package stats to CACHE? > > > > - Heath from my Surface Pro 3 > > > > *From:* Heath Stewart <he...@ou...> > *Sent:* Tuesday, March 3, 2015 9:51 PM > *To:* WiX toolset developer mailing list <wix...@li...> > > > > Sean and Rob, during triage you mentioned that you didn't think CACHE > should be before UNINSTALL, but it was placed between LAYOUT and UNINSTALL > (synonymous with Absent often times), which logically makes sense. If > LAYOUT ~= source layout and ABSENT ~= not installed, then CACHE ~= in > between source and install - exactly what the cache is for. > > > > So do you really think this needs to change? At the very least, it should > be close to LAYOUT which is also before UNINSTALL. > > > > - Heath from my Surface Pro 3 > > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > WiX-devs mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-devs > > |
554 messages has been excluded from this view by a project administrator.
