Harvest using actual MSBuild?

[wasabii]

Unsure whether this counts as a bug, or a feature request, or just something I find obnoxious.

For the longest time, I've maintained my own custom MSBuild SDK project type for Wix3. Part of my custom project type is an implementation of harvest that uses actual ProjectReferences. Correctly. By invoking the Publish target of them, and collecting the publish output into an ItemGroup, which gets fed into a process to generate a wxs file. That is, I'm not spawning a separate executable, that causes a secondary out of node build process.

I fully expected Wix4's new SDK project type to take this approach. And am pretty surprised that it does not. It still uses heat.exe to launch a separate process, which kicks off a distinct MSBuild? Thus causing duplicate MSBuilds, causing errors with files getting clobbered, and timeouts since files are already in use.

So I guess my question is.... why heat.exe for this? Is this something even on people's radar? Is it something you'd like a contribution for? Or is there some reason the problem isn't approached in this way?

Because as of now, this kinda seems a little useless for proper modern Core projects. There's no way I can figure out to capture the output of a .NET Core project.... including the R2R phase, trimming, or NativeAOT. Which happens during the publish phase. And of course, the AppHost executable is not available either.

[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.