Unfortunately I was not able to get a wixout as output, I’m likely not getting
the command line right.
In Bob’s assessment of the feature request he mentioned using Insignia which I
tried however while it can reattach the attached containers it leaves the UX
container in place which gets chopped off when setting the version. The only
option left to me is to walk the PE structures down to the version info and
make the change that way without affecting the containers. Perhaps I can use
the .wixburn section to find where the containers begin and thus be able to
restore them afterwards.
Anyway thanks for the suggestion.
Thanks,
JohnG
From: Blair Murri [mailto:os...@live.com]
Sent: Wednesday, December 04, 2013 1:59 AM
To: wix-devs@lists.sourceforge.net
Subject: Re: [WiX-devs] New user and request
Could you test this idea?
Add an -xo argument to dark (produces WIXOUT instead of WXS). Use light against
the produced WIXOUT file. Does it rebind correctly?
If that works, see which binary/binaries are used by light to generate the
bundle EXE (and its engine). See if it rewrites the settings you needed to
override.
-Blair
From: Gonzalez, John<mailto:john.gonza...@intel.com>
Sent: Tuesday, December 03, 2013 3:23 PM
To: wix-devs@lists.sourceforge.net<mailto:wix-devs@lists.sourceforge.net>
The reason for this request is that the Win32
BeginUpdateResource/EndUpdateResource API’s chop the binary at the proper end
thus dropping the payloads. I discovered this when I used
Microsoft.Deployment.Resources.dll. I ran into a couple of resource editors
that would preserve the payloads simply because they contain their own resource
parser. I would prefer to use a tool instead of making changes to the Wix side.
There are two ways I can think of achieving this, both occurring after the
build is complete;
1. Unbind the UX and package payloads (like Dark does), update the
version info using Microsoft.Deployment.Resources.dll, then bind the payloads
back in. Is there a tool functionally opposite to Dark?
2. Write custom code to read the version info as structures by starting
at the PE header and climbing down and then writing it out manually as well.
Similar to how some resource editors do it as I mentioned above.
As far as my need for this, my team supports close to two dozen installers for
various product teams however we are very loosely coupled. We create and
maintain msbuild files, *.wxs files, and a custom C++ BA which get labeled as a
group. The label is then used by the product teams where they drop in their
product binaries in pre-determined folders and fire off a build. This goes on
indefinitely until a change is needed from the installer side. Thus the same
installer is used many times, for nightly/weekly/engineering builds and when
issues arise the file version is how we can determine if that issue has been
fixed, and for general tracking. Add to that L10N validation occasionally
getting a drop for regression where they need the version to file issues
against the installer.
Sorry for the long-winded explanation. I’ve been in this group close to seven
years and this was the model when I arrived. Well generally at least, back then
file installs were done with CopyFile() and uninstalled with DeleteFile(). ☺
Thanks,
JohnG
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Tuesday, December 03, 2013 1:20 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] New user and request
Thanks. Reading the feature, I don’t think this is something we need to add to
the WiX toolset. It’s pretty odd requirement and not necessarily what we really
want people doing. It also seems easy enough to do outside of the WiX toolset
with a custom executable, right?
From: Gonzalez, John [mailto:john.gonza...@intel.com]
Sent: Tuesday, December 3, 2013 8:34 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] New user and request
Thanks Rob. Issue filed as feature 4219
Thanks,
John
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Monday, December 02, 2013 12:12 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] New user and request
Welcome, John!
First, you’ll want to open an issue to track the bug or feature at
http://wixtoolset.org/issues. That will get the issue on the radar to be
triaged. At triage we (you’re welcome to join, of course) decide what release
the issue should be applied to. Based on that, you’ll know what branch to put
the feature into.
If you want to get ahead of the curve, I’d recommend picking the latest branch
for the major version you are on. So, if you think the issue should go into WiX
v3.x then you’d want to pick “wix39” (that’s the latest available number for
WiX v3 right now). If you want to target WiX v4.x then you’ll want to pick the
“wix40” (that’s the latest available number for WiX v4 right now).
From: Gonzalez, John [mailto:john.gonza...@intel.com]
Sent: Monday, December 2, 2013 10:54 AM
To: wix-devs@lists.sourceforge.net<mailto:wix-devs@lists.sourceforge.net>
Subject: [WiX-devs] New user and request
Hi all,
I just joined this list and am requesting an assignment agreement. I also have
an initial question to go along with it; we use v3.7 and I have made the source
changes locally for testing. When making changes on the trunk do I make them on
3.7 or the latest? If latest what is the difference between master and the
others?
Thanks,
JohnG
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
