Re: [WiX-devs] x64 extensions binaries for Windows Server 2016 without WoW64

CAs only or CAs+everything else? ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Rob Mensching [mailto:r...@firegiant.com] Sent: Thursday, 16 July, 2015 12:19 To: WiX toolset developer mailing

[WiX-devs] No meeting today

We don't have any new bugs to look at (just some old ones). WiX v3.10 RC build should come out today - stay tuned to blogs, Twitter, and http://wixtoolset.org/. ___ FireGiant | Dedicated support for the WiX toolset | http://www.fir

Re: [WiX-devs] .Net 4.5.x Eula - question for Bob

You're just trying to take all the fun parts of my unpaid job, aren't you? :) Thank you! This is great. ___ FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/ -Original Message- From: Phill Hogla

Re: [WiX-devs] Status of 4.x - Creating patches

Patching's broken at the moment: http://wixtoolset.org/issues/4556/ ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Thursday, 2 April, 2

Re: [WiX-devs] Optional command line arguments WIP updated

arguments WIP updated I would like to see Condition added to MsiProperty as well. When can we start using this? :) On Fri, Mar 27, 2015 at 1:53 PM, Bob Arnson mailto:b...@firegiant.com>> wrote: You’re both wrong. ☺ I wanted to use WixBundleExecutePackageAction instead of On* attributes s

Re: [WiX-devs] Optional command line arguments WIP updated

ttp://www.firegiant.com/ From: Bob Arnson [mailto:b...@firegiant.com] Sent: Wednesday, March 25, 2015 9:46 AM To: wix-devs@lists.sourceforge.net<mailto:wix-devs@lists.sourceforge.net> Subject: [WiX-devs] Optional command line arguments WIP updated You can see the diff via pull request at https:

[WiX-devs] Optional command line arguments WIP updated

You can see the diff via pull request at https://github.com/wixtoolset/site/pull/50. I'm strongly leaning toward the "package action variable." It's simple to implement and basically solves the problem adding this functionality to MsiProperty. Feedback sought and welcomed. ___

Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute

If we held our breath for explicit confirmation from the MSI SDK, we'd all be zombies. However, I finally found a mention in the ICE80 doc, so I begrudgingly agree with you. :) From: Heath Stewart [mailto:hea...@outlook.com] Sent: Friday, 20 March, 2015 21:31 To: WiX toolset developer mailing li

Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute

I know that's true of the general case but there's nothing in the RegLocator doc to suggest it applies to searches. I'm going to try a file search - I can see that being affected. (I'm wondering if Burn handles that case either...) From: Heath Stewart [mailto:hea...@outlook.com] Sent: Friday, 20

Re: [WiX-devs] WIXFEAT4707 - Replace Win64 Attribute

64-bit searches are legal (or at least aren't contraindicated) and work from 32-bit packages. So we need to keep a way to specify that. Naming both is hard... From: Rob Mensching [mailto:r...@firegiant.com] Sent: Friday, 20 March, 2015 17:22 To: WiX toolset developer mailing list Subject: Re: [W

[WiX-devs] Anybody using VS2015 CTP6?

I think there's a bug in C++/14 that causes the .wixburn section to be dropped. I can't even find it in the .obj. No doc or warnings that complain about #pragma data_seg. Apparently, I'm going to be spending my Sunday night uninstalling VS2015 and reinstalling VS2013. I'm in for a thrill ride!

Re: [WiX-devs] Build break in wix4 when compiling help

HEAD was a shortcut for "latest." As of a2f0d29ae3fa96f9a74519f428bd5a68b95113f2, it still builds, both in debug and release. Dev12 VSU4 slipstream. On 28-Feb-15 17:49, Heath Stewart wrote: Works for me in wix3 - just not in wix4. Since HEAD is a local ref, I assumed you're sync'd to the mainl

Re: [WiX-devs] [wix4] WIXFEAT4658 - Add builtin button functionality to thmutil (#89)

My $0.02: Prioritize (1) straight line, (2) branches (i.e., "click Go to install or Customize to choose features" both of which go to progress page). Anything else is gravy. On 25-Feb-15 20:02, Jack Hennessey wrote: Thanks for starting this thread. My mind first went to the stack implementati

Re: [WiX-devs] Build break in wix4 when compiling help

WorksForMe(tm) on HEAD. On 28-Feb-15 16:22, Heath Stewart wrote: Oops, sorry. That's when running doccompiler.exe (was looking at the wrong line). I did install HTML Help Workshop on this new machine (guess I haven't done a full build on this one yet) so its not related to that. *Heath Stewa

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 02-Feb-15 15:20, Tunney, Stephen wrote: 1)What is the preference in 4x for tasks? Add a “Project Reference” to things like light, melt, etc. or call out to %WIX%\bin\light.exe? Tasks inherit from WixToolTask to get a bunch of common behavior. 2)What solution would you like this task to

