From: Tunney, S. <Ste...@nu...> - 2015-01-22 18:55:24
|
From: Bob Arnson [mailto:bo...@jo...] Sent: January-21-15 5:27 PM To: wix...@li... Subject: 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 Visual Studio on a laptop and multiple colors of pen at a whiteboard. :) I'm all for the talking :) Sometimes I seem impatient... sometimes I *am* impatient. I apologize for coming off as such. 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 suggested we maybe should consider the MSBuild targets to get there and I think Bob agreed that's a good place to start... For sure. Mostly it's a question of whether we keep using single-purpose tools wrapped in targets or we start moving more logic into tasks/targets (or other higher-level tools that are then wrapped in targets). Now that we are talking about tasks/targets I'm getting a little more excited. I'd really like to see something in my .wixproj for patching that defines the RTM paths, the families, versioning, types, and Upgrade MSI paths. Everything else could be take from there. To be honest I think we could even automatically generate a wxi file that has the extracted TargetProductCode and Media elements, this file would also drive the creation of the "-t" arguments for pyro. Sorry if the process takes a little bit to get there. Patching is both one of the hardest parts of the Windows Installer and the least developed in the WiX toolset. I expect we still have quite a bit of ground to cover to get to an answer. Do you agree? As usual, we have the right tools to support everything that MSI supports, even if it's not the simplest to execute on. Let's continue on with the assumption that an MSBuild task is the way to go to aggregate this functionality. I think we have a winner here too! Right now we're missing information. Can we easily adapt to using .msi+.wixpdb pairs inside pyro? Peter added the admin-image stuff so that points to yes but for some reason I'm not feeling confident. 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? If we move to a MSBuild style the only questions that really need to be asked are: RTM MSI paths Upgrade MSI paths Patch Families to create Version Type If these were the questions answered everything else can either be auto-generated or inspected from the contents of the values given. To be honest I already have this set up in NAnt as a set of targets. Transitioning to MSBuild as a task/target wouldn't take too much effort. -- sig://boB http://joyofsetup.com/ |