Question
Stale MEF cache in Visual Studio: devenv /updateconfiguration or deleting ComponentModelCache?
Nia Indigo
0 reputation · 22 Nov 2024, 14:13 UTC
89.1K views1
Loading…
0 reputation · 22 Nov 2024, 14:13 UTC
After an extension is installed, updated, or uninstalled, Visual Studio's MEF component-model cache can serve stale composition results: IntelliSense returns outdated completions, extension commands disappear from menus, or editor features misbehave. Microsoft's documentation offers two rebuilds, and choosing between them is left to the user.
The lower-impact option is the documented devenv /updateconfiguration switch, which forces the IDE to merge installed packages and refresh the cache while preserving user settings and per-instance state. The heavier option is closing the IDE and deleting only the ComponentModelCache subfolder under %LocalAppData%\Microsoft\VisualStudio\<version-instance>, which regenerates on next launch and can clear corrupted or wedged state the switch may not reach.
Neither approach uninstalls extensions or touches project files, and both rebuild from installed components. However, no documented automatic invalidation covers every extension update or uninstall path, and no command reports whether the cache is stale. Switch support and folder naming can also vary by edition and update, so the installed instance needs confirmation before acting.
Is /updateconfiguration intended as the first-line fix for staleness, with folder deletion reserved for suspected corruption? Are there documented cases where the switch alone cannot recover a wedged cache? And is there any supported way to tell whether the cache is stale before rebuilding at all?
30775 reputation · 22 Nov 2024, 21:53 UTC
Yes, devenv /updateconfiguration is the documented first-line fix for MEF cache staleness after extension install, update, or uninstall. Deleting the ComponentModelCache folder is the heavier fallback for suspected corruption or wedged state that the switch cannot clear.
visualstudioComponentModelCache forces a from-scratch regeneration on next launch. This clears residual MEF parts that may remain wedged after package merges, but it also discards per-instance cached composition results, causing a slower first startup while extensions re-compose.%LocalAppData%\Microsoft\VisualStudio\<version>\<instance>\ComponentModelCache) vary by edition (Community/Professional/Enterprise), update channel (Monthly/LTSC), and instance name. Using the wrong path or an unsupported switch variant produces no effect.devenv /updateconfiguration and wait for it to return.ComponentModelCache folder for that specific instance, then restart.Which exact Visual Studio edition, version, and instance name are you targeting? (Find it via Help → About Microsoft Visual Studio or by listing %LocalAppData%\Microsoft\VisualStudio\.) This confirms the correct devenv path and cache folder before you act.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.