Re: [WiX-devs] Coding Standards

On 30-Jan-15 10:17, Tunney, Stephen wrote: I’m all for code style consistency. Do you guys have a tidy-up macro or a code formatting configuration for Visual Studio (2012+) that I can incorporate so that you guys can worry less about whitespace issues in pull requests? Never seen one. Or is it

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Don't forget your wix3 pull request. :) On 27-Jan-15 22:53, Stephen Tunney wrote: Let me know. I will fork wix4 and get a move on it. On Tue, 27 Jan 2015 22:49 Bob Arnson <mailto:b...@joyofsetup.com>> wrote: On 27-Jan-15 09:22, Tunney, Stephen wrote: Bob, exactly.

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 27-Jan-15 09:22, Tunney, Stephen wrote: Bob, exactly. This MSBuild task would call the Melt, candle, light, torch, and pyro tasks in the background using the supplied values. This would leverage all of our existing code and provide a simple façade for most users to create “normal” patche

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 22-Jan-15 13:55, Tunney, Stephen wrote: You’re suggesting that we remove the melt and torch steps and have pyro encompass **everything** that patch building requires? Or is this the Pyro MSBuild Task that you speak of? The latter. We need the building-block tools (torch, pyro) but can build

Re: [WiX-devs] Issue #4206 - Firewall port list or range not possible #132

On 26-Jan-15 19:06, Rob Mensching wrote: Finally, I’d bet dollars to donuts the current firewall code didn’t validate the port range because the person that wrote the code initially didn’t know there was an allowed range. I'll take that bet. The reason there's little validation is that original

Re: [WiX-devs] 4632 - Use ETW for logging and additional tracing

On 20-Jan-15 23:14, Sean Hall wrote: > Are we planning on dropping support for XP in 4.x? Does that mean we > should bump up to .NET 4.5? Runtime, I agree with Rob: It'll be a couple of years before XP drops to nuisance levels. Build time, I think it'd be fine to assume Windows >=7 and .NET 4.>=

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 21-Jan-15 16:29, Rob Mensching wrote: Isn’t this what we’re discussing? Different ways to solve the patching problem? I totally agree we haven’t hit consensus. Right -- talking is how we get there. In person, this would be a shorter conversation with people swapping positions between Visu

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 20-Jan-15 14:54, Stephen Tunney wrote: I think one less executable would be a good thing. Less code to maintain, etc. etc. Adding modes makes more complicated code and the only thing you've saved is the "shell" work in having an additional project. -- sig://boB http://joyofsetup.com/

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 20-Jan-15 14:19, Rob Mensching wrote: > We have light and lit today because C/C++ has link.exe/lib.exe. If someone > wanted to argue that we should get rid of lit.exe and just make light.exe the > tool that outputs build stuff, I could see that. Lit *is* different because > it doesn't do link

Re: [WiX-devs] Updating Melt to 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): patching should operate off the standard build output: msi, external > cabs/fil

Re: [WiX-devs] WiX Online Meeting time in 2015?

On 18-Jan-15 02:52, Rob Mensching wrote: 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. 0800? --

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

