timheuer
commented
7 months ago @aboimpinto THanks for the thoughtful feedback. This is a mix of ideas and some areas you look like you are experiencing failures. If I could ask you to log independent issues on those items it helps isolate the discussion, triage, resolution to specific items and enables others facing similar issues to see that conversation. It's harder in grouped feedback like this...but we do appreciate the thoughts...
A few quick replies here from me:
Project load and symbol -- this sounds like you are seeing failures, we should get specific with a use case if repeatable and track it down. (@arkalyanms)
Debugging -- I feel you. VSCode has multiple entry points to run/debug your workspace. In the extension we've aimed to make this easy for .NET developers, not requiring launch/task json files to manage. If those are present they take precedent, else we have a 'dynamic' debugger that we integrate with these various entry points. Some of these experience rely on VSCode patterns (e.g., if you have a file open and use the editor button, it is operating on that file info, not the workspace). This is an area we are continually trying to improve...more changes to come here from our extension. (@WardenGnaw / @tmeschter)
Perf degradation -- again, if you see specifics, it would be good to see the actual specifics here so we can analyze (/cc @arkalyanms)
Namespace structure -- I believe this suggestion was already made and something we're looking at.
File add-on. -- I'm confused as you can create new file (I assume you mean templated ones). The reason it's exposed now via SE is that in just a regular workspace we don't know which project, etc. you may want to add it to -- but probably something we can surface up the existing command to the command pallette -- would be another good independent enhancement request to make (/cc @smitpatel)
Test explorer -- I'm confused as this indeed exists. VSCode now has integrated test explorer and we've provided the test adapter to integrate into that experience. Where appropriate we integrate with the 'shell' capabilities of VSCode as a principle. See https://code.visualstudio.com/docs/csharp/testing#_test-explorer
Modularization -- this is more of a principle approach to how we have the extension and our plans. If you want just language features, you don't need the Dev Kit. But the Dev Kit is intended to bring more capabilities together.
Add-ons -- Maybe I assume you are meaning IntelliCode (as we don't have others). IntelliCode is one of those modular things that is independent and separate (and can be installed separately -- FYI we're likely to make changes here not including it in our installer)
Thanks for the thoughtful remarks, let's separate some issues so we can independently resolve/action them.
aboimpinto
arkalyanms
smitpatel
webreidi
Describe the Issue
Dear C# Dev Kit Community,
I want to address some persistent bugs and suggest improvements for the C# Dev Kit in Visual Studio Code. As a developer using this extension regularly, I've encountered several issues that hinder productivity and overall usability. Here are the problems I've faced:
Project Loading and Symbol Recognition: Occasionally, the Dev Kit fails to load projects correctly and doesn't recognize symbols throughout the solution. Even after restarting VSCode, this issue persists, sometimes requiring a full system restart to resolve. It's a frustrating experience that interrupts workflow unpredictably.
Debugging Functionality: The functionality of F5, F10, and F11 during debugging could be more consistent. Despite proper compilation and attempts to run the project, these keys often fail to execute their intended actions, leading to confusion and wasted time in troubleshooting.
Performance Degradation: With each update, the C# Dev Kit consumes more memory and introduces significant sluggishness to the entire system. This contradicts the original purpose of using VSCode as a lightweight alternative to full-fledged IDEs like Visual Studio.
Namespace Structure in Solution Explorer: When creating a new class in Solution Explorer, the Dev Kit doesn't follow the folder structure to determine the namespace. This oversight disrupts the organization and makes maintaining a coherent project structure cumbersome.
Lack of Official File Creation Add-on: It's puzzling why there isn't an official add-on for creating files like classes and interfaces directly from Explorer. Instead, the current implementation in the Solution Explorer feels inadequate and needs to be in sync with user expectations.
Missing Test Explorer: An official, installable Test Explorer needs to be present. While alternative options exist, the absence of an official solution leaves users searching for reliable testing integration elsewhere.
Suggestions for Improvement:
Modularize New Features: New features, such as the "Solution Explorer," should be offered as optional add-ons rather than being integrated directly into the Dev Kit. This approach maintains the lightweight nature of VSCode while allowing users to tailor their development environment to their needs.
Avoid Mandatory Add-ons: While add-ons can enhance functionality, they shouldn't be mandatory installations. Encourage modularity by offering a suite where users can choose which add-ons to install, ensuring a more customizable experience without unnecessary bloat.
As a developer working with .NET applications on various operating systems, including Linux and Windows, these issues persist across different environments. I urge the development team to prioritize resolving these issues and making the C# Dev Kit more user-friendly and efficient.
Let's work together to make the C# Dev Kit in VSCode the best tool it can be for the entire community.
Steps To Reproduce
No response
Expected Behavior
the add-on just work as expected and better than Omnisharp.
Environment Information
Linux (Ubuntu and Manjaro) Windows 11