search

microsoft / vscode-dotnettools

This is a feedback repository to capture issues logged for the C# Dev Kit and related extensions from Visual Studio Code
Other
192 stars 6 forks source link

[FEEDBACK] The experience is nowhere near VS for Mac or Rider #1053

Closed iam3yal closed 1 month ago

iam3yal commented 1 month ago

Feedback

The C# Dev Kit experience falls far short of VS for Mac and isn't even remotely comparable to Rider. If there's a serious intention to transition people from VS for Mac to VSCode (or from Rider for subscribers like myself), then a more serious approach to migration is necessary.

Consider the following points:

This assessment is based on personal experience, but it feels as though there's an unnecessary level of complexity involved in transitioning from VS for Mac or Rider to VSCode. Respectfully, it doesn't quite embody the essence of an IDE but rather feels more like a side project from a third-party vendor. This observation comes from someone who regularly uses VSCode alongside Rider, and I can only speculate on the experience for those who are new to it. Therefore, I genuinely hope that with time, improvements will be made to elevate its quality and usability.🤞

Environment Information

timheuer commented 1 month ago

Thanks for taking the time to post the feedback @iam3yal!

  • When opening a solution, it should seamlessly navigate to Solution Explorer rather than displaying both Folder Explorer and Solution Explorer simultaneously.

We've heard both mixed feedback here. We are looking to experiment with a setting that does just what you are stating here. The default explorer of course shows your entire workspace and is super valuable so we don't want to relegate that as we have heard that most rely on that 'whole workspace' view quite a bit.

  • Keybindings should mirror those of VS for Mac (with optional keymaps for Rider/R# users).

Have you manually set your key bindings to match your desires? Are you looking for us to provide a default optional mapping here? If you had to prioritize, what are the most used keybindings you re-map?

  • Running and debugging should function smoothly without needing to modify launch.json files or mess with configuration at all.

The run/debug experience in VSCode is indeed different. In the C# Dev Kit we've tried to do what you mention. You don't need a launch.json to run/debug a .NET app within the Dev Kit as we've enabled a dynamic debugger that you can leverage. The way that VS Code works today you do have to choose it once to make it known that's preferred, but you don't have to create a new file though.

  • It should effortlessly support Blazor, MAUI, and other project types without requiring additional extensions beyond the C# Dev Kit. It should encompass all C# project types out of the box, akin to a conventional IDE.

Good to hear this. In your list, MAUI is the only thing that is separate as of now. We've also heard much the opposite of what you're proposing that folks want light-weight fast installs and if they don't use a specific framework, they don't want to have to worry about it (e.g., if you aren't a client developer we've heard feedback they don't want MAUI by default).

I think your sentiments are reflected in some other issues, but I might encourage you to close this one, and search for others to upvote and/or create individual items here so that we can reason with them and the community separately. Sound fair? It's better, for example, to have an issue about bringing MAUI in to the extension in one issue that can be discussed, etc. rather than a mutli-topic issue like this, if that makes sense.

iam3yal commented 1 month ago

@timheuer

We've heard both mixed feedback here. We are looking to experiment with a setting that does just what you are stating here. The default explorer of course shows your entire workspace and is super valuable so we don't want to relegate that as we have heard that most rely on that 'whole workspace' view quite a bit.

The option should show the Solution Explorer by default but should you want to go back to Folder Explorer it should be possible to switch between them but showing both of them at the same time can be confusing.

Have you manually set your key bindings to match your desires? Are you looking for us to provide a default optional mapping here? If you had to prioritize, what are the most used keybindings you re-map?

I'd say you should definitely add R#/Rider keybinds over VS for Mac.

The run/debug experience in VSCode is indeed different. In the C# Dev Kit we've tried to do what you mention. You don't need a launch.json to run/debug a .NET app within the Dev Kit as we've enabled a dynamic debugger that you can leverage. The way that VS Code works today you do have to choose it once to make it known that's preferred, but you don't have to create a new file though.

I tried to launch one of my side projects (this solution) and I couldn't just launch it out of the box.

Good to hear this. In your list, MAUI is the only thing that is separate as of now. We've also heard much the opposite of what you're proposing that folks want light-weight fast installs and if they don't use a specific framework, they don't want to have to worry about it (e.g., if you aren't a client developer we've heard feedback they don't want MAUI by default).

Well, I think the problem here is not so much that they are separated extensions, it just feels that quality and usability is not there so once the individual dependencies will be a top-notch quality then I think it wouldn't be so important, maybe a middle ground would be to have a preconfigured extension with all the dependencies for people who wants different "Workload" so for example you might have "C# Web Workload" extension, "C# Desktop Workload" extension, etc.. similar to VS Workload, I dunno it's just an idea but sometimes having options is good.

I think your sentiments are reflected in some other issues, but I might encourage you to close this one, and search for others to upvote and/or create individual items here so that we can reason with them and the community separately. Sound fair? It's better, for example, to have an issue about bringing MAUI in to the extension in one issue that can be discussed, etc. rather than a mutli-topic issue like this, if that makes sense.

I understand. Closing this and if I wouldn't find an issue about one of the issues mentioned I'll create a new one, thank you! keep up the good work!