nly real difference I can > see. > > Should it be considered to merge the two tools together perhaps? Just a > thought exercise perhaps but the questions you two both raised have put a > smell in my nose. > Stephen > ____________ > From: B

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Just -xn works for me. On 05-Jan-15 22:32, Tunney, Stephen wrote: > I like just -xn > > Not -xaladark ?? No? > ____ > From: Bob Arnson [b...@joyofsetup.com] > Sent: January 5, 2015 6:51 PM > To: wix-devs@lists.sourceforge.net >

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 03-Jan-15 20:36, Stephen Tunney wrote: > Ok, so here's my pitch: > > v3.x would get a couple of new flags > -xn (extract in new directory format) > -xb (extract binaries, does not get squashed by -sextract and uses old > path format) Do we need both? I like -xn -- subdirectories for files and

Re: [WiX-devs] 4592 - RestartResource solution and review

On 18-Dec-14 09:27, Phill Hogland wrote: > I anticipate missing the meeting today. Is there anything else that I need > to do on 4592? All good. I fixed up a couple of whitespace issues and merged. Thanks! > I am also looking for some suggested bugs to work on, although I don't know What are area

Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 02-Jan-15 11:50, Tunney, Stephen wrote: I have some good news regarding the work I’m doing with melt. It appears as though all other steps (light, torch, pyro) all seem to carry the changes forward from melt and applying the patch in Orca shows that the Binary data has been updated. All

[WiX-devs] WiX Online Meeting #51

BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:Eastern Standard Time BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02000

Re: [WiX-devs] 4592 - RestartResource solution and review

On 09-Dec-14 13:12, Phill Hogland wrote: > I submitted a pull request. I am still a little confused on the process so > please let me know what I should do different. Thanks for all of the > assistance! The pull request was fine -- there were no conflicting changes so you didn't have to rebase.

Re: [WiX-devs] 4592 - RestartResource solution and review

On 04-Dec-14 09:48, Phill Hogland wrote: > When including an mba.dll as a bootstrapper payload, most examples that I > have seen just include the mba.dll (and any specific dependency dlls that I > also added). However the mba.dll project output folder also has a lot of > wix and microsoft 'framewo

Re: [WiX-devs] Allowing pyro to generate empty transforms

On 06-Dec-14 01:13, Heath Stewart wrote: Bob, I'm a bit confused by the question / thread here: https://github.com/wixtoolset/wix3/pull/156 Generally, empty transforms should not be included in a patch because it impacts install performance of both patches and bundles that include them, and a

[WiX-devs] WiX v3.9 R2 candidate available

WiX v3.9.1208.0, a candidate for the WiX v3.9 R2 servicing release, is now available. It's not publicly visible on the list of weekly releases but you can get the installer at http://wixtoolset.org/downloads/v3.9.1208.0/wix39.exe. At Thursday's meeting, we should discuss what our release criter

[WiX-devs] Servicing branch available

And the WiX v3.9 servicing branch is named *wix39r2*. I cherry-picked these commits: https://github.com/wixtoolset/wix3/commit/bb3f04cd65d80b1aeec1f6a4fa0e0d0d8d982b04 [4609] https://github.com/wixtoolset/wix3/commit/c2199cc44f5186b48488765f8d126a74727d [4608] https://github.com/wixtoolset

Re: [WiX-devs] BA Functions, OnPlanRelatedBundle

On 28-Nov-14 04:41, Neil Sleightholm wrote: As the original author of BA Functions I thought I’d comment. I’d agree with Bob that it is rarely used so having to upgrade wouldn’t be such a big deal. I seem to remember looking at making this a base class originally but IIRC there was a problem wi

Re: [WiX-devs] [SPAM] Re: [SPAM] Re: 4592 - RestartResource solution and review

On 03-Dec-14 11:13, Phill Hogland wrote: > As I reported, I succeeded in creating an "unofficial Official" build, in the > sense that it did a full compile without any errors or skipping any part of > the build. This gets me back to the point where if I recompile both my > compiler extensions and m

Re: [WiX-devs] BA Functions, OnPlanRelatedBundle

On 26-Nov-14 17:20, Hoover, Jacob wrote: I have some new requirements for my installer, and I had previously mentioned customizing WixStdBA for handeling related bundles. The feedback was to expose it so that a BAFunction could implement the customization. What is the plan on breaking BAF’s i

