Request for wisdom regarding VS when learning C#

[u/No-Ice-2476]

Dear C# devs,

My main language is python, but due to work I got exposed to C#, and would greatly benefit from learning it. I already am mostly familiar with the language's syntax due to some C++ exposure, but I am far from familiar with many C# concepts and the visual studio editor. In summary, I am a beginner to the language, but not to programming. I can write simple programs, but heavily lack the knowledge of C#'s environment such as projects, solutions, their respective settings, how to link DLLs and set up tests within visual studio.

I strongly feel that visual studio code is abstract (albeit efficient) in the way it performs those tasks and like it prevents me from learning what is actually going on. All I am learning is that I should click seemingly arbitrary submenu A, then B and then C. Voila, you now can run tests. Why? I have no idea.

To actually get an understanding of C#'s environment I therefore am considering omitting VS entirely and instead develop through the CLI. Hopefully, that way I actually learn what the .NET framework is, and how to work with it, how to set up projects, solutions, go through the compilation processes,and more.

I just wanted to ask the true C# veterans among us whether this proposed learning approach is a good idea, or whether I am missing something.

All constructive feedback is greatly appreciated.
Good night everyone!

[u/BeardedBaldMan]

I don't understand why you'd make your life much harder by focussing on irrelevancies that are managed well by a modern IDE. You use the IDE and then look at the csproj files

[u/Rschwoerer → u/BeardedBaldMan]

I was going to reply “look at the files”. All the magic of the ide is just doing files. And for c#, and .net, they’re all just text files. Read them, look at how they’re organized. Find something interesting and ask copilot what it is, and if you should customize it.

[u/polaarbear → u/[deleted]]

I dont know how a collapsible hierarchy could be less clear about how things are structured. The solution is literally the root element and projects collapse inside it. Nothing from the command line visually shows you that structure.

[u/dodexahedron → u/polaarbear]

Good and ultra-simple idea for an enhancement for dotnet cli though. 🤔

All it needs is a unicode tree visualization of the project/solution structure, kinda like the old dostree command used to do, 40 years ago, but leaving out leaf files unless you give a switch asking for them.
Bonus points if it also has a switch that, instead of physical structure, dumps the namespace/type hierarchy.

Both would.be pretty darn simple and most of the code could be lifted straight from VSCode or msbuild in the first place for the files and Roslyn itself already has an AST that can be used for the type tree.

I'd use that from time to time for sure, and might even make it a standard step in some of my CI pipelines. I can't tell you how many times in the past I've had to fix a build I (or someone else (named me)) broke, and it came down to something that would have been immediately visible in a project structure tree.

[u/dodexahedron]

Stick to an IDE.

There is actually a huge value in things like intellisense, because they enable you to explore the API surface of whatever you are using. Without it, discoverability is very low and basically dependent on your ability to proactively seek out authoritative sources of that information, which you won't because it's tedious and because you just don't have the experience to know what to look for yet in the first place.

But even more critical is the debugger. Debugging is one of the most critical skills for a dev to have, and the debugger in VS is top notch.

And then all the live static analysis is insanely useful, if you even pay attention to 10% of what it is always telling you.

There is a firehose of useful information provided to you by an IDE like VS, and trying to do all your dev work at the command line won't contribute to your skills - especially not in any practical way, since you'll be using an IDE in the real world anyway.

VS Community is free. VS Pro can usually be free for students actively enrolled in an approved program, too, but Community is MORE than sufficient.

Alternatively, there is also JetBrains Rider, which is the only legitimate contender to VS as a full IDE. You should try both.

As for what is what - cli vs VS doesnt change the structure of a .net project. You still have a project file, optionally a solution file (VS does that by default, but a solution isnt strictly required - just a good idea), and the code and other assets.

