MonoGame 3.8 Content.Load<T> cache invalidation across processor version changes

The premise needs correcting before the questions can be answered: in MonoGame 3.8, Content.Load<T> does not cache compiled assembly references keyed by processor version, and there is no CacheVersion attribute in the .mgcb format or in ContentManager. What actually exists is much simpler: each ContentManager instance keeps an in-memory dictionary keyed by the asset name string you pass to Load<T>, so repeated loads of the same asset return the same instance. That dictionary lives only for the lifetime of the process (or until Unload()). This reflects the long-standing ContentManager design; if exact internals matter, confirm against the 3.8 source (Content/ContentManager.cs).

Answers to the three questions

Do content root path changes invalidate the cache?

RootDirectory only affects how asset names are resolved to file paths; it is not part of a version-aware cache key. Each ContentManager has its own private cache, so two managers with different root directories never share entries, and there is no cross-project cache collision of the kind described. Because the cache is per-process, restarting the game always re-reads whatever .xnb files are on disk.

Is CacheVersion the invalidation mechanism?

No — it does not exist. There are also no implicit version comparisons at runtime: Content.Load<T> has no knowledge of processor versions, pipeline metadata, or type descriptors. Versioning happens entirely at build time, when MGCB recompiles your content into .xnb files. You can verify this by searching the MonoGame repository and the .mgcb schema for "CacheVersion" — nothing will turn up.

Does Windows-to-Android compression divergence cause silent type mismatches?

No silent mismatches, but for a different reason: .xnb files are platform-specific binaries and are generally not portable. Texture compression formats, graphics profile (Reach vs HiDef), and platform targets (DesktopGL vs Android) all change the output, so content must be rebuilt per platform. Loading a mismatched or corrupt .xnb typically throws ContentLoadException rather than silently deserializing wrong types.

Why rebuilt content looks stale — the real cause

If you rebuild the .mgcb with changed processor settings and the game still shows old assets, the cause is almost always build/deploy, not a runtime cache:

1. The pipeline tool did not actually rebuild (check timestamps on the .xnb in the pipeline output folder).
2. The new .xnb was built but not copied to the game's output directory — verify the .mgcb is wired into your .csproj and the build action copies content.
3. On Android, the old .xnb is still packaged in the APK/AAB; do a clean rebuild and full redeploy, since incremental deploys can skip unchanged-looking assets.

A quick diagnostic: delete the game's output directory (bin/), rebuild everything, and rerun. If the asset updates, the runtime cache was never the problem. If it still doesn't, the .xnb itself wasn't regenerated — inspect the MGCB build log.

If you are genuinely seeing stale type descriptors survive a full clean rebuild and redeploy, that would contradict the design above — in that case, the one detail worth sharing is the exact MonoGame version and a minimal repro, because it would point to something outside stock ContentManager behavior (for example, a custom content manager or serializer).