Re: [WiX-devs] [SPAM] Re: [SPAM] Re: 4592 - RestartResource solution and review

On 25-Nov-14 00:48, Blair Murri wrote: IIRC an older version of Sandcastle had to be used. Sean just fixed that. -- sig://boB http://joyofsetup.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server

Re: [WiX-devs] Just opened bug 4609 against v3.9

Is the existing PR from Team FireGiant still good to 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-

Re: [WiX-devs] Just opened bug 4609 against v3.9

On 25-Nov-14 00:46, Blair Murri wrote: If you want I could post a pull request against wixtoolset/wix3/master branch with my proposed fix, but I want to have some of you discuss whether you think this is a show stopper or not (my current client can live with the limitations for now). Unfortunat

Re: [WiX-devs] [SPAM] Re: [SPAM] Re: [SPAM] Re: [SPAM] Debug delopment story

First thing to try: Verify the .msi is being built with your changes. Stick a string of asterisks in the code that you can search for. On 19-Nov-14 17:33, Phill Hogland wrote: > I have continued to work on this issue every chance I get. I have tried many > approaches but have not found any way t

Re: [WiX-devs] 2. Re: Wix 3.x - Include .NET 3.5 in WixNetFX extension - Bug > 4584 (Rob Mensching)

http://wixtoolset.org/development/assignment-agreement/ On 19-Nov-14 18:20, Carter Young wrote: > Would someone please email me, or tell me here what I need to do to > receive a copy of the assignment agreement? > >> -- >> >> Message: 2 >> Date: Tue, 18 Nov 2014 19:14:5

Re: [WiX-devs] [SPAM] Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

On 18-Nov-14 12:58, Sean Hall wrote: > We're discussing this topic on Thursday's meeting, right? Probably a good idea, eh? Rob, an agenda item? > Because I'm not sure how much we can accommodate migrating custom > themes from 3.x to 4.x if we do all the features I'm thinking of, like > somehow a

Re: [WiX-devs] [SPAM] Re: WIXFEAT:4149 - Add UninstallSuccess page to WixStdBA

On 18-Nov-14 10:19, PavelAnfimov wrote: > Why not take advantage of our implementation until you finish yours? Our > implementation adds the requested features already now, affecting the > minimum numbers of lines of source code, as in bootstrapper theme files, and > in source code of WixStdBa. I h

Re: [WiX-devs] [SPAM] Re: FW: Problems upgrading to WiX 3.9 - BUG

On 18-Nov-14 11:15, Hoover, Jacob wrote: > The bug is caused by not having a .dll extension so git didn't know it was a > binary. (Why on earth didn't we have an extension?) Because the files came from a merge module. -- sig://boB http://joyofsetup.com/ -

Re: [WiX-devs] Problems upgrading to WiX 3.9 - BUG

On 18-Nov-14 11:33, Hoover, Jacob wrote: > Why would the 3.10 changes matter? You can easily branch as of 3.9 RTM, fix > the mangled DLL's, and cut a release from that branch. Sure but I'm not volunteering Rob to do an official build from a branch other than develop. :) -- sig://boB http://joyo

Re: [WiX-devs] Problems upgrading to WiX 3.9 - BUG

On 18-Nov-14 11:09, Rob Mensching wrote: > I'd toss out that we figure out how to fix this then release a .zip file with > only the VSExtension in it (i.e. do not release a full new build). Bob? If we hadn't opened the floodgates on v3.10 changes, I might want to do the first WiX service pack ev

Re: [WiX-devs] [SPAM] Re: [SPAM] Debug delopment story

On 15-Nov-14 16:18, Sean Hall wrote: > No, I do all development and building on my dev machine. Then I setup > a VM for the environment I need to test, and create a snapshot. Then > I copy the MSI/bundle from the dev machine to the VM and test it out, > reverting back to the snapshot as necessary

Re: [WiX-devs] [SPAM] Re: 4592, but first github????

On 14-Nov-14 18:29, Phill Hogland wrote: > thought the above was going to make a new folder tree, and I don't see it. Nope -- Git updates files, as needed, in place. -- sig://boB http://joyofsetup.com/ -- Comprehensive S

