# Check installed SDKs and runtimes
dotnet --list-sdks
dotnet --list-runtimes
dotnet --version
Topics
31
.NET CLI, SDK & Project Structure (csproj)
.NET vs .NET Framework
API Versioning
ASP.NET Core Middleware & Request Pipeline
Assemblies & NuGet
Authentication & Authorization (Identity, JWT, OAuth)
Background Services
Blazor (Server & WebAssembly)
Caching (In-Memory, Distributed & Redis)
CI/CD, Publishing & Deployment
CLR & Runtime
Configuration & Options
CORS & Cross-Origin Resource Sharing
Dependency Injection
Diagnostics & Performance
Docker & Containerization
Entity Framework Core & Data Access
Generic Host
Global Exception Handling & Middleware
gRPC Services
Health Checks & Readiness/Liveness Probes
Logging
Microservices & Distributed Architecture Patterns
Minimal APIs
MVC & Razor Pages
Rate Limiting & Throttling
RESTful Web APIs & Controllers
Secrets Management & Configuration Providers (Key Vault, User Secrets)
SignalR & Real-Time Communication
Testing in .NET (xUnit, Integration & Unit Testing)
Worker Services & IHostedService
.NET CLI, SDK & Project Structure (csproj)
15 questions found
The .NET SDK includes everything needed to build, run, and publish .NET applications: the compiler (Roslyn for C#), the dotnet CLI, MSBuild, and the runtime. The .NET Runtime alone only includes what's needed to execute already-built applications (CLR, base libraries) without build tools. Developer machines need the SDK; production servers running pre-built apps only need the runtime.
Real-world example
A CI build agent installs only the SDK to compile and publish an app, while the production Docker image uses a lightweight aspnet:runtime base image without the full SDK to reduce image size.
.NET vs .NET Framework;CI/CD
Publishing & Deployment
The dotnet CLI is the cross-platform command-line interface for creating, building, running, testing, and publishing .NET projects. Common commands include `dotnet new` (scaffold a project), `dotnet build`, `dotnet run`, `dotnet test`, `dotnet publish`, `dotnet add package`, and `dotnet restore`.
dotnet new webapi -n MyApi
cd MyApi
dotnet restore
dotnet build
dotnet run
Real-world example
A developer onboarding to a new project runs `dotnet restore && dotnet build && dotnet test` as a single sequence to verify their environment is set up correctly before writing any code.
.NET CLI
SDK & Project Structure (csproj);Assemblies & NuGet
What is the structure and purpose of a .csproj file in a modern SDK-style .NET project?
IntermediateA .csproj file is an MSBuild XML project file describing how to build a project: target framework, package references, project references, compiler settings, and output type. Modern SDK-style projects (introduced with .NET Core) are dramatically simpler than legacy .NET Framework .csproj files, using implicit file globbing (no need to list every .cs file) and a concise `<Project Sdk="Microsoft.NET.Sdk">` root element.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
</ItemGroup>
</Project>
Real-world example
A team migrating a legacy .NET Framework project to .NET 8 replaces a 200-line .csproj with explicit file lists with a 15-line SDK-style version relying on automatic globbing.
Assemblies & NuGet;.NET vs .NET Framework
A .sln file is a text-based manifest listing one or more related projects (each with its own .csproj) that are built and managed together, along with build configurations (Debug/Release) and project dependencies. It's primarily consumed by IDEs like Visual Studio and by `dotnet build`/`dotnet sln` commands to operate on multiple projects as a unit.
dotnet new sln -n MySolution
dotnet sln add src/MyApi/MyApi.csproj
dotnet sln add tests/MyApi.Tests/MyApi.Tests.csproj
dotnet build MySolution.sln
Real-world example
A microservices repository organizes each service as a separate project within one solution file, letting developers open the whole system in one IDE window while building and testing services independently.
Assemblies & NuGet;CI/CD
Publishing & Deployment
dotnet build compiles the project into assemblies in the output directory (bin/Debug or bin/Release), suitable for local development but not necessarily deployment-ready. dotnet publish produces a self-contained, deployment-ready output including all dependencies (and optionally the runtime itself for self-contained deployments) in a separate publish folder. dotnet run builds (if needed) and immediately executes the application, primarily for local development iteration.
dotnet build -c Release
dotnet publish -c Release -o ./publish --self-contained true -r linux-x64
dotnet run --project src/MyApi
Real-world example
A CI/CD pipeline uses `dotnet publish` to produce the exact artifact deployed to production, while developers use `dotnet run` dozens of times a day during local iteration for fast feedback.
CI/CD
Publishing & Deployment;Docker & Containerization
How does target framework moniker (TFM) selection, like net8.0 or net8.0-windows, affect what a project can do?
IntermediateThe TargetFramework property specifies which .NET version's APIs and behaviors the project compiles against; platform-specific TFMs like net8.0-windows unlock Windows-only APIs (e.g., WinForms, Registry access) at the cost of losing cross-platform compatibility. Choosing the right TFM balances access to newer APIs and platform features against the breadth of environments the application can run on.
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<!-- vs -->
<TargetFramework>net8.0-windows</TargetFramework>
</PropertyGroup>
Real-world example
A cross-platform background service targets plain net8.0 to run on Linux containers, while a companion WinForms configuration tool targets net8.0-windows to access Windows-specific UI APIs.
.NET vs .NET Framework;Assemblies & NuGet
MSBuild properties (in PropertyGroup, e.g., <TargetFramework>, <Nullable>, <LangVersion>) are single named values controlling build behavior, while items (in ItemGroup, e.g., <PackageReference>, <Compile>, <ProjectReference>) represent lists of inputs like source files, package dependencies, or project references. MSBuild evaluates these to construct and execute the actual build graph (compilation, resource embedding, packaging).
<PropertyGroup>
<OutputType>Exe</OutputType>
<LangVersion>latest</LangVersion>
</PropertyGroup>
<ItemGroup>
<Compile Remove="Legacy/**/*.cs" />
<ProjectReference Include="..\MyLib\MyLib.csproj" />
</ItemGroup>
Real-world example
A project excludes an obsolete Legacy folder from compilation using a Compile Remove item, keeping the dead code in source control for reference without it being built.
Assemblies & NuGet;Diagnostics & Performance
`dotnet new <template>` scaffolds a new project or file from a built-in or installed template (like webapi, console, classlib, mvc, blazorwasm). `dotnet new list` shows all available templates, including ones installed from third-party template packages via `dotnet new install`.
dotnet new list
dotnet new webapi -n MyApi --use-controllers
dotnet new gitignore
Real-world example
A team creates a custom internal template package with `dotnet new install` so every new microservice starts from a pre-configured template with logging, health checks, and standard middleware already wired up.
Generic Host;.NET CLI
SDK & Project Structure (csproj)
A global.json file specifies the exact SDK version (and optional roll-forward policy) that `dotnet` commands should use when building within that directory tree, ensuring consistent builds across developer machines and CI regardless of which SDK versions happen to be installed globally.
{
"sdk": {
"version": "8.0.100",
"rollForward": "latestMinor"
}
}
Real-world example
A large enterprise repo commits a global.json pinning SDK 8.0.100 so that a developer with SDK 9.0 preview installed locally still builds using the officially supported 8.0.100 toolchain.
.NET vs .NET Framework;CI/CD
Publishing & Deployment
What is Directory.Build.props, and how does it help manage shared MSBuild settings across multiple projects in a repository?
AdvancedDirectory.Build.props is an MSBuild file automatically imported by every project in and below the directory it resides in, letting you centralize common properties (like LangVersion, Nullable, common package versions, or company copyright metadata) without repeating them in every individual .csproj file, reducing duplication and drift across a multi-project solution.
<!-- Directory.Build.props at repo root -->
<Project>
<PropertyGroup>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
</Project>
Real-world example
A monorepo with 40 microservice projects uses a single Directory.Build.props to enforce nullable reference types and warnings-as-errors consistently across every project without editing each csproj individually.
Assemblies & NuGet;CI/CD
Publishing & Deployment
Showing 1–10 of 15