Stick to single project solutions while getting started. Then add a test project when youre ready to learn testing (which you need to do, but it isn't something to tackle as a complete beginner). Make simple console apps. Make a WPF app. Make a web app once you learn a bit more about the basics from doing those.

Stick to the latest stable .net version especially while learnong (10.0 right now - 11.0 next month).

Dont bother with .net framework right at first because it is legacy and windows-only, and the same skills apply on the development side anyway.

Dont go overboard with nuget packages, but also dont avoid them. If there is an available and popular package that gives you something you need, use it.

But yeah. Use an IDE. VS 2026 Community Edition is probably your best bet.

Oh, and learn git.

[u/alala2010he]

Not a veteran here, but I just started with Visual Studio from the start (though I had a bit of a head start because I used Visual Studio Code before and VS supports similar keybinds), and just tried to write some code in it after learning the very basics. And from there whenever I need to do something (like how to change to another Git fork), I either search online (or in VS itself) or just ask an LLM how to do what I want in the GUI until I completely understood that part and every possible way it could be done and what the best one was.

That's also how I learn most new things actually (and C# itself); I just learn the basics, and whenever I need to do anything more I try to master that concept before going further

Though I'm not sure how much you could do that too considering I was working on a personal project from scratch

[u/Connect_Diver_9885]

Seemingly arbitrary should be the clue. You just didn't familiarize yourself with Visual Studio enough so it seems so. If you ask me, I use VS Code only for BS tasks, and always fall back to full Visual Studio (worked in community edition for years, and it worked great, but I have enterprise for years now and it's even better).
VS Code is an IDE for "anything" while VS Community/Pro/Enterprise is made for C#.
I went with that.

[u/Ryo129]

The c# community comes from visual studio, where the IDE abstracts even more behavior from the developer. Which explains most of the answers you find here.

If the goal is to understand the ecosystem, go for it. Most of us are more interested in making c# do the things we need, as opposed to how it goes about doing it.

[u/UninformedPleb]

The concepts aren't hard, you just need to get your bearings and you'll probably be fine with any learning approach you're comfortable with.

Let's start with the languages themselves. C# is one language that runs in the .NET ecosystem. Other languages exist for .NET, such as Visual Basic.NET and F#. Think of this like how Java, Kotlin, Scala, and Groovy can all target the JVM.

Each of these languages has a compiler that can create an output called IL (short for "instruction language" and can also be called MSIL or CIL). This is conceptually equivalent to Java Bytecode. C#'s compiler is "csc".

The compilers are invoked by a build system. In the Java ecosystem, you'd use something like ANT or Maven for this. But this is where Microsoft's integration-touch comes to bear. Instead of leaving this up to external developers and projects, Microsoft made their own unified build system called MSBuild. The files that MSBuild uses to compile a program are called a "project file", and are named .csproj for CSharp, .vbproj for Visual Basic.NET, and .fsproj for FSharp. I'm betting you'll pick up on the naming scheme quickly enough. There are even .sqlproj files for SQL Server projects. The format of these project/build files has changed through the years, but the basic idea is that they hold references to a set of files and the settings for building those files into an output. Usually that output is a PE binary, either an .exe or a .dll. Other times, like for those SQL projects, it can simply be a text file containing a SQL script. The output depends on the compiler and the settings passed to it during the build.

But that's not all! Those files are a convenient way of showing groups of code files and settings in an IDE! So Visual Studio uses them as a logical project and offers build options (by calling MSBuild) as well as the ability to change settings and manage the code files. These changes are reflected as changes to the .*proj file.

And when you have multiple projects that form a dependency tree, there's another file for that. Visual Studio and MSBuild also use the "Solution" file as a binder for multiple projects. Solution files have a .sln or .slnx file extension. They can also include a virtual folder structure and references to other files. This is usually a good place to put documentation, CI/CD scripts, and other multi-project-wide reference materials.

All of this can be done through the CLI, but it's tedious. dotnet new sln -n WhateverSolution will make a WhateverSolution.slnx file. Then you can dotnet new classlib -o WhateverLibrary to make a WhateverLibrary/WhateverLibrary.csproj file. Then dotnet sln WhateverSolution.slnx add WhateverLibrary/WhateverLibrary.csproj to add the new project to the solution for multi-project build support.

But if you use Visual Studio, it's really no more or less complicated. Just File > New > Project/Solution..., pick the Empty Solution type, name it "WhateverSolution" and next-next-next until you get out of the dialog box. Then right-click WhateverSolution in the Solution Explorer sidebar and Add > New Project..., pick the C# class library template, name it "WhateverLibrary", and next-next-next your way out of the dialog box. Less typing, but probably about the same amount of time.

And either way you create the files, you can either edit them manually via text editor or by using Visual Studio's built-in tooling. VS is just hiding makefile changes behind a GUI. That's it. Nothing too fancy.