Re: [WiX-devs] Bug in AdvancedWelcomeEulaDlg?

On 06-Nov-14 10:15, Nik T wrote: Is the fact the following statement from AdvancedWelcomEulaDlg.wxs is missing an Overridable=”yes” attribute an issue? It's only pulled in if you reference AdvancedWelcomeEulaDlg. Otherwise, it only prevents you from choosing a different progress dialog. --

Re: [WiX-devs] WIP 4161 - 4.x edition

On 10-Nov-14 19:20, Sean Hall wrote: > Maybe if I have time to go through the cache execute code I can > implement something like this. Otherwise, since the full and redist > package have the same license could you live with only being able to > set the license on one package? Yes. Or, if not, it'

Re: [WiX-devs] Wix build machine

On 01-Nov-14 14:04, Sean Hall wrote: > Looking at the build file from v3.6, the current documentation seems > to leave out that WiX requires Visual C++ Express (or Visual Studio) > along with the platform SDK. Should we update the documentation, or > add support for building with just the platform

Re: [WiX-devs] Strong naming WixTests.dll : v 4.0

On 01-Nov-14 13:26, Hoover, Jacob wrote: Would anyone have any strong objections on removing the strong naming of the WixTests assembly for 4.0? I started working on Nancy for an embedded web server for testing bundle self-updates, however Nancy’s NuGet package isn’t strongly named. I’d rath

[WiX-devs] WiX v3.9 released

WiX v3.9 released Friday, October 31, 2014 The production/stable release of WiX v3.9 has been released. You can download it from here . Read more about the release at Rob's blog

Re: [WiX-devs] WiX v4.0 Default Compression Level?

On 22-Oct-14 21:06, Rob Mensching wrote: I completely agree with this and #2 is straight forward to do below. We should be able to make it so. Should we get a WIP written up? Does it need a WIP or just a note in the What's New document? -- sig://boB http://joyofsetup.com/

Re: [WiX-devs] Possible bug in 3.9 when compiling pure-wix patches that need to update entries in the Binary table.

On 28-Oct-14 16:50, Tunney, Stephen wrote: I would think that this is a bug in light since melt doesn’t output entries from the Binary table to disk but I’ve been wrong before. I will try and create a reproducible test bed and reproduce the issue. Sounds like a bug in Melt, that it should suppo

Re: [WiX-devs] WIP 4161 - 4.x edition

On 22-Oct-14 19:50, Sean Hall wrote: > I really think that the feature of using the full redist package when > available, and the web package as a fallback, should be in the engine. Maybe. I'm not sure how common it is, though, whether it's something important/common enough to earn a spot in the e

Re: [WiX-devs] WIP 4161 - 4.x edition

On 22-Oct-14 19:15, Sean Hall wrote: > So the install fails if the redist package doesn't pass verification, > and the user has to delete it to make it work? Not very user friendly. No different than any other failed package. > If you're modifying the InstallCondition, then you must be authoring

Re: [WiX-devs] WIP 4161 - 4.x edition

On 22-Oct-14 18:47, Sean Hall wrote: > Hmm. I was ignoring your scenario because it's not possible to write > an install condition like that. Well, I frequently do the impossible but in this case, it's definitely possible. > If that functionality is added, I would expect it to be authored as >

Re: [WiX-devs] WiX v4.0 Default Compression Level?

On 21-Oct-14 21:53, Chris Dahlberg wrote: With cab count appearing to have even more of an impact on link time than the compression level, I agree that halving it to 100MB is a good idea. Generally true. The assumptions are that you have a big enough installer and have enough cores to benefit f

Re: [WiX-devs] WIP 4161 - 4.x edition

