[SUGGESTION] C# is a second class citizen in vscode (.sln files are workspaces NOT folders in .NET)

[zezba9000]

Describe the feature you'd like

.sln files are workspaces in .NET NOT folders

• No way to open .sln files without opening folders first (feels like C# is now a second class citizen)
• No NuGet management without using command line?
• No way to manage .csprojs in solution
• No way to unload .csprojs in solution
• No way to manage solution level build configs
• OmniSharp doesn't load .csproj or .sln build configs for debuging
• Building an IDE around HTLM/JS/TS was a huge mistake.
• Making users sign into MS accounts is a huge mistake.
• Most serious cross-platform dev is now going to be using Rider as VScode is a massive IDE regression from MonoDevelop.
• Long run this could actually do harm to C# as a language because it now feels like a alien to the IDE and a second class citizen.

Alternatives considered

• Get rid of the hack that is OmniSharp and use standards around MSBuild
• Make a new .sln alternative thats human readable & foundational to the Roslyn compiler
• vscode needs to conceptualize workspaces around what extensions feed it not what folder is open
• Make a new IDE built on C# & AvaloniaUI that actually functions like a normal IDE

In short vscode is hacky, confusing and a poor experience to what was & you need a elegant system for dealing with .csproj files that don't live within a folders scope.
The .sln file has been a core part of .NET dev for 20 years. Yet ppl on the vscode team seem to pretend this doesn't matter.
vscode is now trying to be an IDE when it is so fundamentally flawed for the task when it comes to complex workspace scoping issues, it makes zero sense at a fundamental level.

In fact this scoping issue is such a big problem it now means any lang that supports scoping files outside a folder now have to deal with these kinds of IDE disparities.

Environment Information

Win, Mac & Lin

[timheuer]

Thanks for moving this to issue here so we can engage better, really appreciate that! We may break these out separately as this is a compound issue with many suggestions!

• No way to open .sln files without opening folders first (feels like C# is now a second class citizen)

It definitely is a different experience than a full IDE as an editor-first experience where extensions light-up more functionality. This is not likely to change soon.

• No NuGet management without using command line?

This is issue: #62

• No way to manage .csprojs in solution

Can you explain a bit more here -- is this Property Pages basically? This is #294 (says target frameworks, but more about all properties)

• No way to unload .csprojs in solution

Would solution filters work for you here?

• No way to manage solution level build configs

This is #67

• OmniSharp doesn't load .csproj or .sln build configs for debuging

Since OmniSharp isn't a part of the C# Dev Kit, can you explain this one more?

• Making users sign into MS accounts is a huge mistake.

All functionality is enabled without signing in. Enterprise customers should sign-in for their support and license agreements.

[Ghostbird]

Personally I greatly enjoy the move away from the archaic .sln file as workspace definition to something that in my opinion is more logical and more generic. To me C# feels like a second class citizen, not because of this, but because of the weird focus part of Microsoft's management has on steering people towards Visual Studio (sell licences) which causes them to not implement, or even remove, features that were available in VSCode / non-Visual Studio integrated tooling. (e.g. the dotnet watch debacle)

Historically I'm sure you're right, but I've always hated the .sln treatment in Visual Studio. To me, the workspace is the folder, and the .sln file is just one of many configuration files in such a workspace. An important one to be sure, but in many cases there's no single .sln file that forms the root of a workspace and applies to all of it.

Not being open source is my main gripe with the C# Dev Kit, and the primary reason for not using it. However, constantly being pestered to sign-in to to a Microsoft account is actually the reason why I uninstalled it after trying it for a few hours. I'm only using the more open ms-dotnettools.csharp at the moment.

My opinion of .csproj files is much the same. I always hated the loading/unloading them to edit something that in my opinion was an XML configuration file. I'm guessing it's because I normally use Linux based systems, my mind is more geared to the "everything is a file" and "do one thing and do it well" philosophy, where you use a modular approach with many separate files and tools. It seems you're more used to the integrated experience that Visual Studio offers.

[Leonardo-Ferreira]

Now that MS is abandoned VS for Mac, "the weird focus part of Microsoft's management has on steering people towards Visual Studio (sell licences)" does not stick... this is a blunder all together, and MS is basically handing off all of its devs to Rider... was VS for MAC excellent? no, but it is way better than VS Code + C# Dev Kit...

[timheuer]

constantly being pestered to sign-in to to a Microsoft account

You should not be constantly pestered. We show one notification but after dismissal it should not be constantly popping up.

[zezba9000]

Can you explain a bit more here -- is this Property Pages basically? This is #294 (says target frameworks, but more about all properties)

Sorry that wasn't clear. For this I meant no way to manage what build config a particular project uses when building a solution.

Would solution filters work for you here?

I don't see any docs for this outside Visual Studio? It might work if it doesn't take 30 minutes to hunt for docs. But normally the reason for unloading projects is because you're trying to debug working projects in a solution but need to stop compiling broken ones while you're trying to reduce error complexity in the middle of things.

Since OmniSharp isn't a part of the C# Dev Kit, can you explain this one more?

The C# extension is a dependency of DevKit which uses OmniSharp correct?
In short OmniSharp has its own build system and doesn't even understand how to build from a .sln file. Maybe I'm misunderstanding the projs here but MSBuild system already exists and is open-source. OmniSharp being used in vscode just makes things annoying when other IDEs use MSBuild. Am I confusing something here?

All functionality is enabled without signing in. Enterprise customers should sign-in for their support and license agreements.

I was under the impression this was blocking DevKit from functioning.

[zezba9000]

Personally I greatly enjoy the move away from the archaic .sln file as workspace definition to something that in my opinion is more logical and more generic.

A folder is not a solution alternative to the .NET platform. Its just a lack of one. Is there another way to emulation solution files without solution files? And that works across all IDEs? (Not some OmniSharp hack in short)

To me, the workspace is the folder, and the .sln file is just one of many configuration files in such a workspace

This is not possible for complex setups. For example if you have .csproj files that are pulled and referenced outside the folder scope. There are very good reasons for this, particularly frameworks. Without a solution file a config file of some kind is needed to say what projects get loaded when opening a solution folder. This has always been the .sln file.

Not being open source is my main gripe with the C# Dev Kit, and the primary reason for not using it.

Ya that makes literally no sense. Maybe from key logging to feed into AI idk.

I always hated the loading/unloading them to edit something that in my opinion was an XML configuration file

This only applied to NETFW not NET-CORE

It seems you're more used to the integrated experience that Visual Studio offers.

No reason to waist time with endless amounts of hacky tools that take longer to do that same work.