Conceptually the following is a good way to view the Binder (it is somewhat
simplified, so the usual caveats apply): in the WiX toolset the "native" file
formats are all based on XML (with a small smattering of ZIP) but the final
output files are mostly not that format. So the Binder is the component the
Linker uses to write the non-WiX-native files (like MSI, MST, EXE (in the case
of Burn), etc.). It's called the binder because it takes not just the output of
the Linker but also all the files referenced by the linker and "binds" them
into the final output file(s). What is happening here is that the Binder emits
a file indicating all of those referenced files (since if any of them changed
you need a re-link (or at minimum a rebind) to incorporate those changed files
into the output file. To enable correct incremental linking MSBuild needs to
have a list of the files that were incorporated by the binder into the output
file. However, some of those files may not exist after the linker is done (if
that portion of the temp folder was cleaned, for instance) and if MSBuild can't
find them it assumes that a rebuild is needed. So resetting timestamps will do
nothing for this issue. Devs: would moving @(_BindBuiltOutputs) from Outputs to
Inputs fix this issue? Or would it introduce some other subtle error?
-Blair From: r...@merlinia.com
To: wix-devs@lists.sourceforge.net
Date: Thu, 14 Mar 2013 18:05:05 +0000
Subject: Re: [WiX-devs] Project with merge modules defeating incremental
build facility
Yes, well, I'm sure you're right. I don't even know what the "Binder" is.
All I know is that when I started researching this, what I could see in the
MSBuild logs that marked the turning point of whether MSBuild ran the
Link task or not was a message where it said "All output files are up to date"
in the cases where it didn't run Link. And as far as I know MSBuild does not
keep track of whether there have been changes in the collection of files from
one build to the next,
it just blindly compares timestamps on the current input files vs. the current
output files.
Yours,
Rennie
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 14. marts 2013 18.32
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Project with merge modules defeating incremental build
facility
It's not a timestamp issue. The file paths change everytime so there are always
a set of files that were removed and a set of files that were added. Even if
the timestamps were correct (they may be) the add/remove makes it look like a
lot
of changes. So, the Binder would need to taught to recoginize the files from
Merge Modules much as I described above.
On Thu, Mar 14, 2013 at 9:53 AM, Rennie Petersen <r...@merlinia.com> wrote:
I'm not sure I understand - I had assumed that the BindContentsFileList was a
list created
by WiX as part of the build.
Anyway, it is correct that the three temporary files get different names on
every build.
I've attached some of them for your viewing pleasure.
I'm still thinking that the way to fix this is to set the timestamps on those
temporary files to
equal the timestamp on the merge module file, but what do I know?
Yours,
Rennie
From: Rob
Mensching [mailto:r...@robmensching.com]
Sent: 14. marts 2013 15.55
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Project with merge modules defeating incremental build
facility
My bet is that the mergemod.dll is extracting the contained files to a random
temp location. Thus every time the Merge Module is merged, the
BindContentsFileList gets a different
set of file names and thinks things are out of date. If you could confirm
that, that'd be awesome.
If my guess is correct, the fix is to probably to add the paths to the merge
modules to the BindContentsFileList *instead of* the files in the merge modules.
On Wed, Mar 13, 2013 at 12:11 PM, Rennie Petersen <r...@merlinia.com> wrote:
> This conversation is better for wix-devs,
OK.
> short answer: no WiX does not create those files. The mergemod.dll from the
> MSI SDK creates those files
Hmm, but WiX must get the filenames of the three files since they end up on the
projectName.BindContentsFileListextension.txt list of files.
So again, what you should do with those three temporary files is to set their
timestamp to the timestamp of the merge module file.
That should solve the problem.
Yours,
Rennie
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
