MGCB Content Pipeline: Cache Invalidation during Global Property Changes

The MonoGame Content Builder (MGCB) does not track changes to global project properties within the .mgcb file as a trigger for asset re-processing. The build-cache system is primarily designed to monitor the timestamps of individual source assets; therefore, modifying a global configuration while leaving source files untouched will typically result in the pipeline skipping the rebuild of existing .xnb files.

Cache Behavior and Global Properties

In MonoGame 3.8+ and the mgcb-editor tool, the dependency graph is asset-centric. While the .mgcb file defines the environment, the pipeline does not treat the project file itself as a global dependency for every single asset's cache key. This creates a scenario where global flags (such as platform targets or general build parameters) can be updated in the XML, but the resulting binaries remain stale because the source asset timestamps have not advanced.

Recommended Synchronization Method

To ensure all assets are synchronized with global configuration changes without performing a full manual Clean (which deletes all binaries and forces a total rebuild), you can use a "touch" strategy to trick the timestamp-based invalidation system.

The most efficient way to force a rebuild of all assets is to update the modification date of the source assets. On a Unix-like system or via PowerShell, you can recursively update the timestamps of your content folder:

# PowerShell example to touch all source assets
Get-ChildItem -Path "./Content" -Recurse | ForEach-Object { $_.LastWriteTime = Get-Date }

After running this command, the next MGCB build execution will detect that every source asset is "newer" than its corresponding .xnb output, forcing the pipeline to re-process them using the updated global properties.

Verification Steps

1. Modify a global property in your .mgcb file.
2. Run the build tool and observe the output; if assets are skipped, the cache is not invalidating.
3. Apply the timestamp update (touch) to the source directory.
4. Run the build tool again to verify that all assets are now being re-processed.

Diagnostic Note: Are you utilizing a custom build script or a CI/CD pipeline to trigger MGCB? If the build is being called via a specific wrapper, the wrapper may be caching the .mgcb file state independently of the MGCB tool itself.