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: Hoover, J. <Jac...@gr...> - 2015-04-13 08:18:19
|
https://github.com/jchoover/wix3/tree/WIXBUG4512 This is a single shot relay command, where the user should not be able to mash the button multiple times for install, repair, uninstall. ________________________________ From: Hoover, Jacob [Jac...@gr...] Sent: Saturday, April 11, 2015 11:09 PM To: Windows Installer XML toolset developer mailing list Subject: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of Install button while update check is running http://wixtoolset.org/issues/4512/ Technically any enabled button would allow multiple clicks between DetectBegin and DetectComplete. The question I have, is shouldn't any installation state info passed in DetectBegin also be passed in DetectComplete? I know in 3.x we can't modify the signature, but to me we shouldn't be proclaiming the overall bundle state until after detection is done. In 3.x, either I could introduce a new state indicator, DetectedAbsentInstalling, which would indicate the button was clicked, or a local member variable in the installation view model that would prevent the double invocation. Which ever pattern we favor, I think we should also apply it to the Repair and Uninstall commands. Even with the detected state not being "available" until DetectComplete, it's almost as if we need a OneShotRelayCommand class to only allow a single invocation, and if a user is able to abort out the OneShotRelay should be reset. Thoughts? Thanks, Jacob |
|
From: Hoover, J. <Jac...@gr...> - 2015-04-12 04:09:27
|
http://wixtoolset.org/issues/4512/ Technically any enabled button would allow multiple clicks between DetectBegin and DetectComplete. The question I have, is shouldn't any installation state info passed in DetectBegin also be passed in DetectComplete? I know in 3.x we can't modify the signature, but to me we shouldn't be proclaiming the overall bundle state until after detection is done. In 3.x, either I could introduce a new state indicator, DetectedAbsentInstalling, which would indicate the button was clicked, or a local member variable in the installation view model that would prevent the double invocation. Which ever pattern we favor, I think we should also apply it to the Repair and Uninstall commands. Even with the detected state not being "available" until DetectComplete, it's almost as if we need a OneShotRelayCommand class to only allow a single invocation, and if a user is able to abort out the OneShotRelay should be reset. Thoughts? Thanks, Jacob |
|
From: Blair M. <os...@li...> - 2015-04-07 06:59:16
|
------------------------------------------------------------------------------ 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: Rob M. <ro...@fi...> - 2015-04-06 21:51:31
|
Next WiX Online meeting will be: April 7th, 2015 @14:30 PST Agenda items: * Triage ......................................................................................................................................... --> Join Lync Meeting<https://meet.lync.com/firegiant/rob/7N97G6DV> Help<http://go.microsoft.com/fwlink/?LinkId=389737> [!OC([1033])!] ......................................................................................................................................... |
|
From: Bob A. <bo...@fi...> - 2015-04-02 21:06:17
|
Patching's broken at the moment: http://wixtoolset.org/issues/4556/ _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Hoover, Jacob [mailto:Jac...@gr...] Sent: Thursday, 2 April, 2015 16:49 To: WiX toolset developer mailing list Subject: [WiX-devs] Status of 4.x - Creating patches Rob/Bob, Do you have any status information so to where the 4.x tools sit? I was trying to rework the unit tests to get the burn related ones functional, and I kept running into issues. Ex: The 4.x binder requires bind variables to be paths, not files. This breaks all tests which pass in the MSI/MSP file names as bind variables. I can fix this with adding Path.GetDirectoryName around the existing calls to the BundleBuilder.Output, or I could add a read only property to BundleBuilder that does the same. The WixToolset.Tool.PyroCommandLine doesn't initialize the default values of properties, which cause access violations. I also ran into a legitimate bug inside of WixToolset.Data.Pdb, the Read method does a comparison that is incorrect if (!reader.LocalName.Equals("wixPdb" == reader.LocalName)) { throw new XmlException(); } >From there, I was haing issue with Pyro not able to create a patch because the Files table was null. When the 4.x refactoring was done, did you do ay manual testing to verify basic functionality? Do you have any docs on the significant refactoring done, or any hints on where to start with the patch generation process failing? (What tool/section of code is responsible for populating the file table which is consumed by pyro?) P.S. For any of the test to work they rely on bits from my outstanding pull request, as the BindBundleCommand was no longer populating packageLanguage/packageManufacturer. Thanks, Jacob |
|
From: Hoover, J. <Jac...@gr...> - 2015-04-02 20:48:38
|
Rob/Bob,
Do you have any status information so to where the 4.x tools sit? I was trying to rework the unit tests to get the burn related ones functional, and I kept running into issues.
Ex:
The 4.x binder requires bind variables to be paths, not files. This breaks all tests which pass in the MSI/MSP file names as bind variables. I can fix this with adding Path.GetDirectoryName around the existing calls to the BundleBuilder.Output, or I could add a read only property to BundleBuilder that does the same.
The WixToolset.Tool.PyroCommandLine doesn't initialize the default values of properties, which cause access violations.
I also ran into a legitimate bug inside of WixToolset.Data.Pdb, the Read method does a comparison that is incorrect
if (!reader.LocalName.Equals("wixPdb" == reader.LocalName))
{
throw new XmlException();
}
>From there, I was haing issue with Pyro not able to create a patch because the Files table was null. When the 4.x refactoring was done, did you do ay manual testing to verify basic functionality? Do you have any docs on the significant refactoring done, or any hints on where to start with the patch generation process failing? (What tool/section of code is responsible for populating the file table which is consumed by pyro?)
P.S. For any of the test to work they rely on bits from my outstanding pull request, as the BindBundleCommand was no longer populating packageLanguage/packageManufacturer.
Thanks,
Jacob
|
|
From: Rob M. <ro...@fi...> - 2015-03-31 17:27:04
|
Unfortunately, not related at all. That is a completely independent feature. Adding grouping things is generally a "harder" problem. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -----Original Message----- From: Phill Hogland [mailto:pho...@ri...] Sent: Tuesday, March 31, 2015 6:14 AM To: wix...@li... Subject: Re: [WiX-devs] Optional command line arguments WIP updated I appreciate this discussion and effort. I hope you don't mind me piointing out a related issue here <http://wixtoolset.org/issues/4531/> . |
|
From: Mike C. <mi...@fi...> - 2015-03-31 16:38:51
|
Does anyone have a better name than "Platform" for this attribute to suggest? Or other comments on the idea in general? From: Mike Carlson [mailto:mi...@fi...] Sent: Tuesday, March 24, 2015 2:04 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute Revising my suggestion, I think it makes sense to allow 64-bit searches as they are allowed today (even if they are officially unsupported by MSI). Agreeing with Sean, I'd also like to only make this change for the CustomAction and Component elements, because it only belongs in elements that cannot support 64-bit from a 32-bit package. The other two elements (ApprovedExeForElevation and util:RegistrySearch) will continue having the same Win64 attribute they have today. I also favor making the new attribute an enum instead of a bool, for clarity of purpose, and also to be clear to users that the new attribute is not simply a renaming of Win64 (and is not simply the inverse of Win64). I'm thinking of an attribute named something like "Platform", with possible values "win32" or "default". I'm sure there's a better name out there than "Platform" - I am very open to suggestions. From: Bob Arnson [mailto:bo...@fi...] Sent: Tuesday, March 24, 2015 11:20 AM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute If we held our breath for explicit confirmation from the MSI SDK, we'd all be zombies. However, I finally found a mention in the ICE80 doc, so I begrudgingly agree with you. :) From: Heath Stewart [mailto:he...@ou...] Sent: Friday, 20 March, 2015 21:31 To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 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...<mailto:bo...@fi...> To: wix...@li...<mailto: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...<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 ------------------------------------------------------------------------------ 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: Phill H. <pho...@ri...> - 2015-03-31 13:13:57
|
I appreciate this discussion and effort. I hope you don't mind me piointing out a related issue here <http://wixtoolset.org/issues/4531/> . -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Optional-command-line-arguments-WIP-updated-tp7599703p7599795.html Sent from the wix-devs mailing list archive at Nabble.com. |
|
From: Bob A. <bo...@fi...> - 2015-03-31 03:43:05
|
That’s phase 2, mostly because I’m still thinking about whether we could have attributes on MsiProperty kinda like {Install|Uninstall|Repair}Argument. Adding just Condition is still a win, though, so I’ll start with that. That comes after ExePackage/CommandLine, however.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Sean Hall [mailto:r.s...@gm...]
Sent: Monday, 30 March, 2015 23:27
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Optional command line arguments WIP updated
I would like to see Condition added to MsiProperty as well. When can we start using this? :)
On Fri, Mar 27, 2015 at 1:53 PM, Bob Arnson <bo...@fi...<mailto:bo...@fi...>> wrote:
You’re both wrong. ☺ I wanted to use WixBundleExecutePackageAction instead of On* attributes so each CommandLine instance was just argument and condition. That said, Rob’s proposed authoring looks awesome. And I think it’s not much more complex than what I was thinking of.
Unless someone objects, I’m going with that (and will update the WIP to match).
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Hoover, Jacob [mailto:Jac...@gr...<mailto:Jac...@gr...>]
Sent: Friday, 27 March, 2015 14:42
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Optional command line arguments WIP updated
The way I read it was
<ExePackage RepairCommand=”” UninstallCommand=”/uninstall”>
<CommandLine OnInstall=”yes” OnRepair=”yes” Conditon=”VarX=1”>/foo /bar</CommandLine>
<CommandLine OnUninstall=”yes” Conditon=”VarY=9”>/notfoo</CommandLine>
</ExePackage>
From: Rob Mensching [mailto:ro...@fi...]
Sent: Friday, March 27, 2015 1:28 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Optional command line arguments WIP updated
I like this. I could really use a couple examples (sorry, “visualizing” changes is easiest way for me to understand)
So you are suggesting the following:
<ExePackage RepairCommand=”” UnisntallCommand=”/uninstall”>
<CommandLine InstallArgument=”/foo /bar” RepairArgument=”/foo /bar” Conditon=”VarX=1” />
<CommandLine UninstallArgument=”/notfoo” Conditon=”VarY=9” />
</ExePackage>
That would match our use of InstallCommand, RepairCommand, UninstallCommand and probably avoid the use of the WixBundleExecutePackageAction 90+% of the time.
If so, I *really* like this.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Bob Arnson [mailto:bo...@fi...]
Sent: Wednesday, March 25, 2015 9:46 AM
To: wix...@li...<mailto:wix...@li...>
Subject: [WiX-devs] Optional command line arguments WIP updated
You can see the diff via pull request at https://github.com/wixtoolset/site/pull/50.
I’m strongly leaning toward the “package action variable.” It’s simple to implement and basically solves the problem adding this functionality to MsiProperty.
Feedback sought and welcomed.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
------------------------------------------------------------------------------
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-31 03:27:37
|
I would like to see Condition added to MsiProperty as well. When can we start using this? :) On Fri, Mar 27, 2015 at 1:53 PM, Bob Arnson <bo...@fi...> wrote: > You’re both wrong. J I wanted to use WixBundleExecutePackageAction > instead of On* attributes so each CommandLine instance was just argument > and condition. That said, Rob’s proposed authoring looks awesome. And I > think it’s not much more complex than what I was thinking of. > > > > Unless someone objects, I’m going with that (and will update the WIP to > match). > > > > _______________________________________________________________ > > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > > > *From:* Hoover, Jacob [mailto:Jac...@gr...] > *Sent:* Friday, 27 March, 2015 14:42 > *To:* WiX toolset developer mailing list > *Subject:* Re: [WiX-devs] Optional command line arguments WIP updated > > > > The way I read it was > > > > <ExePackage RepairCommand=”” UninstallCommand=”/uninstall”> > > <CommandLine OnInstall=”yes” OnRepair=”yes” Conditon=”VarX=1”>/foo > /bar</CommandLine> > > <CommandLine OnUninstall=”yes” > Conditon=”VarY=9”>/notfoo</CommandLine> > > </ExePackage> > > > > > > *From:* Rob Mensching [mailto:ro...@fi... <ro...@fi...>] > *Sent:* Friday, March 27, 2015 1:28 PM > *To:* WiX toolset developer mailing list > *Subject:* Re: [WiX-devs] Optional command line arguments WIP updated > > > > I like this. I could really use a couple examples (sorry, “visualizing” > changes is easiest way for me to understand) > > > > So you are suggesting the following: > > > > <ExePackage RepairCommand=”” UnisntallCommand=”/uninstall”> > > <CommandLine InstallArgument=”/foo /bar” RepairArgument=”/foo > /bar” Conditon=”VarX=1” /> > > <CommandLine UninstallArgument=”/notfoo” Conditon=”VarY=9” /> > > </ExePackage> > > > > That would match our use of InstallCommand, RepairCommand, > UninstallCommand and probably avoid the use of the > WixBundleExecutePackageAction 90+% of the time. > > > > If so, I **really** like this. > > > > _______________________________________________________________ > > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > > > *From:* Bob Arnson [mailto:bo...@fi... <bo...@fi...>] > *Sent:* Wednesday, March 25, 2015 9:46 AM > *To:* wix...@li... > *Subject:* [WiX-devs] Optional command line arguments WIP updated > > > > You can see the diff via pull request at > https://github.com/wixtoolset/site/pull/50. > > > > I’m strongly leaning toward the “package action variable.” It’s simple to > implement and basically solves the problem adding this functionality to > MsiProperty. > > > > Feedback sought and welcomed. > > > > _______________________________________________________________ > > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > > ------------------------------------------------------------------------------ > 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-30 16:46:36
|
Next WiX Online meeting will be: March 31st, 2015 @14:30 PST Agenda items: * Triage ......................................................................................................................................... --> Join Lync Meeting<https://meet.lync.com/firegiant/rob/FCVBBBQ6> Help<http://go.microsoft.com/fwlink/?LinkId=389737> [!OC([1033])!] ......................................................................................................................................... |
|
From: Bob A. <bo...@fi...> - 2015-03-27 18:53:57
|
You're both wrong. :) I wanted to use WixBundleExecutePackageAction instead of On* attributes so each CommandLine instance was just argument and condition. That said, Rob's proposed authoring looks awesome. And I think it's not much more complex than what I was thinking of. Unless someone objects, I'm going with that (and will update the WIP to match). _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Hoover, Jacob [mailto:Jac...@gr...] Sent: Friday, 27 March, 2015 14:42 To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Optional command line arguments WIP updated The way I read it was <ExePackage RepairCommand="" UninstallCommand="/uninstall"> <CommandLine OnInstall="yes" OnRepair="yes" Conditon="VarX=1">/foo /bar</CommandLine> <CommandLine OnUninstall="yes" Conditon="VarY=9">/notfoo</CommandLine> </ExePackage> From: Rob Mensching [mailto:ro...@fi...] Sent: Friday, March 27, 2015 1:28 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Optional command line arguments WIP updated I like this. I could really use a couple examples (sorry, "visualizing" changes is easiest way for me to understand) So you are suggesting the following: <ExePackage RepairCommand="" UnisntallCommand="/uninstall"> <CommandLine InstallArgument="/foo /bar" RepairArgument="/foo /bar" Conditon="VarX=1" /> <CommandLine UninstallArgument="/notfoo" Conditon="VarY=9" /> </ExePackage> That would match our use of InstallCommand, RepairCommand, UninstallCommand and probably avoid the use of the WixBundleExecutePackageAction 90+% of the time. If so, I *really* like this. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Bob Arnson [mailto:bo...@fi...] Sent: Wednesday, March 25, 2015 9:46 AM To: wix...@li...<mailto:wix...@li...> Subject: [WiX-devs] Optional command line arguments WIP updated You can see the diff via pull request at https://github.com/wixtoolset/site/pull/50. I'm strongly leaning toward the "package action variable." It's simple to implement and basically solves the problem adding this functionality to MsiProperty. Feedback sought and welcomed. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ |
|
From: Hoover, J. <Jac...@gr...> - 2015-03-27 18:42:33
|
The way I read it was
<ExePackage RepairCommand="" UninstallCommand="/uninstall">
<CommandLine OnInstall="yes" OnRepair="yes" Conditon="VarX=1">/foo /bar</CommandLine>
<CommandLine OnUninstall="yes" Conditon="VarY=9">/notfoo</CommandLine>
</ExePackage>
From: Rob Mensching [mailto:ro...@fi...]
Sent: Friday, March 27, 2015 1:28 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Optional command line arguments WIP updated
I like this. I could really use a couple examples (sorry, "visualizing" changes is easiest way for me to understand)
So you are suggesting the following:
<ExePackage RepairCommand="" UnisntallCommand="/uninstall">
<CommandLine InstallArgument="/foo /bar" RepairArgument="/foo /bar" Conditon="VarX=1" />
<CommandLine UninstallArgument="/notfoo" Conditon="VarY=9" />
</ExePackage>
That would match our use of InstallCommand, RepairCommand, UninstallCommand and probably avoid the use of the WixBundleExecutePackageAction 90+% of the time.
If so, I *really* like this.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Bob Arnson [mailto:bo...@fi...]
Sent: Wednesday, March 25, 2015 9:46 AM
To: wix...@li...<mailto:wix...@li...>
Subject: [WiX-devs] Optional command line arguments WIP updated
You can see the diff via pull request at https://github.com/wixtoolset/site/pull/50.
I'm strongly leaning toward the "package action variable." It's simple to implement and basically solves the problem adding this functionality to MsiProperty.
Feedback sought and welcomed.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
|
|
From: Rob M. <ro...@fi...> - 2015-03-27 18:27:53
|
I like this. I could really use a couple examples (sorry, "visualizing" changes is easiest way for me to understand)
So you are suggesting the following:
<ExePackage RepairCommand="" UnisntallCommand="/uninstall">
<CommandLine InstallArgument="/foo /bar" RepairArgument="/foo /bar" Conditon="VarX=1" />
<CommandLine UninstallArgument="/notfoo" Conditon="VarY=9" />
</ExePackage>
That would match our use of InstallCommand, RepairCommand, UninstallCommand and probably avoid the use of the WixBundleExecutePackageAction 90+% of the time.
If so, I *really* like this.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Bob Arnson [mailto:bo...@fi...]
Sent: Wednesday, March 25, 2015 9:46 AM
To: wix...@li...
Subject: [WiX-devs] Optional command line arguments WIP updated
You can see the diff via pull request at https://github.com/wixtoolset/site/pull/50.
I'm strongly leaning toward the "package action variable." It's simple to implement and basically solves the problem adding this functionality to MsiProperty.
Feedback sought and welcomed.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
|
|
From: Bob A. <bo...@fi...> - 2015-03-25 16:46:20
|
You can see the diff via pull request at https://github.com/wixtoolset/site/pull/50. I'm strongly leaning toward the "package action variable." It's simple to implement and basically solves the problem adding this functionality to MsiProperty. Feedback sought and welcomed. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ |
|
From: Tunney, S. <Ste...@nu...> - 2015-03-25 15:20:24
|
This can double for en-ca as well :)
Thanks, Thomas for the effort!
-----Original Message-----
From: Thomas Williams [mailto:Tho...@qu...]
Sent: March-25-15 7:08 AM
To: wix...@li...
Subject: [WiX-devs] British English Localisation File
Hi,
I've created a localisation file for a British English installer ('license' has been changed to 'licence', but other than that the file is identical to WixUI_en-us.wxl apart from the copyright note at the very top) and wanted to submit it to be considered to be included in the WiX Toolset.
I have attached a patch (diff between my file and the US equivalent) and claim no rights to the file. I hope this is the right place to send it to, and please feel free to include it (or not). I only ask that I can be updated on the decision.
Cheers,
Thomas
--
----------------------------------------------------------------------
Thomas J. Williams
Undergraduate Placement Student
Quintessa Ltd. Email: Tho...@qu...
The Hub, Phone: +44 (0)1491 630048
14 Station Road, Fax: +44 (0)1491 636247
Henley-On-Thames,
Oxfordshire Web: http://www.quintessa.org
RG9 1AY
----------------------------------------------------------------------
Quintessa Limited. Registered in England Number 3716623.
Registered office: The Hub, 14 Station Road, Henley-on-Thames, Oxfordshire RG9 1AY
|
|
From: Thomas W. <Tho...@qu...> - 2015-03-25 11:08:46
|
Hi,
I've created a localisation file for a British English installer
('license' has been changed to 'licence', but other than that the file
is identical to WixUI_en-us.wxl apart from the copyright note at the
very top) and wanted to submit it to be considered to be included in the
WiX Toolset.
I have attached a patch (diff between my file and the US equivalent) and
claim no rights to the file. I hope this is the right place to send it
to, and please feel free to include it (or not). I only ask that I can
be updated on the decision.
Cheers,
Thomas
--
----------------------------------------------------------------------
Thomas J. Williams
Undergraduate Placement Student
Quintessa Ltd. Email: Tho...@qu...
The Hub, Phone: +44 (0)1491 630048
14 Station Road, Fax: +44 (0)1491 636247
Henley-On-Thames,
Oxfordshire Web: http://www.quintessa.org
RG9 1AY
----------------------------------------------------------------------
Quintessa Limited. Registered in England Number 3716623.
Registered office: The Hub, 14 Station Road, Henley-on-Thames, Oxfordshire RG9 1AY
|
|
From: Mike C. <mi...@fi...> - 2015-03-24 21:04:19
|
Revising my suggestion, I think it makes sense to allow 64-bit searches as they are allowed today (even if they are officially unsupported by MSI). Agreeing with Sean, I'd also like to only make this change for the CustomAction and Component elements, because it only belongs in elements that cannot support 64-bit from a 32-bit package. The other two elements (ApprovedExeForElevation and util:RegistrySearch) will continue having the same Win64 attribute they have today. I also favor making the new attribute an enum instead of a bool, for clarity of purpose, and also to be clear to users that the new attribute is not simply a renaming of Win64 (and is not simply the inverse of Win64). I'm thinking of an attribute named something like "Platform", with possible values "win32" or "default". I'm sure there's a better name out there than "Platform" - I am very open to suggestions. From: Bob Arnson [mailto:bo...@fi...] Sent: Tuesday, March 24, 2015 11:20 AM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute If we held our breath for explicit confirmation from the MSI SDK, we'd all be zombies. However, I finally found a mention in the ICE80 doc, so I begrudgingly agree with you. :) From: Heath Stewart [mailto:he...@ou...] Sent: Friday, 20 March, 2015 21:31 To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 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...<mailto:bo...@fi...> To: wix...@li...<mailto: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...<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 ------------------------------------------------------------------------------ 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: Rob M. <ro...@fi...> - 2015-03-24 18:26:08
|
A single commit? Uhh, that's rarely ideal. It's much better to see logical commits to make it easier to review. Sean had a great example when he did the thmutil updates in v4. In this case, we've already reviewed this so it's less of an issue. You don't need a new pull request. Just update the branch you sent the pull request from and it should be good. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Hoover, Jacob [mailto:Jac...@gr...] Sent: Tuesday, March 24, 2015 11:09 AM To: WiX toolset developer mailing list Subject: [WiX-devs] Pull request Rob, for https://github.com/wixtoolset/wix4/pull/80. I have a squashed branch located at https://github.com/jchoover/wix4/tree/SelfUpdateTesting.v2; I could kill the old pull request and submit the new one so it's a single commit. I think I've addressed all the concerns/feedback that was provided. I've also merged in all changes from upstream, so it should auto-merge for you. Thanks, Jacob |
|
From: Bob A. <bo...@fi...> - 2015-03-24 18:19:45
|
If we held our breath for explicit confirmation from the MSI SDK, we'd all be zombies. However, I finally found a mention in the ICE80 doc, so I begrudgingly agree with you. :) From: Heath Stewart [mailto:he...@ou...] Sent: Friday, 20 March, 2015 21:31 To: WiX toolset developer mailing list Subject: Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute 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...<mailto:bo...@fi...> To: wix...@li...<mailto: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...<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 ------------------------------------------------------------------------------ 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: Hoover, J. <Jac...@gr...> - 2015-03-24 18:09:18
|
Rob, for https://github.com/wixtoolset/wix4/pull/80. I have a squashed branch located at https://github.com/jchoover/wix4/tree/SelfUpdateTesting.v2; I could kill the old pull request and submit the new one so it's a single commit. I think I've addressed all the concerns/feedback that was provided. I've also merged in all changes from upstream, so it should auto-merge for you. Thanks, Jacob |
|
From: Brian R. <rog...@gm...> - 2015-03-24 03:35:43
|
Hey Sean, IIRC it is a set of properties you would like to pass to the MSI in a rollback scenario rather than a plain, no property, uninstall or the install set of properties. This is useful if there are clean up dependencies because everything has been installed (possibly starting/stopping services). I don't believe it is something which is heavily used, but in another life I found the concept valuable. Hope that helps, Brian Brian Rogers "Intelligence removes complexity." - Me http://blogs.msdn.com/icumove On Mon, Mar 23, 2015 at 7:28 PM, Sean Hall <r.s...@gm...> wrote: > I'm starting to work on bug 4630 <http://wixtoolset.org/issues/4630/�> and > I found RollbackValue is supported on MsiProperties in the Burn engine, but > candle and light know nothing about it. Does anyone know anything about > MsiProperty/@RollbackValue? > > > ------------------------------------------------------------------------------ > 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-24 02:28:08
|
I'm starting to work on bug 4630 <http://wixtoolset.org/issues/4630/�> and I found RollbackValue is supported on MsiProperties in the Burn engine, but candle and light know nothing about it. Does anyone know anything about MsiProperty/@RollbackValue? |
|
From: Rob M. <ro...@fi...> - 2015-03-23 20:17:03
|
Next WiX Online meeting will be: March 24th, 2015 @14:30 PST Agenda items: * Triage ......................................................................................................................................... --> Join Lync Meeting<https://meet.lync.com/firegiant/rob/01428JQ4> Help<http://go.microsoft.com/fwlink/?LinkId=389737> [!OC([1033])!] ......................................................................................................................................... |
554 messages has been excluded from this view by a project administrator.