ne file, right? They can also customize the theme. On Mon, Oct 20, 2014 at 11:14 PM, Bob Arnson <mailto:b...@joyofsetup.com>> wrote: Which is the "default URL"? First? I suppose that would work, as long as @After is used correctly. (To be clear, this isn't a real

Re: [WiX-devs] WIP 4161 - 4.x edition

Force the user to customize the UI to disable the default URL link, and use the new ability to conditionally hide controls to show the right license? On Mon, Oct 20, 2014 at 10:50 PM, Bob Arnson <mailto:b...@joyofsetup.com>> wrote: On 20-Oct-14 23:34, Sean Hall wrote: S

Re: [WiX-devs] WIP for migrating v3 source code to v4.

Definitely we want the doc topic, because not every change can be fixed by WixCop. Do we want the doc to be built from the WIP content or should we maintain the list in doc? On 20-Oct-14 23:50, Sean Hall wrote: I was going to ask what was done for 2.x -> 3.0, but I guess DTF and Burn weren't a

Re: [WiX-devs] WIP 4161 - 4.x edition

On 20-Oct-14 23:34, Sean Hall wrote: Since we're talking about breaking changes in v4.0, I sent a pull request to update the WIP about MBA prerequisites. As mentioned in th

Re: [WiX-devs] WiX v4.0 Default Compression Level?

On 18-Oct-14 21:02, Rob Mensching wrote: First, picking reasonable defaults for things in WiX is the only way we'll reduce the complexity. However, exposing the full power of the Windows Installer for those that want/need it is also still very important. Second, thank you for the data point

Re: [WiX-devs] WiX v4.0 Default Compression Level?

On 17-Oct-14 14:26, Rob Mensching wrote: Bob and I are having a little conversation on a pull request about what the default compression level should be in the WiX toolset: https://github.com/robmen/wix4/commit/edf0a4cc32992d918846631fe7a2338bbf700c08#commitcomment-8206079 Historically, we u

Re: [WiX-devs] Move WiX Online Meeting?

On 14-Oct-14 17:03, Rob Mensching wrote: I'm not going to be able to make the usual WiX Online Meeting timeslot this week. I could move the meeting back to 14:00 Pacific or we could just skip this week. Thoughts? I'm open. -- sig://boB http://joyofsetup.com/ --

Re: [WiX-devs] Naming internal bundle related tables.

On 07-Oct-14 14:34, Rob Mensching wrote: In the massive bundle binder refactoring, it was exposed that there are a lot of unreal Bundle-related tables that are not prefixed (Like ChainMsiPackage) or prefixed poorly (MsiFeature). See: https://github.com/wixtoolset/wix4/pull/50#discussion_r1853

Re: [WiX-devs] Updated WiX Toolset issue #4434 - Pyro throws MsiException when Patchbaseline name is really long

On 07-Oct-14 12:54, Stephen Tunney wrote: > There is a limit to the length of the value in the MSI table. This is > an infrastructure issue that WiX works within. The exception is there > to assist a developer in building a product that works within this > inheritted limitation. I'd much rathe

Re: [WiX-devs] Updated WiX Toolset issue #4434 - Pyro throws MsiException when Patchbaseline name is really long

On 05-Oct-14 16:47, Stephen Tunney wrote: > > The limit is variable, true. The xsd docs are like "the pirate's > code" though, right? :) > > Otherwise this seems like a code change in 4.x > Exceptions are bugs. If we need to crank down the length limit, it's preferable to an exception. -- sig:

Re: [WiX-devs] Updated WiX Toolset issue #4434 - Pyro throws MsiException when Patchbaseline name is really long

The limit might be wrong, since the length of the id varies as you add transforms. On 03-Oct-14 15:31, Stephen Tunney wrote: > What action would you like to see come out of the discussion? > Improved documentation set in the XSD as to how to determine how long > one should make their baseline

Re: [WiX-devs] Updated WiX Toolset issue #4434 - Pyro throws MsiException when Patchbaseline name is really long

Discussion at https://github.com/wixtoolset/wix3/commit/2c25ea685855c5a2aa4c9d26e38d74754dc14d76#commitcomment-8023152. On 03-Oct-14 15:09, Stephen Tunney wrote: http://wixtoolset.org/issues/4434/ Why was this changed from Resolved to Untriaged? Is there more to fix that I can add to the iss

[WiX-devs] ICE Breaker v0.0.1

I just committed a draft readme to the new icebreaker repo: https://github.com/wixtoolset/icebreaker It lays out some rough plans and requirements. Interesting ones include: * Tests are required. This is all-new code so there's no excuse not to have them. They won't necessarily be unit tests, t

