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-04-28 23:01:07
|
For the time being, I thought I'd share that internally I've added - if set - the layout directory (whether doing a layout or not - seems the BA might want to do something special here) + package path to the rwzSourcePaths array in the CacheVerifyLocalContainerOrPayload() function we check before asking the BA. This works and feels like a good long-term fix unless we do want to consider the layout directory a sort of cache. Heath Stewart Software Engineer Visual Studio, Microsoft http://blogs.msdn.com/heaths From: he...@ou... To: wix...@li... Date: Tue, 28 Apr 2015 15:05:51 -0700 Subject: [WiX-devs] Avoiding re-downloading of payloads I'm looking into fixing http://wixtoolset.org/issues/3060/ (rather, I'm fixing it anyway and was wondering if it already was so may as well pick this up) and have determined a couple different ways but wanted to get architecture guidance (or feedback in general). Mainly, is a layout directory considered a local cache? I'm assuming not, since "cache" also carries some guarantees like that the file is protected (at least in per-machine cases). I ask, because one way is to check if we're doing a layout and, if so, track the layout path as the cache. This will avoid adding cache actions. Similarly, I could add a member to track a layout specifically and avoid adding cache actions, but that blurs the line between cache and layout directory. If we want to disassociate the cache and layout (as they appear to be now), the most straight forward way is to consider the layout directory (if doing a layout, or maybe just query the variable anytime since maybe the BA wants that to be considered regardless of bundle action) in CacheVerifyLocalContainerOrPayload(). We still plan cache actions, but not until before downloading it do we consider whether it's already downloaded. I'm leaning toward this one given that a layout isn't really a cache, but if we want to consider layout as a type of cache than the ideas above make more sense. Thoughts? Heath Stewart Software Engineer Visual Studio, Microsoft http://blogs.msdn.com/heaths ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ WiX-devs mailing list WiX...@li... https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: Heath S. <he...@ou...> - 2015-04-28 22:08:44
|
Re: the comment on http://wixtoolset.org/issues/4432/ Hopefully, but I've been swamped trying to ship VS2015 (mainly RC, so hopefully I'll have time); otherwise, the code is there and just needs to be merged. Sean could finish it if he wants. What's the cut-off for 3.10 to have some idea of time frame? Heath Stewart Software Engineer Visual Studio, Microsoft http://blogs.msdn.com/heaths |
|
From: Heath S. <he...@ou...> - 2015-04-28 22:05:59
|
I'm looking into fixing http://wixtoolset.org/issues/3060/ (rather, I'm fixing it anyway and was wondering if it already was so may as well pick this up) and have determined a couple different ways but wanted to get architecture guidance (or feedback in general). Mainly, is a layout directory considered a local cache? I'm assuming not, since "cache" also carries some guarantees like that the file is protected (at least in per-machine cases). I ask, because one way is to check if we're doing a layout and, if so, track the layout path as the cache. This will avoid adding cache actions. Similarly, I could add a member to track a layout specifically and avoid adding cache actions, but that blurs the line between cache and layout directory. If we want to disassociate the cache and layout (as they appear to be now), the most straight forward way is to consider the layout directory (if doing a layout, or maybe just query the variable anytime since maybe the BA wants that to be considered regardless of bundle action) in CacheVerifyLocalContainerOrPayload(). We still plan cache actions, but not until before downloading it do we consider whether it's already downloaded. I'm leaning toward this one given that a layout isn't really a cache, but if we want to consider layout as a type of cache than the ideas above make more sense. Thoughts? Heath Stewart Software Engineer Visual Studio, Microsoft http://blogs.msdn.com/heaths |
|
From: Rob M. <ro...@fi...> - 2015-04-27 22:02:09
|
Next WiX Online meeting will be: April 28th, 2015 @14:30 PST Agenda items: * Triage ......................................................................................................................................... --> Join Skype Meeting<https://meet.lync.com/firegiant/rob/GH9QJ4VW> Help<http://go.microsoft.com/fwlink/?LinkId=389737> [!OC([1033])!] ......................................................................................................................................... |
|
From: Rob M. <ro...@fi...> - 2015-04-21 04:40:54
|
Next WiX Online meeting will be: April 20th, 2015 @14:30 PST Agenda items: * Triage ......................................................................................................................................... --> Join Skype Meeting<https://meet.lync.com/firegiant/rob/71VK0M3P> Help<http://go.microsoft.com/fwlink/?LinkId=389737> [!OC([1033])!] ......................................................................................................................................... |
|
From: John C. <JoC...@ja...> - 2015-04-15 17:48:02
|
Strongly agreed. Particular when they won’t discuss weaknesses. Every technology has them. When somebody denies a technology has weaknesses, I get really worried and I look very hard to find them. Used to write those scripted tarballs—well I remember. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |JoC...@ja...<mailto:JoC...@ja...> From: Rob Mensching [mailto:ro...@fi...] Sent: Wednesday, April 15, 2015 12:43 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Future coolness (was RE: Windows Nano server) Ahh. Well, that’s possible today with prototype work in Simplified WiX. Now, IMHO, NuGet and nupkg’s as they are today aren’t terribly compelling installation technologies. It’s basically, drop a bunch of files and run a custom PowerShell script. That’s 1980s based-installation technology that brought us all kinds of hell when it “got big” (which none of these NuGet based systems are yet). However, that’s not to say the world won’t keep changing (Innovator’s Dilemma and all that) so I’m staying abreast of the technologies as they change… With that said, we’re in the middle of a very large transition right now. The world is going to get chaotic for a while. It’ll be interesting but don’t let the hipster-programmers tell you that the fundamentals don’t matter. They don’t stick to one project long enough to feel the pain of the systems they built. <smile/> _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Stephen Tunney [mailto:ste...@gm...] Sent: Wednesday, April 15, 2015 10:25 AM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Future coolness (was RE: Windows Nano server) My apologies, With respect to Chocolatey WiX would generate a .nuspec (perhaps) that could do all of the things that MSIs do today (perhaps with some limitation, though I can't think of any). This would allow the WiX xml to generate MSIs, .nuspec, and allow the user to pick their delivery vehicle. Just as a side note, I looked at the Google Chrome chocolatey package, and it is a thin wrapper around... their MSI !! :) On Wed, 15 Apr 2015 at 13:01 Rob Mensching <ro...@fi...<mailto:ro...@fi...>> wrote: Changing title. I don’t understand that question. WiX is a build tool, not an installation engine. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Tunney, Stephen [mailto:Ste...@nu...<mailto:Ste...@nu...>] Sent: Wednesday, April 15, 2015 9:50 AM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server So on the subject of “future coolness”; Are there plans for translating WiX declarative XML into OneGet/Chocolatey/NuGet packages as well? ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF_______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. |
|
From: Rob M. <ro...@fi...> - 2015-04-15 17:43:10
|
Ahh. Well, that’s possible today with prototype work in Simplified WiX. Now, IMHO, NuGet and nupkg’s as they are today aren’t terribly compelling installation technologies. It’s basically, drop a bunch of files and run a custom PowerShell script. That’s 1980s based-installation technology that brought us all kinds of hell when it “got big” (which none of these NuGet based systems are yet). However, that’s not to say the world won’t keep changing (Innovator’s Dilemma and all that) so I’m staying abreast of the technologies as they change… With that said, we’re in the middle of a very large transition right now. The world is going to get chaotic for a while. It’ll be interesting but don’t let the hipster-programmers tell you that the fundamentals don’t matter. They don’t stick to one project long enough to feel the pain of the systems they built. <smile/> _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Stephen Tunney [mailto:ste...@gm...] Sent: Wednesday, April 15, 2015 10:25 AM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Future coolness (was RE: Windows Nano server) My apologies, With respect to Chocolatey WiX would generate a .nuspec (perhaps) that could do all of the things that MSIs do today (perhaps with some limitation, though I can't think of any). This would allow the WiX xml to generate MSIs, .nuspec, and allow the user to pick their delivery vehicle. Just as a side note, I looked at the Google Chrome chocolatey package, and it is a thin wrapper around... their MSI !! :) On Wed, 15 Apr 2015 at 13:01 Rob Mensching <ro...@fi...<mailto:ro...@fi...>> wrote: Changing title. I don’t understand that question. WiX is a build tool, not an installation engine. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Tunney, Stephen [mailto:Ste...@nu...<mailto:Ste...@nu...>] Sent: Wednesday, April 15, 2015 9:50 AM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server So on the subject of “future coolness”; Are there plans for translating WiX declarative XML into OneGet/Chocolatey/NuGet packages as well? ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF_______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: John C. <JoC...@ja...> - 2015-04-15 17:37:38
|
Chocolately was discussed during the MVA session I attended (with much enthusiasm). Basically, it provides a NuGet derived wrapper around an APPX to get some of the functionality (particularly dependency resolution) that APPX won’t give you by itself. So, if I can make an APPX with Wix tools, I can easily wrap it in Chocolately. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |JoC...@ja...<mailto:JoC...@ja...> From: Stephen Tunney [mailto:ste...@gm...] Sent: Wednesday, April 15, 2015 12:25 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Future coolness (was RE: Windows Nano server) My apologies, With respect to Chocolatey WiX would generate a .nuspec (perhaps) that could do all of the things that MSIs do today (perhaps with some limitation, though I can't think of any). This would allow the WiX xml to generate MSIs, .nuspec, and allow the user to pick their delivery vehicle. Just as a side note, I looked at the Google Chrome chocolatey package, and it is a thin wrapper around... their MSI !! :) On Wed, 15 Apr 2015 at 13:01 Rob Mensching <ro...@fi...<mailto:ro...@fi...>> wrote: Changing title. I don’t understand that question. WiX is a build tool, not an installation engine. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Tunney, Stephen [mailto:Ste...@nu...<mailto:Ste...@nu...>] Sent: Wednesday, April 15, 2015 9:50 AM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server So on the subject of “future coolness”; Are there plans for translating WiX declarative XML into OneGet/Chocolatey/NuGet packages as well? ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF_______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. |
|
From: Stephen T. <ste...@gm...> - 2015-04-15 17:24:56
|
My apologies, With respect to Chocolatey WiX would generate a .nuspec (perhaps) that could do all of the things that MSIs do today (perhaps with some limitation, though I can't think of any). This would allow the WiX xml to generate MSIs, .nuspec, and allow the user to pick their delivery vehicle. Just as a side note, I looked at the Google Chrome chocolatey package, and it is a thin wrapper around... their MSI !! :) On Wed, 15 Apr 2015 at 13:01 Rob Mensching <ro...@fi...> wrote: > Changing title. > > > > I don’t understand that question. WiX is a build tool, not an installation > engine. > > > > _______________________________________________________________ > > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > > > *From:* Tunney, Stephen [mailto:Ste...@nu...] > *Sent:* Wednesday, April 15, 2015 9:50 AM > *To:* WiX toolset developer mailing list > *Subject:* Re: [WiX-devs] Windows Nano server > > > > So on the subject of “future coolness”; > > > > Are there plans for translating WiX declarative XML into > OneGet/Chocolatey/NuGet packages as well? > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF_______________________________________________ > WiX-devs mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-devs > |
|
From: Sean H. <r.s...@gm...> - 2015-04-15 17:01:14
|
Nuget packages are in v4.0 already. https://github.com/wixtoolset/wix4/pull/5 On Wed, Apr 15, 2015 at 11:49 AM, Tunney, Stephen <Ste...@nu... > wrote: > So on the subject of “future coolness”; > > > > Are there plans for translating WiX declarative XML into > OneGet/Chocolatey/NuGet packages as well? > > > > *From:* Rob Mensching [mailto:ro...@fi...] > *Sent:* April-15-15 11:56 AM > *To:* WiX toolset developer mailing list > *Subject:* Re: [WiX-devs] Windows Nano server > > > > Good, that’s already been written (although may need updating for Win10). > Much more work to do in the space, of course. > > > > _______________________________________________________________ > > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > > > *From:* John Cooper [mailto:JoC...@ja... > <JoC...@ja...>] > *Sent:* Wednesday, April 15, 2015 5:48 AM > *To:* WiX toolset developer mailing list > *Subject:* Re: [WiX-devs] Windows Nano server > > > > I would absolutely LOVE an XML-driven replacement for MakeAppx.exe. > Besides the non-declarative model, the thing won’t run on Server OS’s—only > Windows 8.1—which makes it worthless on my build servers. > > > > -- > > *John Merryweather Cooper* > > Senior Software Engineer | Integration Development Group | Continuing > Development > > Jack Henry & Associates, Inc.*® *| Lenexa, KS 66214 | Ext: 431050 |*JoC...@ja... > <JoC...@ja...>* > > > > > > > > *From:* Rob Mensching [mailto:ro...@fi... <ro...@fi...>] > *Sent:* Tuesday, April 14, 2015 4:54 PM > *To:* WiX toolset developer mailing list > *Subject:* Re: [WiX-devs] Windows Nano server > > > > And WiX will build those things as appropriate. <smile/> > > > > _______________________________________________________________ > > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > > > *From:* John Cooper [mailto:JoC...@ja... > <JoC...@ja...>] > *Sent:* Tuesday, April 14, 2015 2:28 PM > *To:* WiX toolset developer mailing list > *Subject:* Re: [WiX-devs] Windows Nano server > > > > The word at Microsoft is packages. APPX, APK, and WebDeploy. All fine > and dandy, and they work well enough in a limited set of circumstances. > > > > Of course, when I ask the MVP instructors to discuss the disadvantages of > packages, they seemingly can’t come up with any. > > > > Experience teaches otherwise. > > > > -- > > *John Merryweather Cooper* > > Senior Software Engineer | Integration Development Group | Continuing > Development > > Jack Henry & Associates, Inc.*® *| Lenexa, KS 66214 | Ext: 431050 |*JoC...@ja... > <JoC...@ja...>* > > > > > > > > *From:* Hoover, Jacob [mailto:Jac...@gr... > <Jac...@gr...>] > *Sent:* Tuesday, April 14, 2015 4:19 PM > *To:* WiX toolset developer mailing list > *Subject:* [WiX-devs] Windows Nano server > > > > From > http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx > > > > “To achieve these benefits, we removed the GUI stack, 32 bit support > (WOW64), *MSI* and a number of default Server Core components.” > > > > Guess we won’t have to worry about nano compatibility… > > > > Thanks, > > Jacob > > > > NOTICE: This electronic mail message and any files transmitted with it are > intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or privileged > information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, please > immediately advise the sender by reply email and delete all copies. > > NOTICE: This electronic mail message and any files transmitted with it are > intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or privileged > information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, please > immediately advise the sender by reply email and delete all copies. > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > WiX-devs mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-devs > > |
|
From: Rob M. <ro...@fi...> - 2015-04-15 17:00:44
|
Changing title. I don't understand that question. WiX is a build tool, not an installation engine. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Tunney, Stephen [mailto:Ste...@nu...] Sent: Wednesday, April 15, 2015 9:50 AM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server So on the subject of "future coolness"; Are there plans for translating WiX declarative XML into OneGet/Chocolatey/NuGet packages as well? |
|
From: Tunney, S. <Ste...@nu...> - 2015-04-15 16:49:45
|
So on the subject of "future coolness"; Are there plans for translating WiX declarative XML into OneGet/Chocolatey/NuGet packages as well? From: Rob Mensching [mailto:ro...@fi...] Sent: April-15-15 11:56 AM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server Good, that's already been written (although may need updating for Win10). Much more work to do in the space, of course. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: John Cooper [mailto:JoC...@ja...] Sent: Wednesday, April 15, 2015 5:48 AM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server I would absolutely LOVE an XML-driven replacement for MakeAppx.exe. Besides the non-declarative model, the thing won't run on Server OS's-only Windows 8.1-which makes it worthless on my build servers. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoC...@ja...<mailto:JoC...@ja...> From: Rob Mensching [mailto:ro...@fi...] Sent: Tuesday, April 14, 2015 4:54 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server And WiX will build those things as appropriate. <smile/> _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: John Cooper [mailto:JoC...@ja...] Sent: Tuesday, April 14, 2015 2:28 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server The word at Microsoft is packages. APPX, APK, and WebDeploy. All fine and dandy, and they work well enough in a limited set of circumstances. Of course, when I ask the MVP instructors to discuss the disadvantages of packages, they seemingly can't come up with any. Experience teaches otherwise. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoC...@ja...<mailto:JoC...@ja...> From: Hoover, Jacob [mailto:Jac...@gr...] Sent: Tuesday, April 14, 2015 4:19 PM To: WiX toolset developer mailing list Subject: [WiX-devs] Windows Nano server >From http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx "To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components." Guess we won't have to worry about nano compatibility... Thanks, Jacob NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. |
|
From: Rob M. <ro...@fi...> - 2015-04-15 15:55:53
|
Good, that's already been written (although may need updating for Win10). Much more work to do in the space, of course. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: John Cooper [mailto:JoC...@ja...] Sent: Wednesday, April 15, 2015 5:48 AM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server I would absolutely LOVE an XML-driven replacement for MakeAppx.exe. Besides the non-declarative model, the thing won't run on Server OS's-only Windows 8.1-which makes it worthless on my build servers. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoC...@ja...<mailto:JoC...@ja...> From: Rob Mensching [mailto:ro...@fi...] Sent: Tuesday, April 14, 2015 4:54 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server And WiX will build those things as appropriate. <smile/> _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: John Cooper [mailto:JoC...@ja...] Sent: Tuesday, April 14, 2015 2:28 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server The word at Microsoft is packages. APPX, APK, and WebDeploy. All fine and dandy, and they work well enough in a limited set of circumstances. Of course, when I ask the MVP instructors to discuss the disadvantages of packages, they seemingly can't come up with any. Experience teaches otherwise. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoC...@ja...<mailto:JoC...@ja...> From: Hoover, Jacob [mailto:Jac...@gr...] Sent: Tuesday, April 14, 2015 4:19 PM To: WiX toolset developer mailing list Subject: [WiX-devs] Windows Nano server >From http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx "To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components." Guess we won't have to worry about nano compatibility... Thanks, Jacob NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. |
|
From: John C. <JoC...@ja...> - 2015-04-15 12:48:17
|
I would absolutely LOVE an XML-driven replacement for MakeAppx.exe. Besides the non-declarative model, the thing won't run on Server OS's-only Windows 8.1-which makes it worthless on my build servers. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoC...@ja...<mailto:JoC...@ja...> From: Rob Mensching [mailto:ro...@fi...] Sent: Tuesday, April 14, 2015 4:54 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server And WiX will build those things as appropriate. <smile/> _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: John Cooper [mailto:JoC...@ja...] Sent: Tuesday, April 14, 2015 2:28 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server The word at Microsoft is packages. APPX, APK, and WebDeploy. All fine and dandy, and they work well enough in a limited set of circumstances. Of course, when I ask the MVP instructors to discuss the disadvantages of packages, they seemingly can't come up with any. Experience teaches otherwise. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoC...@ja...<mailto:JoC...@ja...> From: Hoover, Jacob [mailto:Jac...@gr...] Sent: Tuesday, April 14, 2015 4:19 PM To: WiX toolset developer mailing list Subject: [WiX-devs] Windows Nano server >From http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx "To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components." Guess we won't have to worry about nano compatibility... Thanks, Jacob NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. |
|
From: Rob M. <ro...@fi...> - 2015-04-14 21:58:12
|
Note: in the end it's all packages. The question is what format and what engine drives it. It's still doing all the same things ultimately. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Rob Mensching Sent: Tuesday, April 14, 2015 2:54 PM To: WiX toolset developer mailing list Subject: RE: Windows Nano server And WiX will build those things as appropriate. <smile/> _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: John Cooper [mailto:JoC...@ja...] Sent: Tuesday, April 14, 2015 2:28 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server The word at Microsoft is packages. APPX, APK, and WebDeploy. All fine and dandy, and they work well enough in a limited set of circumstances. Of course, when I ask the MVP instructors to discuss the disadvantages of packages, they seemingly can't come up with any. Experience teaches otherwise. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoC...@ja...<mailto:JoC...@ja...> From: Hoover, Jacob [mailto:Jac...@gr...] Sent: Tuesday, April 14, 2015 4:19 PM To: WiX toolset developer mailing list Subject: [WiX-devs] Windows Nano server >From http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx "To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components." Guess we won't have to worry about nano compatibility... Thanks, Jacob NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. |
|
From: Rob M. <ro...@fi...> - 2015-04-14 21:53:51
|
And WiX will build those things as appropriate. <smile/> _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: John Cooper [mailto:JoC...@ja...] Sent: Tuesday, April 14, 2015 2:28 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Windows Nano server The word at Microsoft is packages. APPX, APK, and WebDeploy. All fine and dandy, and they work well enough in a limited set of circumstances. Of course, when I ask the MVP instructors to discuss the disadvantages of packages, they seemingly can't come up with any. Experience teaches otherwise. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoC...@ja...<mailto:JoC...@ja...> From: Hoover, Jacob [mailto:Jac...@gr...] Sent: Tuesday, April 14, 2015 4:19 PM To: WiX toolset developer mailing list Subject: [WiX-devs] Windows Nano server >From http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx "To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components." Guess we won't have to worry about nano compatibility... Thanks, Jacob NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. |
|
From: John C. <JoC...@ja...> - 2015-04-14 21:27:46
|
The word at Microsoft is packages. APPX, APK, and WebDeploy. All fine and dandy, and they work well enough in a limited set of circumstances. Of course, when I ask the MVP instructors to discuss the disadvantages of packages, they seemingly can't come up with any. Experience teaches otherwise. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Continuing Development Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoC...@ja...<mailto:JoC...@ja...> From: Hoover, Jacob [mailto:Jac...@gr...] Sent: Tuesday, April 14, 2015 4:19 PM To: WiX toolset developer mailing list Subject: [WiX-devs] Windows Nano server >From http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx "To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components." Guess we won't have to worry about nano compatibility... Thanks, Jacob NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. |
|
From: Hoover, J. <Jac...@gr...> - 2015-04-14 21:18:47
|
>From http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx "To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components." Guess we won't have to worry about nano compatibility... Thanks, Jacob |
|
From: Hoover, J. <Jac...@gr...> - 2015-04-14 05:19:31
|
100% untested but something along the lines of https://github.com/jchoover/wix3/tree/WIXBUG4512.1? /// <summary> /// The states of detection. /// </summary> public enum DetectionState { Absent, Present, Newer, } /// <summary> /// The states of installation. /// </summary> public enum InstallationState { Initializing, Detecting, Waiting, Planning, Applying, Applied, Failed, } ________________________________ From: Sean Hall [r.s...@gm...] Sent: Monday, April 13, 2015 9:44 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of Install button while update check is running It will if you add a Waiting value in Installation state, and change it from this.uninstallCommand = new RelayCommand(param => WixBA.Plan(LaunchAction.Uninstall), param => this.root.State == InstallationState.DetectedPresent); to this.uninstallCommand = new RelayCommand(param => WixBA.Plan(LaunchAction.Uninstall), param => this.root.State == InstallationState.Waiting && this.root.DetectedState == DetectionState.Present); On Mon, Apr 13, 2015 at 9:31 PM, Hoover, Jacob <Jac...@gr...<mailto:Jac...@gr...>> wrote: But that still won't fix the issue of the detected state being set in DetectBegin instead of DetectComplete. ________________________________ From: Sean Hall [r.s...@gm...<mailto:r.s...@gm...>] Sent: Monday, April 13, 2015 9:25 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of Install button while update check is running I would move the Detected* values in the InstallationState enum into a new DetectedState enum. That way the InstallationState refers to the state of the BA, and the DetectedState refers to the state of the Bundle. On Mon, Apr 13, 2015 at 9:06 PM, Hoover, Jacob <Jac...@gr...<mailto:Jac...@gr...>> wrote: I could create a named event, and use it to sync... But I fear I'm going way overboard for a "simple" fix. ________________________________ From: Sean Hall [r.s...@gm...<mailto:r.s...@gm...>] Sent: Monday, April 13, 2015 9:02 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of Install button while update check is running It's close, but it needs to be able to prevent clicking on the Uninstall button and then the Repair button. Since the action doesn't even happen until after the update check, I'm not sure if the user should even be able to click Install/Uninstall/Repair until it's finished. On Mon, Apr 13, 2015 at 3:18 AM, Hoover, Jacob <Jac...@gr...<mailto:Jac...@gr...>> wrote: 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...<mailto: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 ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: Sean H. <r.s...@gm...> - 2015-04-14 02:44:32
|
It will if you add a Waiting value in Installation state, and change it from this.uninstallCommand = new RelayCommand(param => WixBA.Plan(LaunchAction.Uninstall), param => this.root.State == InstallationState.DetectedPresent); to this.uninstallCommand = new RelayCommand(param => WixBA.Plan(LaunchAction.Uninstall), param => this.root.State == InstallationState.Waiting && this.root.DetectedState == DetectionState.Present); On Mon, Apr 13, 2015 at 9:31 PM, Hoover, Jacob <Jac...@gr...> wrote: > But that still won't fix the issue of the detected state being set in > DetectBegin instead of DetectComplete. > > > > > ------------------------------ > *From:* Sean Hall [r.s...@gm...] > *Sent:* Monday, April 13, 2015 9:25 PM > *To:* WiX toolset developer mailing list > *Subject:* Re: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of > Install button while update check is running > > I would move the Detected* values in the InstallationState enum into a > new DetectedState enum. That way the InstallationState refers to the state > of the BA, and the DetectedState refers to the state of the Bundle. > > On Mon, Apr 13, 2015 at 9:06 PM, Hoover, Jacob <Jac...@gr... > > wrote: > >> I could create a named event, and use it to sync... But I fear I'm >> going way overboard for a "simple" fix. >> >> >> ------------------------------ >> *From:* Sean Hall [r.s...@gm...] >> *Sent:* Monday, April 13, 2015 9:02 PM >> *To:* WiX toolset developer mailing list >> *Subject:* Re: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of >> Install button while update check is running >> >> It's close, but it needs to be able to prevent clicking on the >> Uninstall button and then the Repair button. Since the action doesn't even >> happen until after the update check, I'm not sure if the user should even >> be able to click Install/Uninstall/Repair until it's finished. >> >> On Mon, Apr 13, 2015 at 3:18 AM, Hoover, Jacob < >> Jac...@gr...> wrote: >> >>> 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 >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>> Develop your own process in accordance with the BPMN 2 standard >>> Learn Process modeling best practices with Bonita BPM through live >>> exercises >>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>> event?utm_ >>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>> _______________________________________________ >>> WiX-devs mailing list >>> WiX...@li... >>> https://lists.sourceforge.net/lists/listinfo/wix-devs >>> >>> >> >> >> ------------------------------------------------------------------------------ >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >> Develop your own process in accordance with the BPMN 2 standard >> Learn Process modeling best practices with Bonita BPM through live >> exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >> event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >> _______________________________________________ >> WiX-devs mailing list >> WiX...@li... >> https://lists.sourceforge.net/lists/listinfo/wix-devs >> >> > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > WiX-devs mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-devs > > |
|
From: Hoover, J. <Jac...@gr...> - 2015-04-14 02:32:12
|
But that still won't fix the issue of the detected state being set in DetectBegin instead of DetectComplete. ________________________________ From: Sean Hall [r.s...@gm...] Sent: Monday, April 13, 2015 9:25 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of Install button while update check is running I would move the Detected* values in the InstallationState enum into a new DetectedState enum. That way the InstallationState refers to the state of the BA, and the DetectedState refers to the state of the Bundle. On Mon, Apr 13, 2015 at 9:06 PM, Hoover, Jacob <Jac...@gr...<mailto:Jac...@gr...>> wrote: I could create a named event, and use it to sync... But I fear I'm going way overboard for a "simple" fix. ________________________________ From: Sean Hall [r.s...@gm...<mailto:r.s...@gm...>] Sent: Monday, April 13, 2015 9:02 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of Install button while update check is running It's close, but it needs to be able to prevent clicking on the Uninstall button and then the Repair button. Since the action doesn't even happen until after the update check, I'm not sure if the user should even be able to click Install/Uninstall/Repair until it's finished. On Mon, Apr 13, 2015 at 3:18 AM, Hoover, Jacob <Jac...@gr...<mailto:Jac...@gr...>> wrote: 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...<mailto: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 ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: Sean H. <r.s...@gm...> - 2015-04-14 02:25:53
|
I would move the Detected* values in the InstallationState enum into a new DetectedState enum. That way the InstallationState refers to the state of the BA, and the DetectedState refers to the state of the Bundle. On Mon, Apr 13, 2015 at 9:06 PM, Hoover, Jacob <Jac...@gr...> wrote: > I could create a named event, and use it to sync... But I fear I'm going > way overboard for a "simple" fix. > > > ------------------------------ > *From:* Sean Hall [r.s...@gm...] > *Sent:* Monday, April 13, 2015 9:02 PM > *To:* WiX toolset developer mailing list > *Subject:* Re: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of > Install button while update check is running > > It's close, but it needs to be able to prevent clicking on the > Uninstall button and then the Repair button. Since the action doesn't even > happen until after the update check, I'm not sure if the user should even > be able to click Install/Uninstall/Repair until it's finished. > > On Mon, Apr 13, 2015 at 3:18 AM, Hoover, Jacob <Jac...@gr... > > wrote: > >> 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 >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >> Develop your own process in accordance with the BPMN 2 standard >> Learn Process modeling best practices with Bonita BPM through live >> exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >> event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >> _______________________________________________ >> WiX-devs mailing list >> WiX...@li... >> https://lists.sourceforge.net/lists/listinfo/wix-devs >> >> > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > WiX-devs mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-devs > > |
|
From: Hoover, J. <Jac...@gr...> - 2015-04-14 02:06:20
|
I could create a named event, and use it to sync... But I fear I'm going way overboard for a "simple" fix. ________________________________ From: Sean Hall [r.s...@gm...] Sent: Monday, April 13, 2015 9:02 PM To: WiX toolset developer mailing list Subject: Re: [WiX-devs] Issue 4512: WiX BA allows multiple clicks of Install button while update check is running It's close, but it needs to be able to prevent clicking on the Uninstall button and then the Repair button. Since the action doesn't even happen until after the update check, I'm not sure if the user should even be able to click Install/Uninstall/Repair until it's finished. On Mon, Apr 13, 2015 at 3:18 AM, Hoover, Jacob <Jac...@gr...<mailto:Jac...@gr...>> wrote: 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...<mailto: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 ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ WiX-devs mailing list WiX...@li...<mailto:WiX...@li...> https://lists.sourceforge.net/lists/listinfo/wix-devs |
|
From: Sean H. <r.s...@gm...> - 2015-04-14 02:03:07
|
It's close, but it needs to be able to prevent clicking on the Uninstall button and then the Repair button. Since the action doesn't even happen until after the update check, I'm not sure if the user should even be able to click Install/Uninstall/Repair until it's finished. On Mon, Apr 13, 2015 at 3:18 AM, Hoover, Jacob <Jac...@gr...> wrote: > 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 > > > > > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > WiX-devs mailing list > WiX...@li... > https://lists.sourceforge.net/lists/listinfo/wix-devs > > |
|
From: Rob M. <ro...@fi...> - 2015-04-13 22:41:27
|
Next WiX Online meeting will be: April 14th, 2015 @14:30 PST Agenda items: * Triage ......................................................................................................................................... --> Join Lync Meeting<https://meet.lync.com/firegiant/rob/V56WS45W> Help<http://go.microsoft.com/fwlink/?LinkId=389737> [!OC([1033])!] ......................................................................................................................................... |
554 messages has been excluded from this view by a project administrator.
