Harvest using actual MSBuild? about issues

[robmen]

why heat.exe for this?

There were many things done in WiX v4, but improving the state of harvesting was not one of them. So, heat.exe was maintained in v4 to the extent that it could be

Is this something even on people's radar?

Absolutely. Notice was put out that heat.exe was on a path to obsolecence.

There are some ideas about how to finally deprecate heat.exe in WiX v5.

Is it something you'd like a contribution for?

At FireGiant, we released an advanced harvesting solution as a WiX extension. If this is something you are interested in implementing, you could do so in a similar way.

Or is there some reason the problem isn't approached in this way?

Solving harvesting correctly for all scenarios (not just the "always early major upgrade" scenario) requires careful handling of identifiers to ensure they are stable. That makes creating a general harvesting solution more complex than it seems like it should be. We've slowly been implementing features in WiX to make harvesting work properly in all scenarios.

[wasabii]

Ahh. Yes, I did not know about this extension. I will check it out.

My solution for IDs has been to hash the case-insensitive relative file path from the project, coupled with an identifier assigned per ProjectReference (which I actually called HarvestProjectReference in my code). So the user can import the project multiple times (including output from multiple TFMs, or RIDs, etc).

[wasabii]

Looking at the FireGiant thing, looks like it might be customizable for my needs, except I'd need to add some custom targets to the source projects, that collected publish output. Because the Core SDK doesn't quite populate the returns from the Publish target properly (AppHost gets left out for some reason). So, calling Publish, having it emit to a directory, and then collecting the output items, I've found, has always been necessary.

Also, doesn't really deal with RID negotiation, or have any sort of outer build structure. Hmmm.

Is there a reference to a place where your current thinking on a future approach (for WiX itself, not FG), might be?

[robmen]

except I'd need to add some custom targets to the source projects, that collected publish output.

FireGiant is a commercial company. We're responsive to customer requirements. Of course, that doesn't mean everything gets implemented, but customer input absolutely guides the way.

Is there a reference to a place where your current thinking on a future approach (for WiX itself, not FG), might be?

Future ideas for WiX are captured in WiX Improvement Proposals. The WIP I'm hinting at here has not been written yet since we're working through some pre-requisite ideas based on a new "wix stdlib". The conversations happen publicly during the WiX Online Meetings if you want to get into the weeds. Those meetings are also summarized on the FireGiant blog.