This mailing list address is very dead. See the correct locations for the
mailing lists at: http://wixtoolset.org/documentation/
Regards,
Rob Mensching
CEO
FireGiant
___
FireGiant | Dedicated support for the WiX toolset
This mailing list is deprecated. Please see:
http://wixtoolset.org/documentation/ for updated list of mailing lists.
From: Manimala Kottha [mailto:manimala.kot...@gmail.com]
Sent: Tuesday, December 26, 2017 11:23 PM
To: wix-devs@lists.sourceforge.net
Subject: [wix-devs] (deprecated) Need help in
This mailing list has moved. Please sign up for the
wix-d...@lists.wixtoolset.org mailing list.
More information can be found here:
https://www.firegiant.com/blog/2015/7/21/new-wix-mailing-lists/
--
_
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
This is just work (mostly build system work at that). It should be done. Just
need someone to step up.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Blair Murri [mailto:os...@live.com]
Sen
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
We've known this has been coming and waiting for it to hit priority. A 64-bit
Burn will be needed as well.
Probably something for someone to do for v4.0 and, probably, v3.11.
It isn't as easy as just building 64-bit DLLs.
___
FireGiant
Try uninstalling Sandcastle and make sure all of its environment variables are
removed from your build cmd prompt.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: John Cooper [mailto:jocoo...
You can submit pull requests against wix3/develop. That will become v3.11 after
v3.10 moves to master.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Heath Stewart [mailto:heath.stew...@micr
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
1. If we were to add something to the frontmatter it'd probably be better
to actually put the WiX release instead of just "completed". The current
process means don't have to go back and update documents again... but
2. Could do that. How many documents are there?
Ahh, yes. Sorry, known MPF issue. I have a bad habit of whacking the Project
metadata from project references even though MPF based projects require it...
because... well, MPF bugs me.
___
FireGiant | Dedicated support for the WiX to
I'd let Bob speak to v3.x but totally reasonable for v4.x. Not sure separate
extension is the way to go or if it should get dumped in with all the Util
stuff... but either way, seems more than reasonable.
___
FireGiant | Dedicated sup
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
now.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Friday, May 29, 2015 1:54 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs
No, not known issue. We’ll investigate. Thanks.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Mat Barrie [terrafinity] [mailto:mat.bar...@terrafinity.com.au]
Sent: Thursday, May 28, 2015 11:
Monday was a holiday and Bob is out today so we'll just pick it up next week.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
1. Can we actually unit test much by hooking just ::MsiProcessMessage()?
If so, cool.
2. Instead of checking in a binary MSI + external UI handler, we can just
build them.
___
FireGiant | Dedicated support for the WiX too
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
This is a short week for me (travel Thursday) and I'm a bit squished. So no
meeting this week. We'll get to all the bugs next week.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
8, 2015 at 8:23 PM, Rob Mensching
mailto:r...@firegiant.com>> wrote:
Adding a package’s “Package Cache” location as a source seems completely
reasonable.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.fire
Adding a package's "Package Cache" location as a source seems completely
reasonable.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Heath Stewart [mailto:hea...@outlook.com]
Sent: Tuesday, A
Quick answer: Layout is not a cache. It's not trusted or anything like that.
Burn will verify the bits later.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Heath Stewart [mailto:hea...@outl
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
er 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
mailto:r...@firegiant.com>> wrote:
Changing title.
I don’t understand that questio
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:stephen.tun...@nuan
;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
|jocoo...@jackhenry.com<mailto:jocoo...@jackh
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.
___
FireGiant | Dedicated support for the WiX toolset
And WiX will build those things as appropriate.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Tuesday, April 14, 2015 2:28 PM
To: WiX tools
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
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 M
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
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:
That would match our use of InstallCommand, RepairCommand, UninstallCommand and
probably avoid the use of the WixB
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
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
64 works for Burn, I'd have to think about whether
there's a better name.
On Fri, Mar 20, 2015 at 4:53 PM, Rob Mensching
mailto:r...@firegiant.com>> wrote:
What if we had 64-bit Burn that was affected by -arch switch?
Ultimately, I think I agree with you. Thus my point in #3 whe
n and util:RegistrySearch in
Burn. These aren't going to be affected by the -arch switch, so it doesn't
make sense to me to have "force" or "always" in the name.
On Fri, Mar 20, 2015 at 4:21 PM, Rob Mensching
mailto:r...@firegiant.com>> wrote:
1. I don’t understand
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
100% agree with this position.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Sean Hall [mailto:r.sean.h...@gmail.com]
Sent: Sunday, March 1, 2015 12:53 PM
To: WiX toolset developer mailing l
I expect it’s by design since pulling the source out from under an MSI that was
delivered by a bundle leaves the user in a bad place if they ever need the
source again.
Of course, it almost guarantees the MSI source is “leaked” in the cache.
There is no great answer here (unless we started teac
n Tue, Mar 17, 2015 at 1:01 PM, Rob Mensching
mailto:r...@firegiant.com>> wrote:
Yep. Outstanding task.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Brian Rogers
[mailto:rogers
Yep. Outstanding task.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Brian Rogers [mailto:rogers.br...@gmail.com]
Sent: Tuesday, March 17, 2015 12:58 PM
To: Windows Installer XML toolset de
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
I can totally see that line of thinking but LAYOUT is actually an outlier, just
like HELP. Honestly, if I could do it again, I wouldn’t add LAYOUT to the
command-line either and make it more like what I imagined CACHE to be.
So, ignore LAYOUT then the states a package can move through from “less
Why? Won’t “additional command-line arguments” be appended so that whatever was
called “CACHE” on the command line (/cache or /store or /whateverBAchooses)
would get put back on there? Or am I not remembering the code correctly?
___
Fi
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
This is a short week for me. I fly out for SJC early Wednesday morning. So no
meeting this week. We'll be back on the week after. Then off again the last
week of February.
Talk to you all next week!
___
FireGiant | Dedicated support
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
seen this validation where only specific
words are allowed.
E.g. registry extension doesn't check the parameters.
Also the current firewall port code doesn't check if the number is between 1
and 65535.
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Sunday, January 4, 2015 02:5
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
Agreed except there would need to be something really compelling in .NET v4.5
for us to move there. It seems .NET v4.0 serves us just fine.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Ori
Got it thanks.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Sean Hall [mailto:r.sean.h...@gmail.com]
Sent: Thursday, January 22, 2015 10:43 AM
To: WiX toolset developer mailing list
Subject
, Rob Mensching
mailto:r...@firegiant.com>> wrote:
An hour earlier won’t help much. It’d have to be probably 3 hours earlier (6:00
AM PST) to have any hope of not being interrupted by life here.
However, it seems like many are interested in taking it back an hour (10:00 AM
PST). That’s the t
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
Isn't this what we're discussing? Different ways to solve the patching problem?
I totally agree we haven't hit consensus. We've worked our way to a big
question, the "higher level model" in Bob's words, of how to make patching
really work, instead of the disconnected set of tools we use today. I
Honestly, the way the numbers are going… I don’t know when we drop support for
XP SP3.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Sean Hall [mailto:r.sean.h...@gmail.com]
Sent: Tuesday,
extract files from the Binary table
for patching
On 19-Jan-15 16:13, Rob Mensching wrote:
> I'm really not at all excited about *another* tool in v4.
Why do we have Light and Lit? :)
> I guess that's where I'd like to see this in v4 (or later if it can't make
> v4):
ching which is what we want to get away from.
Stephen
On Mon, 19 Jan 2015 16:14 Rob Mensching
mailto:r...@firegiant.com>> wrote:
I'm really not at all excited about *another* tool in v4. I'd much rather we be
able to use the MSI and the cabs as the source without having to pr
I'm really not at all excited about *another* tool in v4. I'd much rather we be
able to use the MSI and the cabs as the source without having to preprocess
them. Maybe melt.exe keeps the functionality or maybe dark.exe is the best
place for it but you only use it to optimize the process. Otherwi
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Monday, January 19, 2015 7:44 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WiX Online Meeting time in 2015?
An hour earlier or later would be fine by me (if that helps at all).
From: Rob Mensching [mailto:r...@firegia
Greetings,
Last year our weekly meeting was regularly scheduled at 9:00 AM PST on
Thursdays. Due to changes in life, 9:00 AM PST is turning out to be very
challenging for me to attend regularly. Thus I'd like to move the meeting time
to another timeslot.
Of course, no time slot can be perfect
Sorry, still adjusting to newborn at home. No meeting this week. Hopefully,
back on track next week.
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with
rom: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
Sent: Wednesday, January 7, 2015 3:08 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] WiX Online Meeting #52
2015-01-07 19:58 GMT-03:00 Rob Mensching :
> Happy New Year!
>
> Next WiX Online meeting will be: December 8th, 2014 @1
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
Okay. How did you resolve the issue?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Stephen Tunney [mailto:stephen.tun...@gmail.com]
Sent: Sunday, January 4, 2015 6:32 AM
To: WiX toolset deve
519-880-7463 Office
NUANCE.COM
The experience speaks for itself (tm)
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: December-05-14 12:25 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Building WiX 3.9
Adding /pTargetFramework probably will really confu
Left my one comment. Is there really no validation of the port list required?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Norbert Schulze [mailto:norbert-schu...@online.de]
Sent: Thursday,
1. Is there real value putting the method in DTF if only Melt uses it?
2. I agree with you and Bob about not breaking WiX v3.
3. Do we need the “-sextract” (what kind of tract?) in v4? Can’t we just
do what it does and not bother with suppression? Or is suppression a *really*
-level folder for
consistency?
Stephen Tunney
Nuance Communications, Inc.
Solutions Architect, Imaging Division
Waterloo, Ontario, Canada
stephen.tun...@nuance.com<mailto:stephen.tun...@nuance.com>
519-880-7463 Office
NUANCE.COM
The experience speaks for itself (tm)
From: Rob Mensching [mailt
"wix#" seems quite reasonable. Things should be backwards compatible on major
version so we shouldn't need minor version. If we do, I suppose we could add
that later.
PS: I suppose there might be changes necessary to Votive as well but wouldn't
know much about that myself. Something to keep in
1. What does dark.exe do?
2. I'd do what dark.exe does.
3. Need more information about why you need a new method.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Tunney, St
Yeah, this was discussed here and there before. I think it came down to someone
just needs to do the work in NuGet.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Heath Stewart [mailto:hea..
Phill, no worries. Everyone has to learn. IMHABO, the WiX toolset is a great
place to learn because it is a non-trivial project that can really help a dev
grow in lots of different directions. Just keep with it.
___
FireGiant | Dedi
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
Yeah, I was always leaning that way as well. However, I didn't think really
hard if there was ever a case you'd want them separated. Anyone have scenarios
where you'd need a RestartBoundary without a RollbackBoundary?
___
FireGiant |
Adding /pTargetFramework probably will really confuse things. Some tools must
target older frameworks.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Tunney, Stephen [mailto:stephen.tun...@n
Jacob, that's VS2013's location for MSBuild. It moved.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Friday, December 5, 2014 7:35 AM
If you have all the VS's installed remove the "/p:PlatformToolset=v120_xp".
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Tunney, Stephen [mailto:stephen.tun...@nuance.com]
Sent: Friday, Dec
on my pull
request<https://github.com/wixtoolset/wix3/pull/181>: the scenario where the
source is encrypted but the target is not encrypted can't happen in the current
code. And I don't see a valid use case for it either. More comments are
always good, though :). I'
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02000
For general usage questions, please contact wix-users mailing list.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
From: Neginina Javan [mailto:negin...@gmail.com]
Sent: Thursday, November 27, 2014 4:21 AM
Was a bug opened tracking this issue (if it is real)?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Thursday, November 6, 2014 1:38 PM
ubject: Re: [WiX-devs] Wix4: Unit testing
Part of it was my missing the Command where the code was migrated to, the other
part was there are 2 lines commented out which are bugs. Is there a WIP for the
refactoring you did I could dig into, so I could better understand the intent
of the change?
Fro
Seems reasonable for the BA to provide the update URL at runtime. Seems that
setting the value would have to happen before returning from
DetectUpdateBegin().
___
FireGiant | Dedicated support for the WiX toolset |
http://www.fire
Top of message there says “This post has NOT been accepted by the mailing list
yet.”. You’ll want to follow up with the owners of that site why. We don’t have
anything to do with it.
___
FireGiant | Dedicated support for the WiX tools
go? Or should we wait for
a conclusion to this thread?
On 25-Nov-14 19:18, Rob Mensching wrote:
BVariantSetVariant() isn't bad. Maybe, BVariantAssign()? I think the important
trick is to control encryption state, right? Almost want a tri-state enum:
HRESULT BVariantAssign(
__in BURN_VA
easier to talk about code changes when you can actually see it.
On Tue, Nov 25, 2014 at 3:35 PM, Rob Mensching
mailto:r...@firegiant.com>> wrote:
Ahh, yes, right. The root issue is that the Source encryption state is rarely
set “correctly”. I 100% agree that using the target’s encrypti
f all callers of BVariantCopy properly set the target's encryption state
before calling. Using the target's encryption seems counter intuitive to me
though, especially since it's an out parameter.
On Tue, Nov 25, 2014 at 2:36 PM, Rob Mensching
mailto:r...@firegiant.com>>
against v3.9
That works, too. That just means at least one additional encryption/decryption
cycle, which I was trying to avoid.
On Tue, Nov 25, 2014 at 1:55 PM, Rob Mensching
mailto:r...@firegiant.com>> wrote:
Breaking change to BVariantCopy(). What if we always use the encryption state
of
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Just opened bug 4609 against v3.9
Here's how I would fix it:
https://github.com/rseanhall/wix3/commit/e14695eeac02b82f7d2ed392606cd1c8a670a7ab
On Tue, Nov 25, 2014 at 1:37 PM, Rob Mensching
mailto:r...@firegiant.com>>
It’s okay. I missed in code review as well. Anyway, we started digging into
this at FireGiant and I expect we’ll have a pull request against WiX v3.10 very
shortly.
___
FireGiant | Dedicated support for the WiX toolset |
http://ww
When rebasing, I usually just set a tag (so I can hard reset if the rebase goes
awry), do the interactive rebase, then if all is well, delete the tag. Avoids
switch branches when I'm just cleaning up in place.
___
FireGiant | Dedicat
1 - 100 of 954 matches
Mail list logo
