A couple of months ago I updated Visual Studio 2022 which broke a lot of important things, like the save functionality. I had to look around for an alternative, and my first thought was Emacs, of course, sadly I could not get omni-sharp or omisharp-roslyn to work. So the next best option was Visual Studio Code, which I switched to.

Then an update was made to Visual Studio which fixed my problems or some of them, enough that I decided to move back. This blog post will describe why I moved back to Visual Studio. Before we continue for the rest of this blog post, VS will mean Visual Studio, and VSC will mean Visual Studio Code.

First, I want to say that VSC impressed me a lot. It was a lot snappier (this changed) than the first time around it, on my old blog I had a post about why I disliked both VSC and Atom and how slow both were (for the same reason… electron) was one of my main cavities with these two editors.
Also, I would like to amend that I only use VS and VSCode for C# and Blazor/MudBlazor, for everything else (JavaScript, Go, Python, …) I still use Emacs.

Project Dependencies and Nuget Management

One of the things I like the most about Rust and Ruby is dependency management. It is so simple compared to any other language, YES, I SAID THAT!!! With C# it is somewhat easy with Nugets and the UI in VS. However, the story is a little different in VSC. First of all internal project dependencies (if you have more than one project in a solution) is essentially handled by adding the dependency to the .csproj, which I have no issue with. But, there is an issue in VSC. By default there is (to my knowledge) no built-in way to do this other than adding the dependencies by hand to the .csproj file, which is pretty annoying. Yet there is a plug-in for this vscode-solution-explorer, it does other things too. But I have tried, more than once, that would end up with the .csproj file in a corrupt state and I would have to fix it by hand, ending up with just having done it by hand from the start being quicker.

Another issue comes with nuget packages, actually two issues. In VSC, you should be able to type Ctrl + Shift + P, and Select Nuget package Manager: Add Package, which I can and I can install Nuget packages. However, when I push to git all changes to the repo, colleagues get an error that reference to X is not found, where X is an element in the Nuget package. This is weird because if I run dotnet add <PROJECT> package <PACKAGE_NAME> with the options, I need (see stack overflow answer) then it works. I found on IRC that I am not the only one with this issue, but it seems like it fixes itself after certain updates. I just never hit one of those updates. Additionally, and this is not an issue with VSC but the Nuget command line tool (I think) getting access to private Nuget repos outside of VS just never worked for me, even though I had to configure it for VS with the command line tool. Maybe I missed something in the setup.

Debugging

Now this one is probably the most significant problem, I could not get debugging to work. How you tried developing without the option of debugging, it sucks.

I have to be 100% honest. A colleague of mine does use VSC permanently and has debugging working. But we spent roughly 2 hours together trying to figure out what in the name of hell was wrong with my setup. But we simply could not find out what was wrong.
The debugger did seem to run, but breakpoints just never activated. From our point of view, it looked like there was a miscommunication between the debugger and VSC about where breakpoints were in the code. I do have a lead about where the issue might be, but I haven’t had the time to confirm it and fix it.

Could not find an alternative to Code Maid

Code Maid is a nifty plug-in to VS which allows you to clean up and format your code according to a specification. It is kind of similar to ClangFormat if you are familiar with that.

For some reason, I could not find an alternative to VSC, I am honestly surprised that there does not exist a port of Code Maid to VSC.

Code Maid is so nice and quickly removes unused imports and more, and I found that I really missed it in VSC as I spend quite some time removing unused imports.

Plug-In Configuration

Okay, this may be the plug-ins problem and not VSC, but it is still through VSC I experience the problem, so it is the first encounter with this issue. The issue is that some plugins require you to alter a JSON file to configure, others utilize drop-downs and text boxes, and even some use a mixture.

This is insanely annoying, first of all, because there is no coherence, and you have to remember which plug-ins that do it in which way. Some plug-ins do not inform the user that advanced configurations are only available in the JSON configuration. It is even hidden that the file exists at all. Granted a little bit of searching the web will reveal it, but for an editor that kind of beats the drums of easy-to-use, this is a letdown.

Mudblazor never worked properly

For frontend development in C# I use Mudblazor (this is not a recommendation), blazor/mudblazor is smart in theory, not always so much in practice. ANWYAYS this is a VSC post. In VS, the editor will most of the time, be able to find the MudBlazor tag you want. But for some reason, in VSC, every time I started a new .razor (Blazor/Mudblazor) file I would have to read-load the project for VSC to understand I wanted access to the Mudblazor components. The former mentioned colleague told me he has a similar issue. This is quite annoying, but it was a problem I could live with, if not for the other issues.

Weird CSV issue

I work with CSV’s a lot and have to be able to handle them, and here VSC failed me big time. For some stupid reason I could not figure out, visual studio kept adding CR LR pairs (\r\n) to the end of lines in CSV (Line Ending explanation). Now, this would be perfectly fine, if I had made the mistake of setting VSC to Microsoft’s (weird) default character encoding for Windows, but I have it configured to be default UTF-8 and VSC told me the pane was open with UTF-8. I could get as far as to identify that it was only an issue with CSVs, which is even weirder because I do not have a plug-in for CSVs installed. Additionally, neither Emacs, Sublime Text, Notepad++, nor VS has the issue.

If anyone can explain it, please reach out.

Resource usage and UI Stuttering

Now, we come to my probably biggest issue and a first-world problem with VSC. In the beginning, it was snappy and pretty sweet to use. However, as I added more and more plug-ins (10 in total), the UI started lagging, and I even experienced characters appearing long after I typed them, which is pretty frustrating. I type fast but not that fast. By enabling and disabling different plug-ins, I could conclude that it was not individual plug-ins but rather the amount. My work pc has 32GB of RAM and a 2.3GHz CPU this should not be a problem. For reference, and as stated in my post Stop using Electron, I find that VSC use around 1.3GB of RAM in Idle, and I have seen it use way over 12GB when I code (20+ files open simultaneously). That honestly worries me when VS, a fully-fledged IDE, uses way less (around 8GB) in the same situation. It was so annoying and got to a point where I sometimes found it took longer to close VSC than closing VS and shutting down windows combined.

Now I do have a suspicion about resource usage, and that is Electron. Yes, I am campaigning against it, but let us face it I use a lot of Electron because I have to (hello Signal my friend). But that aside, I do not have similar issues in Emacs with roughly the same configuration, nor do I have it in Vim. I guess it has something to do with how plug-ins are loaded/handled in VSC. But I cannot confirm it.

Conclusion

So this is why I have decided to move back to Visual Studio. Simply because I had a load of problems, nothing else. As an editor, Visual Studio Code is really solid, but as soon as you start fiddling a little bit with it, in particular adding plug-ins or doing more advanced stuff, it starts to fall apart, in my opinion. Please note, that I still find VS clunky, but there simply is no alternative for C# development besides VSC in my opinion. I would like to dive a little bit more into either using Vim or Emacs again at a later time. But for now, I am sticking with VS.

I would like to make the following closing remark: The VSC Community is by far one of if not the most welcoming editor communities I have ever entered, and I can only wish for the Emacs and Vim Communities to morph into something like the VSC community.

./Lars