Thank you for merging Solution Explorer into native Explorer view

[Yetenol]

This is positive feedback. I love that C# is moving towards the filesystem as source of truth with features like file-scoped namespaces, file visibility modifier, and file-based apps. And now in C# Dev Kit we move from the weird solution view that needed MSBuild to load, to showing the file tree which is always available. For instance, it was always weird that deleting a project in the solution view only removed the .slnx reference, but didn't delete the files on disk. Coworkers accumulated orphaned projects that shouldn't be in git anymore. All programs like VS Code, Visual Studio, git, and agents refer to files by path and name and adhere to .gitignore. The solution explorer is another concept that may not represent the actual file tree used by git, CI, etc. As you correctly pointed out, many probably never discovered or needed the solution explorer. Now all useful functionality is integrated into the native explorer view. For dependencies I prefer dotnet list package --vulnerable or dotnet outdated --upgrade --version-lock major anyway over the solution explorer's dependency display, so I don't need the c# Project Details anyway.

Overall, a great change.

[Sebastriani]

I use both Solution and File Explorer, when I think "Domain" I use Solution Explorer, when I think "Files" I use File Explorer, each of them have (or better said had) their use case.

Enhancing the File Explorer is perfectly fine, but not at the expense of ruining the Solution Explorer.

Stop looking only at your own use case and consider the rest of the community.

[Quickern]

“Hello World” looks great now!

Seriously though, I have a multi-solution project with hundreds of projects, and now I can’t view them in a structurally sane way.

[reidanderson-rh]

Extension is basically useless for my use case now without solution explorer.

[mxcolin]

This is positive feedback. I love that C# is moving towards the filesystem as source of truth with features like file-scoped namespaces, file visibility modifier, and file-based apps. And now in C# Dev Kit we move from the weird solution view that needed MSBuild to load, to showing the file tree which is always available. For instance, it was always weird that deleting a project in the solution view only removed the .slnx reference, but didn't delete the files on disk. Coworkers accumulated orphaned projects that shouldn't be in git anymore. All programs like VS Code, Visual Studio, git, and agents refer to files by path and name and adhere to .gitignore. The solution explorer is another concept that may not represent the actual file tree used by git, CI, etc. As you correctly pointed out, many probably never discovered or needed the solution explorer. Now all useful functionality is integrated into the native explorer view. For dependencies I prefer dotnet list package --vulnerable or dotnet outdated --upgrade --version-lock major anyway over the solution explorer's dependency display, so I don't need the c# Project Details anyway.

Overall, a great change.

Burner account for whoever thought this was a good idea. Insane.

[alexandreperes70-stack]

“Hello World” looks great now!

Seriously though, I have a multi-solution project with hundreds of projects, and now I can’t view them in a structurally sane way.

I'm new to using VS Code, and since I don't know how to use projects and solutions in the file explorer, to solve my problem for now, I simply went to the extensions, disabled auto-update, and installed version 3.10.14.

[joshardt]

Relying on the Solution Explorer feels wrong to me. It's a constructed concept of showing files differently to you, error prone and it even hides files. The only source of truth is the file system. However, good UX accepts duplicates and sometimes bad decisions in favor of user needs. That makes people who were used to the Solution Explorer angry. I've seen that the ReSharper extension also offers a Solution Explorer. Maybe it's a good alternative for now. However, I encourage every developer to use the Single Source of Truth: The file system. Maybe take this chance to get used to it. I promise that you won't regret it.

[mxcolin]

“Relying on the Solution Explorer” feels wrong to YOU. I’m sure the Dev who decided to enshitify this just went with vibes too. The Solution Explorer paradigm has been used successfully for decades. I’ve restored the old version. Won’t be moving off
It until this shit show is resolved.

[Quickern]

Relying on the Solution Explorer feels wrong to me. It's a constructed concept of showing files differently to you, error prone and it even hides files. The only source of truth is the file system. However, good UX accepts duplicates and sometimes bad decisions in favor of user needs. That makes people who were used to the Solution Explorer angry. I've seen that the ReSharper extension also offers a Solution Explorer. Maybe it's a good alternative for now. However, I encourage every developer to use the Single Source of Truth: The file system. Maybe take this chance to get used to it. I promise that you won't regret it.

You’re just wrong. Maybe you’ve never worked with complex solutions — I don’t know.

Look, the file system view and the solution view represent the same project in two different ways. The solution/.csproj view reflects how the compiler actually sees the project, with all the filtering, grouping, and configuration options applied. It doesn’t contradict the file system view — it complements and refines it.

A simple example: bin and obj directories. Do you need to see them all the time? Do you want results from obj/ appearing in search? Probably not. Sure, you can configure VS Code to ignore those directories.

But now extend that idea further. For every rule or option already defined in .csproj, you now need to duplicate the same behavior in workspace configuration files — assuming that’s even possible.

And then add teammates using different IDEs. That’s completely normal; people use whatever tools they prefer.

What about files that shouldn’t really exist as separate visual units? xaml.cs is a perfect example. It’s useful when related files can be grouped or collapsed into a single logical unit in the UI.