C# Get Started: Install .NET and Run Your First Project
Your goal is a working development loop: create a project, change its source, save it, and see the changed output. Follow one installation path for your operating system, then use the same project commands on every platform.
What you will be able to do
- Choose the SDK rather than a runtime-only download.
- Verify which SDK your terminal can find.
- Create and open a dedicated console-project folder.
- Distinguish editable source from generated build files.
- Prove that a new run uses your saved changes.
- Investigate setup errors without deleting your work.
Before installing: know which tool does what
You need a computer on which you can install development tools, permission to install the SDK, an internet connection for the download and initial restore, and a folder where you can save practice work. On a managed work or school device, follow its software-installation policy. The browser exercises remain available while you arrange local access.
The .NET SDK includes development tools and a runtime. A runtime-only installation can run compatible applications, but it cannot replace the SDK used to create and build this project. An editor helps you change source files; it does not replace the compiler. Docker is used by this site's local runner, but is not required for the ordinary SDK-based setup you will perform on your own computer.
This lesson uses the .NET 10 SDK and a project targeting net10.0. Select a supported SDK download rather than a preview or an old .NET Framework tutorial. You do not need the same SDK patch number as a screenshot. The checks below focus on the installed major version and the tools' behavior.
1. Install the SDK for your operating system
Windows: open the official download page and choose the .NET 10 SDK installer for Windows and your device architecture. Most Intel and AMD machines use x64; Windows on ARM devices may use Arm64. Run the installer, complete its steps, and open a new PowerShell or terminal window afterward. Choose the SDK column, not just Desktop Runtime or ASP.NET Core Runtime.
macOS: choose the SDK installer for your Mac. Apple silicon machines use Arm64; Intel Macs use x64. You can check the chip or processor in About This Mac. Complete the installer and reopen your terminal. Matching the native architecture avoids an unnecessary translation layer and confusion about where tools were installed.
Linux: use the official instructions for your exact distribution and release. The repository setup and package command differ between distributions; there is no universal apt command that is correct for every Linux machine. Select the SDK instructions and the .NET 10 package from the appropriate source. Avoid combining several installation methods while troubleshooting an initial setup.
Download tools from their official sites. If the installer says your operating system is unsupported, check the supported-platform instructions instead of repeatedly installing different packages. The links below are installation references, not code to paste into Program.cs.
2. Verify the terminal can find an SDK
Open a new terminal after installing. A terminal is the window where you type commands; PowerShell on Windows and Terminal on macOS are suitable choices. Run the two checks below, one line at a time. Do not type the explanatory text or paste these commands into a C# file.
dotnet --version reports the SDK selected for your current folder. For this lesson, expect a version beginning with 10., with a patch or feature-band suffix that can change over time. dotnet --list-sdks shows all detected SDKs and their installation paths. Seeing a runtime under --list-runtimes alone is not enough to prove the SDK is installed.
If several SDKs are installed, keep them: other projects may need them. A global.json file in the current folder or a parent can influence SDK selection. Start in a new practice folder outside an existing repository before assuming the installation failed. Do not delete another project's global.json to make this exercise work.
dotnet --version
dotnet --list-sdks3. Prepare an editor and a practice folder
Visual Studio Code is one option for this course. Download it from its official site, then install Microsoft's C# Dev Kit extension from the Extensions view. Check the publisher rather than choosing an unrelated extension with a similar name. The editor support is useful, but the terminal workflow below is the reference: you can also follow it with another text editor.
Create a folder named csharp-practice somewhere you can write files, then open a terminal in that folder. The commands below create that folder relative to your current location and move into it. If you already have such a folder, open it instead; do not recreate or overwrite an existing project. Use a simple path for your first exercise so spaces and cloud-sync behavior do not obscure the learning goal.
mkdir creates a directory. cd changes the terminal's current directory. A terminal has its own current folder, which can differ from the folder shown in your editor. That distinction explains many cases where an edit seems to have no effect.
mkdir csharp-practice
cd csharp-practice4. Create a console project and run the generated program
From csharp-practice, create the project below. dotnet new chooses a template; console selects a text-based console application; --name names the project and its folder; --framework requests net10.0. The following cd enters the new folder. Run these commands once to create the project, not every time you edit a file.
The template normally creates Program.cs and FirstSteps.csproj and performs a package restore. Restore resolves the project's dependencies and may need an internet connection. The stock console template does not require you to add a third-party package. First-run tool messages and restore status are not your program's output.
dotnet run builds and executes the project in the current folder. The untouched template normally prints Hello, World! after any tool messages. If that works, you have verified the basic toolchain. Next you will replace that generic message with a result you can recognize as your own.
dotnet new console --name FirstSteps --framework net10.0
cd FirstSteps
dotnet run5. Understand the files before editing them
Open the entire FirstSteps folder in your editor using File → Open Folder. You should see Program.cs beside FirstSteps.csproj. If the code command is configured on your machine, code . is a shortcut, but it is optional. Opening the whole folder gives the editor the project context rather than only an isolated text file.
Program.cs contains the C# source you will change. FirstSteps.csproj is an XML project file that describes settings such as the target framework. Leave those settings alone for this exercise. Files under obj are intermediate build and restore output; files under bin are build output. They are not the place to edit your lesson code.
A generated console project can include top-level statements and implicit imports. Our examples keep using System explicit so the source remains clear when copied. Replace the entire contents of Program.cs with one complete example; do not append a second complete program or add another file with top-level statements. Save the file before running it locally.
A project, its source file and its built assembly are related, but different. Creating the project establishes the build settings. Editing Program.cs changes what you want the application to do. Building produces files the runtime can load; it does not turn the editor itself into the application.
6. Replace Program.cs and verify recognizable output
Replace Program.cs with the complete program below and save it. In a terminal whose current folder is FirstSteps, run dotnet run again. Compare only the application lines with the expected output; a first run may also display build or restore messages. The label, project name and number should all match.
You can also select Run code below to try the source in the browser. That uses a separate isolated environment, not the SDK on your computer. Browser success does not prove that your local installation works, and a local installation problem does not make a valid program wrong. Keep those two verification steps distinct.
dotnet runProgram.cs · Verify your first project
Predict the result, edit Program.cs, then run your program.
Standard input · optional
Select Run code to compile and execute this program.
My C# workspace is ready.
Project: FirstSteps
Practice minutes: 25The two quoted messages identify the program you intended to run. The final message calculates 15 + 10 and inserts 25. These messages do not inspect your computer or install software: a successful browser run verifies this source in the site's sandbox. Only your own terminal can verify your local SDK and project.
7. Edit, save, build, and run again
Now use the revision-2 program below. Before running it, predict the new total: 20 + 10 is 30. Save Program.cs, then use dotnet build followed by dotnet run. build checks and compiles the project without starting the application; run starts it and normally builds it when necessary. For everyday edits, dotnet run alone is enough.
A successful build without your messages is normal: build is not run. To verify the whole loop, look for both revision 2 and 30 after execution. Avoid --no-build while learning this workflow because it can execute older build output after you change the source.
If you work from the parent csharp-practice directory, explicitly select the project with dotnet run --project FirstSteps/FirstSteps.csproj. This is an alternative to changing into FirstSteps. You do not need both approaches at once. Explicit project selection helps when a workspace later contains more than one application.
dotnet build
dotnet runProgram.cs · Prove your saved edit was used
Predict the result, edit Program.cs, then run your program.
Standard input · optional
Select Run code to compile and execute this program.
My C# workspace is ready — revision 2.
Project: FirstSteps
Practice minutes: 30The revision marker and changed number provide two independent signs that the edited program ran. If the terminal still prints 25 and the old message, first check that you saved the correct Program.cs and ran the intended project. Changing an expected-output panel cannot change the program.
Repair: distinguish a code error from a setup error
A successful installation does not mean every program you type will compile. Run the deliberately broken example, read its diagnostic, and repair the missing punctuation. Locally, save the repair and rerun the same project rather than creating a replacement project.
Program.cs · A small compiler error
Predict the result, edit Program.cs, then run your program.
Standard input · optional
Select Run code to compile and execute this program.
Compilation fails: the first WriteLine statement needs a semicolon.This deliberate missing semicolon stops compilation. There should be compiler diagnostics rather than new application output. The exact diagnostic wording and line formatting can vary by SDK. Read the first useful error and inspect the statement just before the reported location.
Reveal the repair
Program.cs · Repair and rerun
Predict the result, edit Program.cs, then run your program.
Standard input · optional
Select Run code to compile and execute this program.
Setup check
Ready to practise.Restoring the semicolon makes both statements valid. Save the file and run again. A successful build means the compiler accepted the source; the printed lines then show that the resulting program actually executed.
- Confirm the broken version produces compiler diagnostics, not the expected application messages.
- Add the missing semicolon without changing the intended messages.
- Save locally, rerun, and compare both printed lines.
- Explain why reinstalling the SDK would not repair a punctuation error in Program.cs.
Independent lab: verify your workspace
Create a small workspace card in the FirstSteps project. Use the starter below, then complete the local verification steps. The browser can check the source and its output; the terminal steps demonstrate that your own development setup works.
Acceptance checklist
- Print Project: FirstSteps and a revision marker on separate lines.
- Calculate practice minutes from 20 + 15 rather than typing 35 as text.
- Save Program.cs and use dotnet run in FirstSteps.
- Change one operand, predict the result, and rerun the saved edit.
- Use dotnet build once and explain why it does not print the workspace card.
Program.cs · Workspace card starter
Predict the result, edit Program.cs, then run your program.
Standard input · optional
Select Run code to compile and execute this program.
Project: change this label
Revision: 1
Practice minutes: 0Replace the project label, revision marker and calculation. Keep the program in the same FirstSteps project: a new source edit does not require another dotnet new command. The console report describes your practice plan; it does not measure time or save progress.
Show hints
- Replace the starter file contents; do not paste it after another complete program.
- The dollar sign enables interpolation; braces contain the calculation.
- If old output appears, check the filename, saved state and selected project before changing tool settings.
Reveal the reference solution
Program.cs · Workspace card solution
Predict the result, edit Program.cs, then run your program.
Standard input · optional
Select Run code to compile and execute this program.
Project: FirstSteps
Revision: 3
Practice minutes: 35This reference solution has a recognizable project label, a revision marker, and a calculated total. After verifying 35, change 20 to 0 and predict 15 before running again. The point is to connect your edit with new output, not to memorize this particular message.
Verification and changed inputs
- 20 + 15 must print 35; 0 + 15 must print 15.
- Change the revision marker and confirm the new marker appears.
- Run with --project FirstSteps/FirstSteps.csproj from the parent folder and compare results.
- Write down your selected SDK version and the location of Program.cs.
Common setup errors and how to investigate
dotnet is not recognized or command not found
Close and reopen the terminal, confirm that the SDK installer finished, and check the official installation instructions for your OS. If needed, use where.exe dotnet on Windows or command -v dotnet on macOS/Linux to inspect the executable location. Do not add a guessed PATH directory or reinstall unrelated runtimes.
No SDK was found, or a requested SDK is unavailable
Check dotnet --list-sdks. A runtime-only download is insufficient. If an installed SDK exists but --version fails in one directory, inspect that project's global.json and compare from your clean practice folder. Install the required SDK or use a compatible practice location without changing another project's policy.
Couldn't find a project to run
The current directory probably does not contain FirstSteps.csproj. Enter FirstSteps or pass its actual path using --project. Opening Program.cs in an editor does not automatically move every terminal into that folder.
The SDK does not support targeting net10.0
Verify that an appropriate .NET 10 SDK is installed and selected. An older SDK cannot target a newer framework just because Program.cs is simple. Read the selected version and any global.json constraints before changing the target framework.
Restore fails before the program starts
Read the restore diagnostic and check the network, proxy and configured package sources. On a managed device, ask for the approved configuration. Retry dotnet restore inside FirstSteps after resolving the cause; do not disable TLS verification or add a random package source to hide the error.
Old output appears, or more than one top-level file is reported
Save the intended Program.cs, confirm the project path, and use ordinary dotnet run without --no-build. If two files contain top-level statements, keep one program entry point; move a copied example outside the project using your editor rather than deleting work blindly. One example is one complete Program.cs.
Frequently asked questions
Do I have to install Visual Studio?
No. This lesson uses the SDK CLI and an editor such as VS Code. Visual Studio is another development environment, but the command-line project provides a shared workflow across Windows, macOS and Linux.
Does the browser Run button use my installed SDK?
No. It sends the editor source to the site's configured execution service. In local SovranCode preview that service uses an isolated .NET container. Your computer's terminal is where you verify your own installation.
Should I run dotnet new after every change?
No. Create FirstSteps once. Edit and save Program.cs, then run dotnet run again in that project. Creating another project for each edit makes it harder to tell which source you are running.
Can I install more than one SDK?
Yes. Existing projects can depend on different SDKs. Use --list-sdks to inspect them and --version to see the selected SDK. A global.json file may constrain selection; do not remove another project's constraint casually.
Do I edit bin or obj when the output looks wrong?
No. Edit Program.cs and save it. bin and obj contain generated artifacts. First check your current directory and project selection; manually changing generated files does not repair the source workflow.
Can you explain your setup?
Check the whole development loop, not just whether an installer finished.
Recap and next step
The SDK supplies build tools, the editor changes source, and the terminal runs commands in a particular folder. Program.cs is your editable source; bin and obj are generated output. A reliable setup is one where you can predict a change, save it, and see the new result from the correct project.
Continue using Next lesson below to C# Syntax and Program Structure. Learn how statements, braces, names, and entry points fit together, then repair and explain a complete report.
Official references
- Official .NET SDK downloads
- Install .NET on Windows
- Install .NET on macOS
- Install .NET on Linux
- Download Visual Studio Code
- Microsoft's C# setup in VS Code
Original SovranCode explanations and exercises. Last updated: .