[WiX-devs] The ICE replacement project

(Rob: You had a name for the ICE replacement project -- what was it? As you know, naming a project is the most important part...) As I write up the WIP, I thought I'd get a head start on any discussion. I want to kick off the project with a proof of concept. Basically, I'd set up a new repo and

[WiX-devs] WiX v4.0/v4.x planning WIP

I collected the bits of my original v4.x features thread and the follow-up in a WIP. I tried to swag whether the features had to be in v4.0 or whether they could come in later v4.x releases. Obviously, everything could go into v4.0, time willing, but it's not strictly necessary. Take a look, s

Re: [WiX-devs] Bugs 4490 and 4491

On 16-Aug-14 07:47, Blair Murri wrote: Does that mean we are still on track for Labor Day? Depends on incoming. -- sig://boB http://joyofsetup.com/ -- ___ WiX-devs mailing li

[WiX-devs] Bugs 4490 and 4491

4490: Rob and I figured out what was going on. I wrote it up in the bug at http://wixtoolset.org/issues/4490/, so see that for details if you're curious. Good news is that it's not really a bug but a design hole and fixing that isn't something we can do in v3.9. (And it wouldn't fix the bug for

Re: [WiX-devs] Bug 3635

On 10-Aug-14 03:14, Blair Murri wrote: When I submitted a fix for this, I was asked to hold off until the code it interacted with was changed/stable. Are we at that point, so I can reimplement this yet? It would just have to go into v4.0, since it's a behavior change against v3.x. -- sig://bo

Re: [WiX-devs] 16 things I'd like to see in WiX v4.x

On 09-Aug-14 00:12, Rob Mensching wrote: > 3. Currently following MSI documentation, not sure what you're thinking here. Just wondering if there's more we can support and stay safe. Nothing comes to mind, but thought it worth the exercise. > 4. Yes, definitely the ConditionRef interested to discu

[WiX-devs] 16 things I'd like to see in WiX v4.x

Here's a quick list of things that would be nice to clean up as part of a new major release. Most of these are additive so could be done throughout the v4.x series. Anyone think any are a bad idea? I'll end up writing at least a few WIPs for these, though I might cheat and combine a few. 1. P

Re: [WiX-devs] bug4481

Merged. Thanks! On 04-Aug-14 09:45, Hoover, Jacob wrote: I'm happy with the changes, and anything I can think of has now been handled. PR is here: https://github.com/wixtoolset/wix3/pull/128 I did have one feature creep, which was to not check

Re: [WiX-devs] WixToolset.org issue...

Since we're meeting tomorrow, I opened a bug. On 31-Jul-14 13:11, Sean Hall wrote: Are you going to resubmit it? It does fix Jacob's issue, it's just no one filed a bug on it. On Thu, Jul 31, 2014 at 12:08 PM, Bob Arnson <mailto:b...@joyofsetup.com>> wrote:

Re: [WiX-devs] WixToolset.org issue...

d. -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com <mailto:b...@joyofsetup.com>] Sent: Thursday, July 31, 2014 11:31 AM To: wix-devs@lists.sourceforge.net <mailto:wix-devs@lists.sourceforge.net> Subject: Re: [WiX-devs] WixToolset.org

Re: [WiX-devs] WixToolset.org issue...

On 31-Jul-14 11:14, Sean Hall wrote: > No meeting today? It's starting to feel like not having a meeting is > the norm. It just feels that way because it's been two weeks in a row. :) I used to have an O365 account but let it lapse because I never used it. I'm not sure there's a good alternativ

Re: [WiX-devs] WixToolset.org issue...

We have a serious regression in Burn -- http://wixtoolset.org/issues/4486/ -- so we'll have to take a fix. That being the case, I'm +1 for #2, to disable Update when called from ARP, if someone wanted to open a bug. On 28-Jul-14 22:11, Bob Arnson wrote: 1. If we set DisableModify=&

Re: [WiX-devs] WixToolset.org issue...

1. If we set DisableModify="button" we get an Uninstall/Change button that triggers maintenance mode, so the BA wouldn't go straight into uninstall. +1 on doing this for WiX v3.9. 2. Someone could still run the bundle with a switch, so we should disable Update when /uninstall is passed. +0 on do

