When you first open the Visual Studio Installer, you're hit with a wall of checkboxes. It’s tempting to treat this like a buffet—checking every box for "Mobile Development," "Game Development with Unity," and "Azure Development" just so you don't have to come back and do it again later. I’ve seen plenty of developers do this, and it feels like the "safe" play. You think you're future-proofing your machine. In reality, you're just bloating your SSD with gigabytes of toolchains and emulators you might never touch, which slows down your updates and clutters your project templates.

The Bloat Trap vs. Targeted Workloads

The naive approach is "Install Everything." The professional approach is "Install Exactly What You Need." For our purposes, the only thing you actually need to check is the .NET desktop development workload. This gives you the core compilers, the debugger, and the libraries needed to build standard C# applications. If you later decide you want to build a website or a mobile app, the Installer is designed to be reopened. It's not a one-time setup; it's a management tool. I always tell my juniors: start lean. It's much easier to add a workload in thirty seconds than it is to realize your C: drive is at 2% capacity because you installed an Android emulator you'll never use.

The Runtime Misconception

Another point where people get tripped up is the difference between the .NET Runtime and the .NET SDK. You might see a download for the "Runtime" and think, "Great, that's the engine that runs the code, I'll just get that." If you do that, you'll find yourself staring at a text editor with no way to actually compile your code into something executable. The Runtime is for people who just want to run a C# program someone else wrote. As a developer, you need the SDK (Software Development Kit). The SDK includes the Runtime, but it also includes the CLI tools and the compilers. If you only install the runtime, you're essentially buying a DVD player without owning a DVD recording studio.

The IDE Weight Trade-off

You'll likely hear people argue about Visual Studio versus Visual Studio Code. It's an important distinction. VS Code is a lightweight editor; it's fast and elegant, but it requires you to manually hunt down and configure plugins to make C# work. For someone starting out, that's just friction. Visual Studio (the full IDE) is a heavy beast, but it's an integrated experience. It handles the project files, the NuGet package management, and the deep debugging tools out of the box. I prefer the full IDE for C# because the "magic" it provides—like IntelliSense that actually understands your whole solution rather than just the current file—saves me hours of manual lookup. You're trading disk space for cognitive bandwidth.

📋 Practical Task

The SDK Version Verification Probe

Now that you've installed Visual Studio and the .NET desktop workload, we need to make sure the system actually knows where the tools are located. Sometimes the installer finishes, but the environment variables aren't updated until a reboot, or the path is slightly off.

Open your terminal (Command Prompt or PowerShell) and perform the following:

• Run the command dotnet --version. You should see a version number (e.g., 8.0.xxx). If you get a "command not found" error, your SDK isn't in your system PATH.
• Run dotnet --list-sdks to see all installed versions.
• Use the CLI to create a blank project folder by running dotnet new console -n EnvironmentCheck.
• Navigate into that folder and run dotnet run.

If you can successfully run that blank project from the command line, your environment is correctly configured and the SDK is communicating with the runtime. If it fails, restart your machine to force the PATH variables to refresh before trying again.