From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: January-21-15 5:27 PM
To: wix-devs@lists.sourceforge.net
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/
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