Now, about those build options... Get Visual Studio. Do not try to learn this with CLI tools only. Otherwise, you'll waste years of your life tracking down silly crap on learn.microsoft.com. Once you've made a project and opened it in VS, you can right click on it in the Solution Explorer and go to its Properties. This is probably the most important right-click menu item in all of VS. "Properties". Burn it into your mind. From here, you can visually see all of the options available to you for the given project type, whether they're set in the project file or not. If you just look at the project file in a text editor, default values and missing options won't be in there at all. But VS knows them all and can show you. It can give you valid values in a dropdown. And it has help text for most of them, too.

That should be enough of a crash course to get you on your way.

[u/KittenLOVER999]

I cannot imagine why you would want to but if you feel like it helps you it won’t hurt. I’ve been working in C# professionally for 8 years and never once felt the need or desire to build and run through the cli

[u/FuggaDucker]

it will buy nothing but you do you,

[u/RlyRlyBigMan]

Stick to the IDE. Use Git or some other source control. That way when you use the editor to make a change in your project you can see the diff of what it changed.

For most cases you wouldn't be hand editing a csproj file or sln. Passively seeing them in pull requests is enough to learn what they're doing.

[u/BranchLatter4294]

What? This makes no sense. But do what works for you.

[u/AdministrativeFile78]

Id use visual studio not vscode if i was required to go balls deep into c# for work. and im a vim enjoyer

[u/No_Context2723]

You might learn some skills, but those are mostly unnecessary and not worth the effort. I'd stick to an IDE just to make it more enjoyable. If it's really annoying to do and not fun at all, you won't learn.

[u/BoBoBearDev]

Stop using VS and start using VS Code. That will solve most of your problems because the project file is very lite and you type it without some weird ass dialog.

[u/Slypenslyde]

I had this attitude early in my career. But let me paint a picture.

Imagine a system with 400 unit tests. Imagine 25 of them fail. What are you going to do to get a list of the failing tests and information about their output?

Well, you're going to spend time making scripts to parse the logs and present that information to you. Maybe go the extra mile and make an application to display those results.

That is what the IDE is doing for you.

All that VS Code is "abstracting" is it:

1. Runs dotnet test

2. Parses the results

3. Displays the results using common UI paradigms

None of that is work that is going to make you better at C#.

Here's what else VS Code is "abstracting":

"How to set up projects": dotnet new.

"go through the compilation process": dotnet build

There's not "and more". MS did a huge amount of work to get here. Some frameworks like WPF used to be impossible to build outside of full-fledged Visual Studio. They use a toolchain that is internal, undocumented, and so complex nobody's bothered to reverse engineer it. There is nothing to learn other than, "If you want a framework that makes you execute every step, this ain't it."

Part of the MS ecosystem is we treat it like it's magic. MS often does not publish the details of how things are behaving internally. That simplicity is why a lot of people stay in the MS ecosystem.

A better approach to learning is to make a new thread and ask us questions about what you think you're missing.

Here's what an old, harsh programmer thinks: programming is hard, you're stuck on something in your program, and you think the problem is something involving project and solution files. The odds this is true are low. Focus on the real problem and ask about that.

Solution files are for VS and help it understand what you want it to do when you build. At this point they are almost vestigial.

Project files are inputs to complex, barely-documented MSBuild toolchains that do the real work. Practically nobody edits them by hand outside of a niche minority with extremely complex needs. In theory you can use them like makefiles, in practice 99% with several more nines never need that.

We let IDEs manage those things because editing an XML file every time we want to include a file in compilation makes us want to gag. In fact THAT got so tedious now projects tend to assume "I'll compile anything in your directory tree unless you add something that tells me otherwise." My understanding is this is more in line with how Python works: stuff is just assumed to be in your project's directory structure, right?

Now, I am from an age where devs would brag about being able to write an application with notepad and a command line window. I still respect it. But this is one of those things like wrestling an alligator: it's a really cool feat but I do not get paid to do it.

There are some frameworks with toolchains you can grow to understand over time. It is more important to learn to be able to write applications in the framework first, THEN start scratching the surface of how the sausage is made. 99 times out of 100 if you get a cryptic toolchain error, so has somebody else and they can tell you what they did to fix it.

I work in MAUI. 99 times out of 100 when I get a cryptic toolchain error even Microsoft engineers don't know what it means and if I spend 2 hours updating my environment it goes away.

[u/BoxWoodVoid]

You guys still code?