Harvesting for hotfixes

[vkpabba]

Question

Hi everyone,

I’m trying to clarify the recommended approach for handling files in WiX when building hotfixes/patches (MSP)—specifically whether to use heat.exe (harvesting) or the newer Files element.

Context

For hotfixes, component GUID stability is non-negotiable. Any change in GUIDs (or component structure) can break patch applicability or cause repair/reinstall issues.

Both heat.exe and Files make file inclusion easier, but they also introduce some uncertainty around how GUIDs are generated and maintained over time.

---

My questions

1. Between heat.exe vs Files element, which is safer/recommended for patch-friendly authoring?

2. How does the Files element handle component GUID generation and persistence across builds?

3. Is it safe to rely on either of these in a long-term servicing model (RTM → updates → hotfixes)?

4. What are the best practices here:

   • Harvest once and freeze the generated output?
   • Use Files but explicitly control GUIDs?
   • Or avoid both and author components manually for patchable resources?

---

My current understanding (please correct me if I’m off)

• Auto-generated GUIDs (especially from heat.exe with -gg) are not suitable for patches
• Even small changes in harvested output (file order, structure) can lead to GUID churn
• Stable component identity is more important than convenience in patch scenarios

---

If anyone has experience using:

• Files element or heat in WiX for patch scenarios
• Harvesting strategies that don’t break GUID stability
• Or general best practices for patch-safe file authoring

I’d really appreciate your guidance or examples.

Thanks!

Open Source Maintenance Fee

• I (or an organization I'm a member of) pay the Open Source Maintenance Fee by sponsoring the wixtoolset project because I support the maintainers.

[cookesan]

For MSP/hotfix servicing, the safe rule is: do not let harvesting change component identity after RTM.

heat.exe and Files are authoring conveniences. The patchability question is still Windows Installer component identity: stable component GUID, stable key path, stable component rules. The WiX docs for Component/@Guid say Guid="*" can generate a stable GUID only under specific key-path conditions, and the Heat docs distinguish -ag (Guid="*") from -gg (generate GUIDs when Heat runs). Re-running Heat with -gg is especially risky for servicing because it can rewrite identities.

For a long-term hotfix model I would use this order of preference:

1. author patchable components explicitly for the serviced payload
2. harvest once, review the output, then freeze it as source
3. use generated authoring only if CI proves component ids, GUIDs, key paths, and file-to-component mapping did not drift

If you use Files, I would still add a build check that compares the built MSI tables or harvested output against the RTM baseline. The important gate is not "Heat versus Files"; it is "can this build prove that component identity did not change for patchable resources?"

[vkpabba]

@cookesan - Thanks for clarifying! The principle makes sense: prove component identity stability, regardless of the tool.

Quick follow-up: Since Files element generates components at compile time (no intermediate .wxs with explicit elements), does that mean Option 2 (harvest once, then freeze) only works with heat.exe?

In other words, for servicing models where we need to freeze after RTM, is heat.exe -ag safer than Files because it produces freezable output?

[cookesan]

Yes, harvest once, then freeze is more naturally a Heat or explicit-component workflow, because there is a .wxs artifact to review and keep under source control.

One nuance: heat -ag does not freeze concrete GUID values in the source. It emits Guid="*", so WiX still generates the component GUID at compile time under the normal generated-GUID rules. That can be fine when the component key path and directory identity are stable, but the thing you are freezing is the authoring shape: component ids, key paths, file membership, and directory mapping. heat -gg writes concrete GUIDs when Heat runs, so rerunning it after RTM needs the same kind of careful diff review.

Files is not automatically unsafe just because it expands during build, but it gives you less source text to freeze. If you use it in a servicing model, I would move the proof to CI by comparing the built MSI tables against the RTM baseline: Component, File, key paths, component GUIDs, and file-to-component mapping.

So I would not phrase it as "heat -ag is universally safer than Files." I would phrase it as: Heat or explicit components are easier to audit as frozen source; Files needs an output-table stability check to give you the same confidence for MSP/hotfix servicing.

[robmen]

This is pretty good advice. In general, if you're going to be patching, you need to be very, very precise about your code as MSPs have lots of restrictions about what can (and cannot) change from patch to patch. Patches are a very advanced Windows Installer topic.