.lscache FAQ
We've heard a lot of great feedback on .lscache files and wanted to put together a central place to address common questions. Thank you to everyone who has taken the time to share your thoughts -- it's genuinely helping us shape this feature.
What are .lscache files?
.lscache files are lightweight caches that store project metadata next to your .csproj files. They contain project structure information like references, target frameworks, and output paths -- no source code or secrets. They allow C# Dev Kit and potentially other clients to skip expensive processing on startup, providing near-instant project loading.
What's the vision here?
We want opening a .NET project in VS Code to feel instant. Today, C# Dev Kit has to do a lot of processing similar to a build itself before it can offer completions, diagnostics, navigation, test discovery, or even know which projects you can debug. On large solutions that can take a long time -- and it happens every single time you open VS Code, switch branches, or spin up a worktree.
.lscache files change that. With caches present, C# Dev Kit can light up immediately using cached data and then silently refresh in the background. The goal is that you open your project and everything just works -- no loading spinner, no waiting for the build system.
And this is just the beginning. Once we have the caching layer in place, it unlocks further optimizations for memory and build times. And it's not just VS Code -- other tools in the .NET ecosystem often need the same project metadata. These caches could be leveraged by any tool that wants to understand your project structure without running a full evaluation.
How big are the performance improvements?
We're seeing about a 70% reduction in startup time today, and upcoming changes will bring significant memory reductions as well. The caches let C# Dev Kit start providing results without needing to do a bunch of builds that require a lot of processing power and memory.
Why are they next to my project files?
We know this is the part that's generated the most discussion, and the feedback is totally valid. Here's the thinking behind the current placement:
- Branch switching becomes a warm start. When caches live in the repo, switching branches means C# Dev Kit can immediately use cached data for that branch instead of rebuilding from scratch.
- Worktrees are a warm start too. Spin up a new worktree and you get instant language service instead of waiting for a full cold evaluation.
- Clone and go. Clone a repo that has caches checked in and all C# Dev Kit features should be available fast!
- Stale caches are still valuable. They don't need to be perfect. The next successful build brings them up to date.
Why not put them in the obj folder?
Several people have suggested this and it's a reasonable idea. Unfortunately, .csproj, .targets, .props, and other build files can all change the obj location, so we don't actually know where the obj folder is on initial startup. Finding out requires expensive processing, which is exactly the operation these caches are designed to skip.
Can I put them in a temp directory?
Yes. If you set dotnet.projectsystem.cacheInProjectFolder to false in your VS Code settings, caches will be written to a temporary location, away from your workspace. Note that any existing .lscache files on disk will continue to be read and updated, in order to preserve the benefits of committing caches to version control.
What if I don't want them in source control?
We'd encourage you to try checking them in and experience the benefits, but we understand not every team will want that. You can add .lscache to your .gitignore if you prefer. You'll still get the per-machine caching benefits (warm starts when reopening the same project), you just won't get the cross-machine and branch-switching benefits. We're exploring configuration options to give users more control here.
What about merge conflicts?
We hear this concern. The file format is designed to minimize merge conflicts (think .slnx rather than .sln). And even if a conflict does happen, it's okay if the file ends up outdated or incomplete -- it will get resolved automatically by tooling or the next build.
Is this final?
No! This is a prerelease experiment and nothing is set in stone. We're exploring options like feature flags and configuration settings, but our approach is to start with the simplest, least complex version first and then respond to your feedback. Your input on this thread and others is directly influencing the direction we take. We'll keep iterating over the next several prereleases.
How can I help?
If you're on prerelease, we'd love for you to be part of shaping this feature:
- Try checking the caches in and see how it feels across branch switches, fresh clones, and worktrees. This is where the biggest benefits show up.
- Time your startup you should see significant improvement now and even more in future releases.
- Keep giving us feedback. Tell us what works, what doesn't, and what surprised you. Every piece of feedback is helping us get this right.
We'll also be linking to this issue from the .lscache files themselves, so as more people encounter them in future prereleases they can find this context and share their feedback too.
If you want to be an early adopter of the vision -- instant project open, warm starts everywhere -- this is your chance to help shape how we get there.
Thank you for going on this journey with us.
.lscache FAQ
We've heard a lot of great feedback on
.lscachefiles and wanted to put together a central place to address common questions. Thank you to everyone who has taken the time to share your thoughts -- it's genuinely helping us shape this feature.What are .lscache files?
.lscachefiles are lightweight caches that store project metadata next to your.csprojfiles. They contain project structure information like references, target frameworks, and output paths -- no source code or secrets. They allow C# Dev Kit and potentially other clients to skip expensive processing on startup, providing near-instant project loading.What's the vision here?
We want opening a .NET project in VS Code to feel instant. Today, C# Dev Kit has to do a lot of processing similar to a build itself before it can offer completions, diagnostics, navigation, test discovery, or even know which projects you can debug. On large solutions that can take a long time -- and it happens every single time you open VS Code, switch branches, or spin up a worktree.
.lscachefiles change that. With caches present, C# Dev Kit can light up immediately using cached data and then silently refresh in the background. The goal is that you open your project and everything just works -- no loading spinner, no waiting for the build system.And this is just the beginning. Once we have the caching layer in place, it unlocks further optimizations for memory and build times. And it's not just VS Code -- other tools in the .NET ecosystem often need the same project metadata. These caches could be leveraged by any tool that wants to understand your project structure without running a full evaluation.
How big are the performance improvements?
We're seeing about a 70% reduction in startup time today, and upcoming changes will bring significant memory reductions as well. The caches let C# Dev Kit start providing results without needing to do a bunch of builds that require a lot of processing power and memory.
Why are they next to my project files?
We know this is the part that's generated the most discussion, and the feedback is totally valid. Here's the thinking behind the current placement:
Why not put them in the obj folder?
Several people have suggested this and it's a reasonable idea. Unfortunately,
.csproj,.targets,.props, and other build files can all change theobjlocation, so we don't actually know where theobjfolder is on initial startup. Finding out requires expensive processing, which is exactly the operation these caches are designed to skip.Can I put them in a temp directory?
Yes. If you set
dotnet.projectsystem.cacheInProjectFoldertofalsein your VS Code settings, caches will be written to a temporary location, away from your workspace. Note that any existing .lscache files on disk will continue to be read and updated, in order to preserve the benefits of committing caches to version control.What if I don't want them in source control?
We'd encourage you to try checking them in and experience the benefits, but we understand not every team will want that. You can add
.lscacheto your.gitignoreif you prefer. You'll still get the per-machine caching benefits (warm starts when reopening the same project), you just won't get the cross-machine and branch-switching benefits. We're exploring configuration options to give users more control here.What about merge conflicts?
We hear this concern. The file format is designed to minimize merge conflicts (think
.slnxrather than.sln). And even if a conflict does happen, it's okay if the file ends up outdated or incomplete -- it will get resolved automatically by tooling or the next build.Is this final?
No! This is a prerelease experiment and nothing is set in stone. We're exploring options like feature flags and configuration settings, but our approach is to start with the simplest, least complex version first and then respond to your feedback. Your input on this thread and others is directly influencing the direction we take. We'll keep iterating over the next several prereleases.
How can I help?
If you're on prerelease, we'd love for you to be part of shaping this feature:
We'll also be linking to this issue from the
.lscachefiles themselves, so as more people encounter them in future prereleases they can find this context and share their feedback too.If you want to be an early adopter of the vision -- instant project open, warm starts everywhere -- this is your chance to help shape how we get there.
Thank you for going on this journey with us.