Open aboimpinto opened 9 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.
@timheuer, thanks for the answer ... Regarding monitoring the usage... those issues that need some monitoring happen several times a day and are sporadic... Just pain over pain! Maybe you can publish a video about how we can monitor VSCode and export the logs that you need. I have no idea how to do that!
Regarding the File Creation, I'm talking about file creation over the Explorer and not the Solution Explorer. Having one that works by putting the correct namespace would be nice.
Test Explorer ... maybe I should have noticed that.
Modulization: right now, I cannot just install the Language Server... the entire Dev Kit is installed, and with that, degradation (I have a last generation processor with 128GBytes of RAM)
Everything else ... thanks for acknowledging it. It was just an exercise in expelling the demons inside me, and it's nice that "god" (mean you, but it could be anyone in charge) is listening.
thanks Paulo
PS: I miss your videos.. they were great
Maybe you can publish a video about how we can monitor VSCode and export the logs that you need. I have no idea how to do that!
I've thought this a good idea as well to a permalink the "can you get the logs for us" instructions -- will see how quickly we can do that formally or informally (cc: @webreidi)
right now, I cannot just install the Language Server
So if you just want C# language features, that's the C# extension (https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp). We hope that you'd find value in other things in the dev kit (e.g., test), but if you just want C# lang server, that's the base extension. Also FYI you can just close solution explorer view...it's not mandatory, it's a 'feature'
I got a good chuckle out of 'expelling the demons' -- appreciate it. We are listening and doing our best to respond as quick as we can. Perf/debugging/reliability are definitely things we want to prioritize working better for ALL.
This is quality feedback, thanks for filing. Should we consider forking these into separate issues?
For namespace structure in newly generated file we have earliest tracking issue https://github.com/microsoft/vscode-dotnettools/issues/105 That is something we are currently working on a part of #967
Currently add new file only works on solution explorer. I believe we avoid changing anything in default explorer window so we don't have plan to modify adding new file there to generate file based on templates but we have plans to enable add new file in command palette so you don't have to use solution explorer. Filed #1071
Closing this issue as we have opened separate issues for each of the asked for enhancements.
@timheuer, I know this is already closed, but the issues are still there
I've made a small video showing my problems in the first issue: Project Loading and Symbol Recognition.
Here is the link for the video: https://youtu.be/_CrtnaWOpXw
I don't know how to create the debug output for VSCode to help you more, but if you need it, please let me know how I can do that.
It's not a long video ... just straight to the point. thanks all and keep up the good work Paulo Aboim Pinto
@aboimpinto I see in your video that you have some projects that haven't loaded. When you see this yellow warning in the status bar, it means something is wrong. Can you please provide information from the Output window for C# Dev Kit, and what it says when you hover over the error?
ok .. when I get this issue again I will capture that and post here!!!
@webreidi I got the same situation where the 12 projects aren't loading, and this is the output information that you requested
If you need more information, I will keep this loaded like this for a while.
You have my contacts in my profile if you need to contact me directly to get more information. Paulo Aboim Pinto
@webreidi I think that I found the issue ... or my wrong usage.
I have several projects in the solution folder, some of which are in the Solution Folder and some of which were NOT added to the Solution File. Even if not part of the Solution File, they are referenced by some projects that aren't being loaded and have this issue.
This wasn't an issue in the past, but now, with the C# Dev Kit, only the projects added to the Solution File have full code completion.
Is my assumption correct? Paulo Aboim Pinto
Now I'm having another issue:
and in the output window is this:
Using dotnet configured on PATH
Dotnet path: /usr/lib/dotnet/dotnet
Activating C# + C# Dev Kit + C# IntelliCode...
waiting for named pipe information from server...
[stdout] {"pipeName":"/tmp/cadfa90b.sock"}
received named pipe information from server
attempting to connect client to server...
[Error - 10:32:11 AM] Microsoft.CodeAnalysis.LanguageServer client: couldn't create connection to server.
Error: Timeout. Client cound not connect to server via named pipe
at W.<anonymous> (/home/esqueleto/.vscode/extensions/ms-dotnettools.csharp-2.45.25-linux-x64/dist/extension.js:2:1265571)
at Generator.next (<anonymous>)
at s (/home/esqueleto/.vscode/extensions/ms-dotnettools.csharp-2.45.25-linux-x64/dist/extension.js:2:1253516)
at runNextTicks (node:internal/process/task_queues:60:5)
at listOnTimeout (node:internal/timers:540:9)
at process.processTimers (node:internal/timers:514:7)
client has connected to server
Close VSCode and kill all dotnet processes were not enough. I had to restart the PC to fix this.
Another error that I get sometimes is, when I compile my App after using VSCode for few compilations is:
An error occurred while accessing the Microsoft.Extensions.Hosting services. Continuing without the application service provider. Error: The configured user limit (128) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached.
maybe this is related ... usually I close VSCode and open it again, and everything keeps working until I have the other error.
@dibarbet the primary issue seems to be the project loading. But the LS start failure in the logs looks interesting too. Let's scout first and work with @lifengl for the load. Most likely a runtime download issue?
@aboimpinto would you mind collecting the C# logs as described here - https://github.com/dotnet/vscode-csharp/blob/main/SUPPORT.md#collecting-general-logs (for the Microsoft.CodeAnalysis.LanguageServer client: couldn't create connection to server.
issue).
For the inotify instances issue, it sounds like something on the machine is probably creating too many file watchers. In the C# extension we do not create file watchers ourselves, we delegate to VSCode. But C# Dev Kit might be (Lifeng would know). A workaround might be to increase the available instances, e.g. https://stackoverflow.com/questions/43469400/asp-net-core-the-configured-user-limit-128-on-the-number-of-inotify-instance
Closing until @aboimpinto gets a chance to collect logs.
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