TL;DR

  • Pin your SDK version with global.json so teammates never break builds with previews.
  • Run SQL Server locally via Docker or LocalDB, and trust ASP.NET Core developer certs with dotnet dev-certs https --trust.
  • Use the command-line CLI shortcuts to build, run, and test projects without IDE friction.

Level: Beginner · Prerequisites: Windows, macOS, or Linux machine · Reading time: 12 min

Part 1 of the “Zero to Full-Stack .NET” series. Section: Getting Started.

It is your first Monday. You clone the project, open it, and press Build. The output says the project targets a .NET version you do not have. You install something, try again, and now the app starts but crashes because it cannot reach SQL Server. You fix that, open the browser, and get a red “Your connection is not private” warning on localhost.

None of this is a real bug. It is a machine that was never set up. The team has been working on their laptops for years and nobody remembers which tools they installed, so the onboarding document is three lines long and two of them are wrong.

This article is the setup I wish someone had handed me. It goes in the order you will hit the problems, and every step ends with a command you can run to prove it worked.

What you will be able to do after this

  • Install the current .NET SDK and pin the version a repository uses with global.json
  • Run SQL Server locally in Docker or as LocalDB and connect to it from a query tool
  • Trust the local HTTPS certificate so https://localhost stops warning
  • Create, run, and test a console app and a Web API from the command line
  • Use a dotnet CLI cheat sheet instead of clicking through menus

Installing the SDK and pinning it per repository

Download the SDK (not just the runtime) for the current LTS release from the .NET download page on dot.net. LTS means long-term support: it is the version most teams target because it receives fixes for three years. .NET 8 and .NET 10 are both LTS releases; pick the one your team uses, or .NET 10 if you are starting fresh (.NET 8 support ends in November 2026).

Check what you have:

1
2
3
4
5

dotnet --list-sdks
# 8.0.xxx [C:\Program Files\dotnet\sdk]
# 10.0.xxx [C:\Program Files\dotnet\sdk]
dotnet --version
# prints the SDK that will be used in the current folder

Having several SDKs installed is normal. The surprise is which one dotnet build picks: without any configuration, it uses the newest one on the machine. That is fine until a teammate installs a preview and a build starts behaving differently. The fix is a global.json at the root of the repository:

1
2
3
4
5
6

{
  "sdk": {
    "version": "8.0.100",
    "rollForward": "latestFeature"
  }
}

rollForward: latestFeature means “use 8.0.100 or any newer 8.0.x feature band, but never jump to 9 or 10”. You can generate the file instead of typing it:

1

dotnet new globaljson --sdk-version 8.0.100 --roll-forward latestFeature

Running SQL Server locally

Pick one of two paths:

  1. Docker (recommended if you have Docker Desktop):
1

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=Dev_Passw0rd!" -p 1433:1433 --name sqldev -d mcr.microsoft.com/mssql/server:2022-latest
  1. LocalDB (lightweight, Windows-only, installed with Visual Studio):
    Connect string: Server=(localdb)\\mssqllocaldb;Database=StoreDb;Trusted_Connection=True;

Trusting Local HTTPS Certificates

When running ASP.NET Core APIs locally, avoid browser SSL security warnings with:

1
2

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Core CLI Cheat Sheet

1
2
3
4

dotnet new webapi -n Store.Api       # Create new Web API
dotnet build                         # Compile project
dotnet run --project Store.Api       # Run application
dotnet test                          # Run all unit tests

Part 1 of 59 in Zero to Full-Stack .NET. Next up: Thinking Like a Programmer: Turning a Vague Request Into Working Code.

How this article was made: drafted with AI assistance, then reviewed by Softinbit Technology before publishing.