Re: [WiX-devs] Bug 4474: The binaries zip file and the full install have different content in the SDK folder

or v3.10? On Fri, Jul 18, 2014 at 9:49 PM, Bob Arnson <mailto:b...@joyofsetup.com>> wrote: Pulled. I'll add it at the beginning of v3.10. On 17-Jul-14 19:32, Sean Hall wrote: I'm ok with this if Express support is added. Otherwise, I don't know who ben

Re: [WiX-devs] appsyn feed: documentation

:51 PM *To:* WiX toolset developer mailing list *Subject:* Re: [WiX-devs] appsyn feed: documentation FYI, I believe I've fixed the feed. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ *From

Re: [WiX-devs] Breakign apart changes before PR

On 19-Jul-14 16:46, Hoover, Jacob wrote: Bob/Rob,? Do you want me to split apart the changes in https://github.com/jchoover/wix3/tree/WixBAUpdates before doing the pull request? I could see all the core fixups in one commit. And then t

Re: [WiX-devs] appsyn feed: documentation

On 19-Jul-14 15:50, Hoover, Jacob wrote: Ahh, was meant to be v 3.9 leaks, not indicating the number of leaks. I figured it out. Eventually. :) No, all remaining leaks look like they are CRT. Those might be intentional, in that they don't explicitly clean up stuff that goes away at process

Re: [WiX-devs] appsyn feed: documentation

I was concerned when I saw that your branch had "39 memory leaks..." Do the 63 leaks start in WiX/Burn? Maybe I'll put the RC2 build through AppVerifier... On 19-Jul-14 15:33, Hoover, Jacob wrote: Now if only I could cleanup the 63 CRT heap leaks... *From:*Bob A

Re: [WiX-devs] appsyn feed: documentation

Merged. Thanks! On 19-Jul-14 15:19, Hoover, Jacob wrote: Leaks put into their own PR, https://github.com/wixtoolset/wix3/pull/118 <https://github.com/wixtoolset/wix3/pull/118> *From:*Bob Arnson [mailto:b...@joyofsetup.com] *Sent:* Saturday, July 19, 2014 2:03 PM *To:* wi

Re: [WiX-devs] appsyn feed: documentation

On 19-Jul-14 14:54, Hoover, Jacob wrote: Yeah, but I have a branch out there for our discussed changes so WixBA uses the engine atom feed parsing. Unfortunately, there are outstanding issues with the existing WiX feed so the engine as is won't accept it (lacking the app id throws out all the

Re: [WiX-devs] appsyn feed: documentation

On 19-Jul-14 12:31, Hoover, Jacob wrote: In the mean time I did some profiling and found some memory leaks. Shall I submit a PR based off the WixBAUpdates branch, or should I rebase off of develop? You can probably just merge; there hasn't been that much churn. -- sig://boB http://joyofsetup.

Re: [WiX-devs] Bug 4474: The binaries zip file and the full install have different content in the SDK folder

t broken every time they upgrade WiX anyway?). People with Express will still have to download the binaries zip for the headers. On Thu, Jul 17, 2014 at 6:15 PM, Bob Arnson <mailto:b...@joyofsetup.com>> wrote: On 17-Jul-14 18:58, Sean Hall wrote: > Am I missing something?

Re: [WiX-devs] Bug 4474: The binaries zip file and the full install have different content in the SDK folder

On 17-Jul-14 19:32, Sean Hall wrote: > I'm ok with this if Express support is added. Otherwise, I don't know > who benefits. People with full versions of VS will have their > projects broken because the inc folder moved (or do they get broken > every time they upgrade WiX anyway?). People wit

Re: [WiX-devs] Bug 4474: The binaries zip file and the full install have different content in the SDK folder

On 17-Jul-14 18:58, Sean Hall wrote: > Am I missing something? With this pull request, if you don't have any > version of VS installed you still don't get any headers right? Yeah. That seems like the right behavior (modulo adding Express support). Most of the headers are useless without the libr

  1   2   3   4   5   >