This is going to turn into a blog post, I know it. 0. First, at this point in WiX v3.x "deprecated" means the functionality will not be present in WiX v4.x. There are no breaking changes in WiX v3.x (unless we need to for security purposes). You can keep doing what you're doing as long as you're happy on WiX v3.x.
1. Melt (like most of the non-core tools) is sorely under documented. There is only a one sentence description on it today. As is the case (too often) detail gets isolated on my or Bob's blog: http://www.joyofsetup.com/2013/07/16/easy-pure-wix-patching-with-melt/. 2. The use of preprocessor defines as paths to other projects was a huge mistake we made early in the design of Votive. We should have used bind paths. Unfortunately, I've not successfully found a way to fix that mistake in a backwards compatible way in v3.x. Hope is that we can get it right in v4.x. 3. Now, you are correct. The ability to use the .wixout as an archive mechanism is absent in WiX v4.x. The goal (in WiX v4.x) is that to patch (should you need to patch) all you need is the stuff that is always output from the build: the MSI, any external .cabs/files and the .wixpdb. Archive that away the exact same way binaries and their .pdbs should be archived away. 4. Why!?!?!? Why would functionality that works be removed?!?!? There are a few reasons: 4a. Again, the goal in WiX v4.x is that to patch, all that is necessary is the standard output from the build. This reduces one more thing you have to pre-plan for if you might need to patch later. Today (WiX v3.x), melt.exe is the stopgap. 4b. Using the .wixout as an archive means you essentially double the output to your release location. This is less of an issue if your package is small but it is a huge problem if your package is huge. This makes binary .wixout's a very non-ideal scenario in some cases. Note: in WiX v4.x the size issue would be even worse because "bound files" are no longer compressed. 4c. Maintaining multiple ways of doing the same thing in the WiX toolset is expensive. If we can come up with a single solid implementation for a problem, we should do so. That minimizes bugs across implementations and frees us up to do other work. This is particularly important in areas like patching where the problem is already insanely complex and the people that can work on patching happen to be people that could work on just about anything. Hopefully that makes the direction we're trying to head in clearer. I know that it doesn't solve the "you moved my cheese" issue. _______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -----Original Message----- From: Nick Ramirez [mailto:nickra...@hotmail.com] Sent: Thursday, January 8, 2015 8:02 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Creating patches using wixout (-bf flag deprecated) Sounds like undocumented functionality of Melt. I don't see anything about using it that way in the WiX.chm. Also, binder variable don't solve the problem of binding the source files into the XML file. They only give you a way to list a bunch of paths to probe. So they don't replace the functionality we'd be losing if -bf is taken away. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
